# differences in the RDBMS ext API's

- Thread: https://externals.io/message/4584
- Original archive: https://news-web.php.net/php.internals/4584
- Started by Marc Boeren on 2003-09-25T14:51:18+00:00
- Messages: 1
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #4584 — Marc Boeren — 2003-09-25T14:51:18+00:00

URL: https://externals.io/message/4584#4584

Hi,

> IMO there are some problems with the dbx extension:
> 
> - it is a wrapper for PHP modules instead for the underlying 
> database API (therefore slower)

True, but this makes for a lot less build-headaches: dbx has no
build-dependencies

> - you cannot rely on it if you depend on an ISP that does not support 
> this extension

True for any non-standard extension (however, for this case I usually make a
simple, pure-php wrapper with the dbx_function names mapped directly to the
database). I would like to see more ISPs include dbx of course, and since it
builds without any dependencies and has just a small footprint it should be
really easy to do. 

> - it does not include a C API that would be useful for custom PHP 
> modules to access a database

I have successfully used the dbx extension from within another
(C++)-extension, perhaps not as clean as I would have with an API, but ok.

> - it does not include an OOP API

OOP-ish :-)

> My dream is a "full featured" SQL extension completely replacing all 
> other database modules, fast, flexible, build-in by default, 
> recommended to be the best way to access databases in PHP.

Yeah, I would have liked that too ;-). I do like the way this is solved in
Python with its DB-API, however they have great namespace/module
resolution...

> Just my two cents....

Appreciated.

Cheerio, Marc.