Hello, John Lim wrote: > Each designer has a different point of view, like Tomas has > written a really excellent oci8 "select limit" emulation, but looking > at the code, it's so complicated that i decided not to incorporate it > in ADODB because I value simplicity. I know Tomas' code works > in theory, and its really impressive that you even considered UNIONs, > Tomas, but I just like "simple" code that I can keep in my head.
But it does not work with computed columns like those that apply functions (COUNT, SUM, SUBSTRING, etc...). The code assumes that you are actually selecting only real table fields. I think it also does not work with columns with table name prefixes. > I think some standardization in terms of API is good, but I don't > think most people care. Newcomers to programming will want to use > something easy and "standard" - is PEAR DB already the standard? Newcomers never know what they want. Most of them learn by copying examples without really understanding them right away. Once they evolve they start caring about things like: Oh, MySQL does not provide good support for transactions or sub-selects. I have to use something else like PostgreSQL, Oracle, MS SQL, whatever. Gee, but my code will not work seeminglessly with those databases! That would not be a problems if they were using Metabase, but they did not know that portability is important to protect their work from changes like this. This happens very often when you mature as a database programming developer. > If we fixed these problems and more, we could talk about having > a unified API. Otherwise for the Oracle OCI_ASSOC, I would prefer > not to change it for speed, Manuel would want to provide an emulation > layer, i would object because it's slow, etc... If you want to resort to non-portable database programming, just stick with the native database API that PHP offers and you will get all the speed that is possible. Using a database abstraction that does not offer portability and still adds execution overhead does not make much sense. Your programs still need to be adapted to run with different databases and they will still be slower than using the native PHP database APIs. > PS: the history of windows shows it's ok to have multiple abstraction > layers: ODBC, RDO, DAO, ADO, ADO+, JDBC, Delphi's db classes, VB's data > controls, provided there is progress. Most of them are either for different languages or just wrap around each other, so they are really not competing in the same language domain. Regards, Manuel Lemos -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
