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

[Mark Lamberton]

As a D newbie, Thomas' post is quite timely.  I've collected all 
the books on offer and scanned the 'net for anything D related.  
Like Thomas, I was starting to feel that D was going nowhere 
fast.  Some of the comments here have helped dispel this 
impression, but it's true to say that from an outsider's 
perspective the situation is confusing.  I'm still not sure why 
(for example) Tango exists and what is its status relative to the 
D ecosystem.

Per the discussion on SQL, database access is a subject close to 
my heart.  Posters here may be interested in looking at OpenDBX - 
http://www.linuxnetworks.de/doc/index.php/OpenDBX - an open 
source, lightweight, EXTENSIBLE database access library with C 
and CPP interfaces.

I've used OpenDBX with Oracle, Firebird, and MSSQL in commercial 
applications and from what little I know (so far) about D, would 
seem to be at least a viable starting point (maybe even a viable 
end point for some...) for a 'universal' database access facility.

Mark

On Monday, 8 October 2012 at 07:35:13 UTC, Paulo Pinto wrote:
> 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