[std.database]

Jonathan M Davis jmdavisProg at gmx.com
Sat Oct 8 14:12:45 PDT 2011


On Saturday, October 08, 2011 12:00:37 Andrei Alexandrescu wrote:
> 1. If we build a D wrapper for ODBC, then we allow people to write code
> for any database that has an ODBC driver. This, assuming we commit to
> ODBC as D's standard database interface, would complete the project.
> 
> 2. If we want to go the route of "one std.database API with drivers for
> each DBMS" and consider ODBC one of several DBMSs, then we need to
> define our own driver architecture, write a few drivers ourselves
> (including probably ODBC), and hope that people will add more drivers.
> That's a larger project but it unties us from ODBC.
> 
> 3. If we want to go the route of "similar but not identical specialized
> APIs per database system" and consider ODBC again only one of the
> database systems, then we need to define one specialized API per DBMS
> and force users to essentially choose upfront what DBMS they'll use, and
> code for it. It's an even larger project and I don't see obvious
> advantages for it than less of a need for upfront design.

I definitely vote for #2 or #3. One of our projects at work uses it (though not 
one that I personally work on), and I've never heard good things about it. 
Supporting it makes good sense, but I wouldn't want us to design Phobos' 
database solution around it.

We should probably explore #2 first, and then if it doesn't work well enough, 
then at least we have a solid base for the API's being similar with #3. 
However, given what I've heard about ODBC and its attempts to unify databases, 
I'm skeptical of how well we'll be able to have a unified DBMS API without 
harming performance. And from what I understand, it's pretty rare to change 
DBMSes for a project. You just pick one and use it. And then in the rare case 
where you have to change, you do the work to do it (and as long as the DB is 
appropriately modularized with regards to the rest of the program, it doesn't 
have a hugely negative affect on the rest of the program). So, I question that 
#2 gains us a whole lot over #3 ultimately (_especially_ if it ends up costing 
much of anything in terms of performance or usability), but I'm not a DB 
expert, and I do think that it's at least worth exploring #2 first - if nothing 
else because it could lead to the APIs for #3 being better unified without 
harming their performance or usability.

- Jonathan M Davis


More information about the Digitalmars-d mailing list