Right after allocators: containers or database connectivity?

[Daniel Kozak via Digitalmars-d]

On Tue, 09 Jun 2015 11:41:37 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> On 6/9/15 10:44 AM, Daniel Kozak via Digitalmars-d wrote:
> >
> > On Tue, 09 Jun 2015 10:05:24 -0700
> > Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> >>
> >> For database connectivity I'm thinking of using ODBC. What I see is that
> >> on all major platforms, vendors offer mature, good quality ODBC drivers,
> >> and most programs that have anything to do with databases offer ODBC
> >> connectivity. So connecting with ODBC means the individual database
> >> drivers are already there; no need to waste effort on creating drivers
> >> for each (or asking vendors to, which we can't afford).
> >
> > Having ODBC support in D is definitely important for some kind of
> > applications. But for most applications which works with some (kind of)
> > database it does not scale. We really need individual drivers for each of
> > the most popular databases (even as a C/C++ lib with d binding around it).
> 
> I derive the exact opposite conclusion from the same facts.
> 
> * Individual drivers for each database engine: spend effort on designing 
> an API, THEN spend effort on writing or adapting (and then maintaining) 
> one driver per database engine. That has "does not scale" written all 
> over it.
> 
> * ODBC: design an API on top of ODBC, then ENJOY all the hard work 
> various database engines have put into their drivers. That scales.
> 
> 
> Andrei

Yep this is the other side of a coin :), and I agree with that. But I do not
belive that performance and features would be on same level as individual
connectors.