Re: [PEPr] Comment on Database::DB_Table
| From: | Alan Knowles | Date: | Wed, 24 Mar 2004 01:37:52 +0000 |
| Subject: | Re: [PEPr] Comment on Database::DB_Table | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-26723@lists.php.net to get a copy of this message | ||
PEPr w
I would argue that it's always difficult to accommodate changes in DB structure after a project starts; The only tool that I know of to gracefully handle schema changes is MDB. However, I do look to make DB_Table handle schema changes by comparing the internal description to what it finds at the table, although admittedly that is a difficult and long-range goal.SQL is probably the best method for changing structure after a project starts. (although not very portable) At present in DB_DataObjects, I very frequently modify table after project starts. (even on live servers) - clients have a horible habit of changing their minds.. :) Process: - using mysql command line to run ALTER TABLE command. (store this in some text file somewhere) - run createTables, to update the code to match the database table. If I need replicate the change to another server - the process is just to run the sql commands. In DB_Table logic. Process: - modify PHP code manually - modify sql manually to match.. (or just drop and let the class automatically recreate the database) there is a slight risk that this approach introduces bugs, - this is why I have tended not to use this methodolgy and why the schema in DataObjects is designed the way it is.. in the MDB logic - it depends on you keeping a 'changelog' in the XML Schema. while very good for projects that have to be maintained across a large range of database, it is extremely verbose for projects that are likely to only target 1 or 2 databases, and currently has some serious kludges to work around cross platform support for some types.. I would generally say the trade off on DB_Table is future flexibility against installation ease and database portibility. Where as Dataobjects may make it difficult to maintain more that 2 or 3 database backends over a long period of time. - but makes it very easy to maintain less than that. Regards Alan
Proposal information: http://pear.php.net/pepr/pepr-proposal-show.php?id=14-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com