Login | Register
My pages Projects Community openCollabNet

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Catacomb] [Ann] Catacomb ODBC

Gianugo Rabellino wrote,
> Sung Kim wrote:
> > Hi,
> > 
> > This is an interesting announce.
> > I have two questions about the work.
> > 
> > 1. Does ODBC affect performance?
> Not really, actually it *might* be quite the opposite under some
> circumstances. See 
> http://www.datadirect-technologies.com/products/odbc/docs/WP_ODBCvsOCI.PDF
> for a thourough analysis.
> So far I don't notice any particular delay in using ODBC and, IMHO, 
> the
> added flexibility is well worth the risk of a (not-so-possibly) degraded 
> performance. Just have a look at http://www.unixodbc.org/drivers.html to 
> see what are the wonderful chances opening up to the Catacomb world. :-)

This brings an important subject to attention: why wasn't ODBC considered in
the first place? Why were RDBMS-specific modules being considerer
(mod_catacomb_mysql, mod_catacomb_oracle or mod_catacomb_psql)?

The only reason that comes to mind is that there was some concern about
performance or the associated bias that coding against a native API is
necessarily better performant than through a generic layer like ODBC's.

Performance isn't always achieved just by coding at a "low" level. Any
db-intensive application spends most of its time doing actual database
access. IMO, for *SQL* databases there's little to gain or lose because the
native API or ODBC are used: once SQL is handed to the RDBMS it's up to the
server. The overhead imposed by a layer like ODBC is neglectible.

That said, if the ODBC driver provides transparent services like caching
frequently accessed database rows, reusing prepared statements and similar
optimizations then the application may actually run *faster* than if coded
directly against a RDBMS-specific API...

If we removed the RDBMS/persistence "aspect" (understood as in
aspect-oriented programming) then at least 85% of Catacomb's dbms*.c code
would be common across all RDBMS's. The only way to reuse, to avoid code
redundance would be to come up with a truly portable interface to be
implemented by different RDBMS's.

ODBC, IMHO, provides such a portable interface while at the same time being
a widely accepted standard.

> Oh, besides, if it wasn't clear enough, you're free to take *anytime*
> the code and incorporate it in the Catacomb codebase. Consider this 
> e-mail and Ricardo's one as an official statement of donation.

Yeah! The code is 100% in sync with the latest cvs commits. *Nothing* in the
original codebase breaks down because of this addition, so I kindly propose
it's incorporated as an experimental feature ;-)