Re: DB portability

mlemos@acm.org wrote: > > Hello Nathan, > > Nathan Cook wrote: > > > > I am looking at undertaking a very large project that will be handled > > initially in MySQL. Down the road we may choose a corporate db such as > > Oracle. My thought was since we will have thousands of lines of code to > > migrate to the new db, I could create a global script that is required by > > each individual script. > > > > This global script would alias typical database functions (connects, > > queries, etc...) to PHP's MySQL functions for the time being and I could > > adjust the alias in one central location if we switch from MySQL (I never > > foresee this happening but you never know). > > > > Can any of you see any repercussions of this central database alias script? > > I'm afraid things are not that simple. DBMS work in very different ways > that it isn't > just a matter of defining alias for each database. > > You may want to try Metabase. Not only it abstracts the access to the > database but it also abstracts the installation of the schemas so your > applications can be completely database independent. > > http://phpclasses.UpperDesign.com/browse.html/package/20 > > Manuel Lemos I haven't looked at metabase yet - but have a few questions - what about trigers and stored procedures - how does metabase deal with them ? Im just getting used to using postgresql, interbase, sybase as well as myql with php - using a simple class to extract and insert data - but I'm wondering how you deal with the different features of each database - Mysql lacks a number of things like triggers and stored procedures, sub ueries etc, would I lose any database specific functionality by going with metabase ? Would an application have to be simplified to work with MYsql and your class ? Also what advantage does metabase have over the one in PEAR ? If I use one wouldn't it be better to use one the ships with php as eventually it would be more wisely used ?