[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]