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
