Re: general questions

Lukas Smith <smith@dybnet.de> wrote in message news:000a01c17904$c8f034e0$4d00a8c0@vandal... > > To the ADODB folks: I have not done benchmarks myself but if ADODB is > such a speedster then please help us incorporate this into this new > abstraction layer. Hi Lukas There would be no speed issues if we planned a standard C API that had similar functionality and we got rid of some of the crazy inconsistencies plaguing programmers who want to write portable code. Speed is simply a matter of the number of lines of code executed. If you count the lines of PHP code that ADODB executes versus PEAR DB or Metabase for a commonly used function like fetchRow() you will see the difference in LOC. There is no secret there! The best advice I can give is KISS: " keep it simple, stupid!" ADODB has some good performance characteristics because we stick as close to the native API as possible. If there are differences in a way the API works, ADODB at the first level doesn't try to workaround it unlike Metabase which tries to find a standard portable solution. ADODB accepts the incompatibility and moves on. However I understand that 100% portability is a very good goal.I am working with the PostNuke developers to achieve this. So the latest beta of ADODB has 2 levels of portability. The first uses the native calls. For example, Oracle has the class ADOConnection_oci8 and is a thin layer over oci8. Bind variables use the Oracle :bind method. Then we define a Portable layer called the PO level, and we have a class called ADOConnection_oci8po. In this class, the more common bind variable method of ? is supported. In this way users have a choice - high speed (use the oci8 driver) or high portability with the oci8po driver. Class hierarchy: class ADOConnection { } ## base class class ADOConnection_oci8 extends ADOConnection { } ## high speed derived class class ADOConnection_oci8po extends ADOConnection_oci8 {} ## slow portable class WHY PORTABILITY ISN'T EVERYTHING TO ME ====================================== My concerns over performance are probably specific to my needs. One of the projects I am working on involves an Extranet with 50Gb of Oracle data, where the largest table has 82 million records. High speed data access is a concern for me, and not so much portability. I believe that there are different levels of portability and performance and there is a tradeoff. There is no one right answer... I want to access and define the tablespaces in Oracle, decide whether to use index-ordered tables, or normal tables, add optimization hints to my SQL, etc that are database specific. It makes no sense for my type of work to hide all these issues under the carpet because a lot of my work is on large databases where tuning is everything. So I want a thin database API layer that doesn't get in my way by virtualizing everything. That is why Metabase is not such a good fit for my needs. Now suppose I want to port my application to say MSSQL in the future. I don't require 100% portability because my customer will pay me $$$ to port to their preferred database. But I do want an API like PEAR DB or ADODB that standardizes my calling conventions so I can do the port quickly. I think that a universal database API is wonderful at the C level, but there will always be multiple higher level API's because SQL or php_mysql is still too basic an abstraction, and no one database API can serve everyone's needs. To me having a defacto standard is nice. PEAR DB is as good as any out there. It's a good API with some really nice ideas like getAssoc(). But Delphi decided to have a higher level API; so did Visual FoxPro; so did VB - there is nothing wrong with this, provided we build on a good foundation - and there is where PHP is weak - an inconsistent C database extension API. Here's another extension blooper: php_ibase commits on a script error, instead of rolling back. Every other php db extension rolls back. Commiting makes no sense if you think about it. Bye, John References: Tom Kyte on Oracle and Black Box Programming: http://wdvl.internet.com/Authoring/DB/Oracle/OneonOne/