SQL working [ was Re: The sorry state of the D stack? ]

[Paulo Pinto]

On Sunday, 7 October 2012 at 20:05:22 UTC, denizzzka wrote:
> On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
> Wakeling wrote:
>> On 10/07/2012 10:55 AM, Russel Winder wrote:
>>> Why only PostgreSQL. Shouldn't it also work with MySQL, 
>>> Oracle, DB2,
>>> PervasiveSQL, SQLite3, etc.?
>>
>> I don't have sufficient experience with SQL to be able to 
>> really make a judgement here, but is there a case for a 
>> std.sql or std.db that would provide a uniform D interface to 
>> the arbitrary DB of choice?
>
> Each database engine has a unique distinguishing features that 
> make this engine interesting. (for example, different 
> implementations of transactions - SQL standard does not 
> describe the SQL transactions precisely enough)

There are plenty of existing interfaces to base D's design on, 
just a few of them:

Perl - DBI
Python - DB API
C, C++ - ODBC (there is an UNIX variant of it)
C++ - OLE DB (Although Windows specific)
Java - JDBC
.NET - Data Providers
Ruby - DBI
TCL - TDBC
Go - database package
Delphi - Data Access
Haskell - HaskellDB (HDBC)

>
> So, I do not know is it possible to make a universal interface. 
> And why it may need in real life?


At least in the enterprise world, we tend to write applications 
in a DB independent way.

One reason is to be able to deploy the applications without 
forcing the customers to invest in new DB engines, thus reaching 
a broader client base.

Sometimes inside the same organization different business units 
have different DB engines running (even different versions of the 
same DB).

Finally, to minimize costs when management decides for whatever 
reason, to change the DB licenses being used.

--
Paulo