On Thu, May 4, 2006 2:48 pm, Drew Butler wrote: > Just had a quick question for anyone out there. I've been using PEAR's > DB > object for quite a while, as I have to simultaneously work with both > MySQL > and PostgreSQL. Currently I use the nextID() method to find new IDs > for the > rows that I insert, but am running into an issue with its sequence > tables. > The fact that it generates a table for every corresponding sequence is > becoming unbearable, as it is seriously cluttering my databases. I was > wondering if anyone knew of a PEAR hack out there that might push all > of > these sequences into a single table that has the sequence name as a > second > row. I'm on the verge of doing this myself, but am hoping for a better > solution, as I would rather not have to break PEAR. > > Any thoughts on how others have tackled this issue ? > > It just seems silly to me that they did not make the sequences behave > in a > nicer way when they designed this system. I would much rather see > something > like a `pear_sequences` table then an extra 4 dozen tables. Thanks. One reason might be that PostgreSQL actually HAS a built-in 'sequence' thingie, which is not a table at all, and you can easily view all tables with no sequence clutter. (Or vice versa.) So while it might be great to hack the MySQL version to use one table for all, doing it to PostgreSQL version might be a significant penalty -- Or maybe not, as PEAR DB might be cluttering up PostgreSQL with tables instead of using sequences in the first place... Which would make me rather sad, frankly, but so it goes. I dunno when/if MySQL will/did implement 'sequences' as a construct of their own, but it sure would-be/is nifty. One of things that I dislike about database abstraction layers is that they inevitably do this kind of thing to work around implementation differences between database vendors. Maybe someday all the database abstraction layers will be moot because all the SQL engines will actually come up with a standard WAY better than SQL92/99/2003 and then they'll all implement a fully-conforming feature-set... I ain't holding my breath. Thought maybe the OS DB community should take the lead on this, and leave the commercial "we don't WANT to be interchangable cuz we'd lose customers" databases in the dust. :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
