Tue, 16 May 2000 14:17:57 +0200
Bill Tutt wrote:
> > From: M.-A. Lemburg [mailto:email@example.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.
Python Pages: http://www.lemburg.com/python/