Re: [PHP] Database abstraction From: Andreas Karajannis (Andreas.Karajannis <email protected>)
Date: 09/16/00

Hello Manuel,

>The way I see it that is not quite what developers want. They end up doing
>that because upgrading database schemas is not a trivial task to get done
>right in a fail safe way.

I can see your point - but I don't think that PHP is the right tool
here.
There are existing database modeling tools (e.g. ERWin, Powerdesigner)
that
already give you this functionality. You start by designing your
abstract
data model independant of a specific RDBMS and can later on generate
SQL scripts for the various systems.

>That doesn't work quite like that. It's upto the the developer that uses
>the database abstraction package to specify field properties consistent
>with the limitations of the underlying database. If he asks for a table
>with property values that exceed the limits of the DBMS, the CREATE TABLE
>statmente will fail because the database abstraction can not do anything to
>overcome the DBMS limitations.

That's exactly what existing tools already provide. In addition, if you
don't
want to use these tools, you can always use odbc_gettypeinfo() to get
the
datatype specifications and limits - it's always up to the developer
himself
to work around db specific limitations.

>I see that the ability to set constraints is good to prevent bugs but not
>needed if the programs do not have such bugs. So, I see foreign key
>support as desired feature, but you can live without it.

When your data model gets more complex you will be grateful for
triggers,
stored procedures and foreign key constraints to maintain database
integrity.
Having all these features prevents your application from being broken by
inexpierenced developers. More important, checking the constraints in
the
application yourself requires additional data transfers between the app
and the database server. Network and IPC communication are slow.
Doing 4 or 5 such data transfers instead of 1 is tremendous overhead.
>Yes, PHP ODBC API needs plenty of work, but for now what it is really
>needed is a simple function stub for SQLGetInfo and the ability of detect
>whether a given result column contains a NULL.

odbc_gettypeinfo() returns a result id that contains information about
either
the requested datatype (the standard odbc datatypes are defined as
constants,
see php_odbc.c for their names) or all available datatypes including
databse
specific ones. You can easily glance at what datatypes a database
provides:
<?
$dbtypes = odbc_gettypeinfo($conn_id);
odbc_result_all($dbtypes);
?>
This will print a table with information about every datatype.
As for the columns provided by this function, please refer to the ODBC
API
specification part II, where under SQLGetTypeInfo() this gets explained
in
detail. Retrieving the information you need out of the columns with PHP
should be trivial.

As for the NULL value detection, I don't want to add some quick & dirty
hack
to implement this when it might change again with a major rewrite later.
In the meantime, an additional where clause testing for NULL could help
in some cases.

-Andreas 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: php-general-unsubscribe <email protected>
For additional commands, e-mail: php-general-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>