[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Next generation of KOrganizer / Call for help: (fwd)
From:       Bavo De Ridder <bavo () ace ! ulyssis ! student ! kuleuven ! ac ! be>
Date:       1999-05-05 14:14:04
[Download RAW message or body]

On Wed, 05 May 1999, Peter Harvey wrote:
> > 
> > ODBC was nice for the past 4-8 years but currently everyone in the \
> > industry is looking for something new, something that will connect to \
> > non SQL databases in an elegant way. Something that unites several \
> > different database in one (virtual) database, something distributed, \
> > lightweight, ... this is everything ODBC is not.
> > 
> 
> 1. "connect to non SQL databases in an elegant way"
> 
> Of course this leads us to OLE-DB and ADO. But remember.... the default \
> provider for OLE-DB is ODBC and this is, in fact what most people are \
> using when they use ADO & OLE-DB. So for most, ADO and OLE-DB just add \
> another two layers to ODBC. I agree, however, ODBC is best at accessing \
> tabular data such as is found in relational databases.... not objects. 

The only reason why ODBC is used in OLD DB is becasue Microsoft wanted to \
make transition as easy and smooth as possible. Access, MS SQL, DB2, \
Oracle, ... already have native OLE DB drivers. Microsoft just wrote a \
wrapper around ODBC so that old ODBC drivers could be used when no native \
OLE DB drivers are available (yet). When people are sticking with ODBC as \
the default driver, that's like people who are running their BMW on steam \
when engines are available. 

> 2. "(virtual) database"
> 
> Universal Database Access Technology is often base upon ODBC. A virtual \
> database server is created by a process which ties multiple ODBC Drivers \
> together. I beleive that this is how OpenLinks ( \
> http://www.openlinksw.com ) virtual server works. 

OLE DB is not based upon ODBC. But... imho OLE DB is nothing more than a \
COM enabled ODBC. The extra features it offers could also have been \
implemented using only ODBC. So, although OLE DB is nice it isn't the \
killer technology it is supposed to be.

> 3. "distributed"
> 
> Two tier is a no brainer... just use ODBC and an SQL Server. n-tier  can \
> also be done with ODBC... for example; you can drop ODBC based COM \
> objects into Microsofts Transactions Server anywhere you want. This is \
> not to say that we can do this on Linux but that it could be done if one \
> wanted to do the work on it. 

With "distributed" I meant the possibilty to use CORBA (or COM) as the \
protocol between ODBC objects. My mistake, the term "disitributed" off \
course means what you stated above. If you would implement every ODBC \
interface using IDL you would end up with something similar to OLE DB. 

> 4. "lightweight"
> 
> ODBC is the litest data access spec out there which provides portable \
> code and plugable drivers (change data source without compiling or \
> linking). 
> 

With OLE DB, you can write a text-based driver by implementing only 7
functions. This could be achieved not because OLE DB is more lightweight, \
but because it used COM. COM enables the aggregation of interfaces while \
only specifying a small interface (cfr. IUnknown, IDatasource, ...).

So I would like to see something based on ODBC but using CORBA. The
introduction of CORBA should also trigger some extra's like the aggregation \
of interfaces. This would be something ready for the next 5 years.

> Peter Harvey


[prev in list] [next in list] [prev in thread] [next in thread]