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