Re: PHP is the scourge
On Tue, 7 Dec 2004, Christopher Hicks wrote: From my experience, switching databases from one to another in PHP when using Pear::DB isn't any more difficult than if I were using DBI or JDBC because the hard part in switching Databases is always in the native database code. Alzabo seems to do a good job of dealing with these things if database portability is a big deal for the project. I've considered using it for managing database changes over time, but keeping a history of the alter tables and create tables works for now. I think it does an ok job, but that's not really it's goal. I also don't think this is super important. You pick a particular DBMS because you think it's the right tool for the job. Only in a few rare cases (apps written for wide distribution) is there any reason to consider portability across DBMS backends. I've never written an app for a client that started on one backend and moved to another. I imagine that if this were to happen, it'd be because the new backend provided some set of features that were now important to the app, and some code changes would be necessary to take advantage of this. -dave /*=== VegGuide.Org Your guide to all that's veg. ===*/
Re: PHP is the scourge
Dave, I think it does an ok job, but that's not really it's goal. I also don't think this is super important. You pick a particular DBMS because you think it's the right tool for the job. Only in a few rare cases (apps written for wide distribution) is there any reason to consider portability across DBMS backends. Good point. From a framework author's point of view, the framework should be able to work with whatever database the app developer deems to be the correct one for their situation. (I believe this is just the logical extension to what you were saying.) Cheers, Richard
Re: PHP is the scourge
On Tue, 7 Dec 2004, Richard Dice wrote: Dave, I think it does an ok job, but that's not really it's goal. I also don't think this is super important. You pick a particular DBMS because you think it's the right tool for the job. Only in a few rare cases (apps written for wide distribution) is there any reason to consider portability across DBMS backends. Good point. From a framework author's point of view, the framework should be able to work with whatever database the app developer deems to be the correct one for their situation. (I believe this is just the logical extension to what you were saying.) Yep, pretty much. So-called database independence is something sought our by people who don't know much about databases, IMO. If you're just treating your SQL DBMS like a filesystem or object store, you're missing out on all the power the DBMS can provide if you actually use it properly. -dave /*=== VegGuide.Org Your guide to all that's veg. ===*/
Re: PHP is the scourge
Dave Rolsky writes: I've never written an app for a client that started on one backend and moved to another. I imagine that if this were to happen, it'd be because the new backend provided some set of features that were now important to the app, and some code changes would be necessary to take advantage of this. We start all projects on Postgres. When Postgres runs out of steam, we move to Oracle. This has happened once, and is likely to happen again. Rob
