RE: [PEAR-DEV] Modification in LiveUser SQL for Perm and Auth

> From: Bertrand Mansion [mailto:bmansion@mamasam.com] > Sent: Thursday, October 10, 2002 4:01 PM > <wolff@21st.de> wrote : > > > Am Thu, 10 Oct 2002 15:22:49 +0200 schrieb Bertrand Mansion > > <bmansion@mamasam.com>: > > > >> Hi again, > >> > >> I forgot to mention one more point about date/time fields. > >> I have noticed that all database support int() fields while they don't > >> support datetime fields the same way. For instance, in MySQL, you will > use > >> DATE_FORMAT() while in Oracle, you use TO_CHAR() in your queries. > >> > >> Then, I suggest we use regular unix timestamps as they are very well > handled > >> by PHP and its date() function. The drawback is that, as raw data, they > are > >> not very much readable except if you naturally know how many seconds > have > >> spent since 1 january 1970 :) > >> > >> Any opinions ? > > > > Actually, we´ve had regular timestamps at first, but then again decided > > to do things the MDB way... but the more I think about it, the more I > > think we should let an MDB container have its own database model, as we > > won´t have this kind of portability with DB, so we should stick to the > > lowest common denominator with the DB container... > > Not having used MDB yet, I didn't know database schemas would suffer from > it > that much. IMO, we should try to have at least 2 DB schemas, starting with > one for DB and then one for MDB. I am pretty sure that in the end, we will > have one schema for each DB, though. > > Still, I think we need some naming conventions for DB schemas in PEAR, > these > will make things easier for developers. Actually MDB has its own native datatypes and maps these datatypes to native datatypes. Any differences are automatically converted by MDB. Furthermore MDB allows you to write your DB schemas in an RDBMS independent xml format. This is exactly the reason why MDB was written, because in DB you will run into soooo many problems. PEAR DB is just a common API (which is does really nicely too), but it has next to nothing in terms of db abstraction. Regards, Lukas