Re: Re: DB_Table: Summary and Pre-Call

Hi guys, Sérgio carvalho wrote:

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.

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.

I think this is a very valid point -- and roughly the one that I was thinking of when I mentioned that this convention is making DB_Table unstandard. I've built a number of PHP applications that needed to ingegrate with other platforms -- g.e. recently Jabber. I can only imagine that if you were integrating with Java or a COM+/.NET app that you'd run into a lot of trouble when you tried to work w/ DB_Table DATE/TIME columns. Additionally, I think it's simply impossible to get a DB abstraction package that's truly abstract. As you mention these SQL functions are going to be different from one RDBMS to another. The behavior of SQL can change within a database too -- for example if you use InnoDB and start defining foreign keys you may start getting errors when you try to insert rows. There simply are going to be differences & I think this is ok. Anyone moving an app from one RDBMS to another (which again, rarely happens) is going to be aware of this and is going to have to budget some time to fix things. I do believe that you want to format and parse data to create standard return values, but I'm less convinced that you should work with non-native types *internally* in order to faciliate this end. I would re-iterate, though, that it's mostly a difference in philosophy and certainly others (SQLite) agree with your approach. Sergio is right that it isn't ideal for systems where data is shared between different technologies (and that really feels like the direction that everything should be heading). Cheers, Hans