[std.database]

[Jacob Carlborg]

On 2011-10-08 23:12, Jonathan M Davis wrote:
> 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 have some trouble with ODBC at work too.

> 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

I think it can be quite useful to change DBMSes for a project. For 
example, start with SQLite because it easy to set up and then move to 
MySQL or similar. It's especially easy to do with Ruby on Rails on Mac 
OS X. Rails uses SQLite as the default database and Mac OS X comes 
bundle with SQLite. There is no extra steps to set up this environment.

-- 
/Jacob Carlborg