[Asterisk-Dev] Current database abstraction effort ?

[Glenn B. Lawler]

>ODBC will slow down db access in varying degrees, depending on a number of
>issues including db schema, the ODBC driver efficiency, the system's
>implementation of ODBC.  But from a code management standpoint (if you are
>going to write to a database at all!), this is probably all worth the loss
>of some performance, which should not be significant if you read further.

The way this is stated seems to imply that ODBC is ALWAYS slower than
some other way of accessing a database. Our primary business involves
developing system software that uses a number of client/server relational
databases; we do bench marks on such things and I can assure you that
ODBC is often just as fast as "native" database access. I understand the
confusion on this subject since when ODBC was relatively new, most ODBC
drivers were implemented as an additional layer of software that simply did
a translation to a native database call. Obviously, when an ODBC driver is
implemented in this way, it can never be as fast as the native access.
However, many ODBC drivers are implemented as a single layer that
communicates directly with the database. These single layer implementations
are typically just as fast as the native method. A case in point is Microsoft
SQL Server.

I should also mention that ODBC is the defacto standard for database access.
ODBC is a one-for-one implementation of the X/Open CLI (Call Level Interface)
standard.

We at Incode Systems are very big on standards-based software, and ODBC is one those standards. Everyone here probably realizes that
application software that uses ODBC to access the database can be
written to use any any backend that adheres to the same API Level. This
promotes competition among the backend RDBMS providers and leads
to higher quality, lower cost RDBMS backends. Developers and users
are the winners.

Glenn Lawler
Incode Systems, Inc.
http://www.incodesystems.com