[std.database]

Jacob Carlborg doob at me.com
Sun Oct 9 02:50:05 PDT 2011


On 2011-10-08 19:00, 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.
>
>
> Andrei

I would say that we declare a high level interface for database drivers. 
std.database can use this interface to connect to all databases there 
are drivers for.

We then provide driver implementations for this interface for the 
databases we choose to support. It should also be possible for a user to 
create his/her own driver implementation for a database we haven't yet 
implemented or choose not to implement.

Driver implementations could be:

* MySQL/MariaDB
* PostgreSQL
* SQLite
* ODBC
* Oracle
* SQL Server

The smart thing would probably be to implement ODBC as the first 
database driver since it would allow most of the common databases to be 
used.

But I don't want ODBC to be the only driver. I have some bad experience 
with ODBC from work. It can't handle multiple result sets and it's not 
very good at handle invalid Unicode characters. This might not be true 
for ODBC in general but it's a problem we have with the implementation 
we currently use. Also, ODBC adds an extra layer between the application 
and the database.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list