[DB-SIG] .prepare()

M.-A. Lemburg mal@lemburg.com
Tue, 16 May 2000 14:17:57 +0200


Bill Tutt wrote:
> 
> > From: M.-A. Lemburg [mailto:mal@lemburg.com]
> >
> > Bill Tutt wrote:
> > >
> >
> > > OLE DB is better than ODBC by a long shot, but its also a
> > very complex
> > > beast.
> >
> > But it's nowhere near as portable as ODBC... on NT or Win2k
> > OLE DB may be the way to go, but on other platforms such as
> > Unix or Mac you'd have to revert to other means.
> >
> 
> I never said life was easy, just mentioning that if you wanted to come up
> with a cool database API that OLE DB is the coolest thing since sliced bread
> in this area.

Hmm, Andy could probably steal a few ideas from OLE DB and reimplement
them using CORBA as backend.

I'm not sure whether it's worth the effort though.
 
> > > [Andy's CORBA DB API]
> > >
> > > You really should read the OLE DB specs. They specify COM
> > interfaces for
> > > everything you've specified above and mroe...
> >
> > AFAIK, COM is MS centric and I think Andy is targetting Unix
> > platforms here as well.
> >
> 
> *sigh* Screw COM. There are two very important concepts with OLE DB that
> make it very powerful. The interfaces that the objects expose, and
> aggregating IUnknowns.
> You can implement these core concepts on any semi-object oriented system. In
> C++, in CORBA, or whatever.
> 
> He was thinking about a blue-sky concept, so I pointed him at what I think
> the blue sky should look like on every platform. :) My top DB API related
> wish is that the core OLE DB libraries were open source,

That would cool and certainly help push OLE DB... but would
this be possible at all ? I would guess that OLE DB relies
heavily on COM and other MS techniques.

> and people could
> use them on Unix or whatever, but it certainly doesn't seem likely to
> happen. Data conversion helper libraries are such a pain in the ass to
> write. :(
> 
> > > SQL 7 is completly built using a superset of these OLE DB
> > interfaces. OLE DB
> > > lets SQL 7 easily perform and optimize joins between
> > different databases.
> > >
> > > Utterly cheesy example:
> > > Joe wants to join table A in an Oracle database against
> > table B in a SQL 7
> > > database.
> > > Depending on the index statistics information (on table B
> > and on table A)
> > > the SQL 7 query optimizer can decide how much of the query
> > can be pushed
> > > into the Oracle database, and how much of it should be done locally.
> > >
> > > The OLE DB interfaces exposes all the necessary information
> > that allows SQL
> > > 7 do perform this cool task.
> > > (Yes, people really do use this feature in real life.)
> >
> > FYI, in ODBC you would do the same using an ODBC DB engine like the
> > one sold by EasySoft.
> >
> 
> That may be, but writing such a beast is much easier using OLE DB than it
> every would be with ODBC.
> ODBC doesn't expose interfaces that allow you to query for an index's
> statsitcs information.

I guess this could be done by hooking into the DBs system tables...
at the cost of not being portable anymore; probably too big
a project though.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/