Re: Re: DB_Table: Summary and Pre-Call
| From: | Sérgio Carvalho | Date: | Wed, 07 Apr 2004 15:37:19 +0000 |
| Subject: | Re: Re: DB_Table: Summary and Pre-Call | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-27128@lists.php.net to get a copy of this message | ||
Paul M Jones wrote:
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc
Your reasoning make sense, if the only app accessing the database is the PHP app, and you want to keep the app RDBMS-independent. However, experience tells that this is almost never the case. Relational databases, being relatively standard, are a prime target for application integration. Many many times apps colaborate with 'foreign' software at the relational database layer. PHP has good date manipulation routines which could, at a performance cost, replace the native database ones. However, it is expectable that other applications won't use PHP. By throwing away native datatypes, you'll be forcing other software running on top of your database to use a rather poor database.When aiming at interoperability, the best is to aim at implementing a standard. I definitely reject the idea of having dates stored as CHAR or VARCHAR. Most databases have the ability to do powerful date arithmetic. There is no point in throwing all those reliable, fast and proven functionallity out of the window in name of interoperability.Agreed that native date/time types and their related native functions are far more powerful. However, my (admittedly limited) experience is that the powerful date and time arithmetic in one RDBMS is not implemented the same way in another RDBMS. Thus, an SQL query written for one RDBMS with its particular date and time functions will not translate directly to another RDBMS. Additionally, per my earlier conversation with Hans Lellelid, the date and time formats are not the same between RDBMS engines, leading to the need for conversion functions, etc. As always, I am willing to be proven wrong with examples.
You are correct, and I agree -- I want very much to test DB_Table under different systems. I only have access to two RDBMS engines, MySQL and MS-SQL, and only have complete control over the MySQL one. I'd be thrilled if you could help test it out, but I understand if you cannot.I'll try to have a look at it in the next few days. I can also setup a postgresql server for you to test yourself. Do you have a static IP address, so I can drill a hole in the firewall? Cheers, Sérgio Carvalho
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc