RE: [PEAR-DEV] Idea for pear sequence tables

On my list for about day 9 of this week ;-) If someone else has time, great. Otherwise I will get to it sometime about the beginning of next week. Thanks, Rob > -----Original Message----- > From: Tomas V.V.Cox [mailto:cox@idecnet.com] > Sent: Wednesday, September 17, 2003 11:15 PM > To: Rob Hutton > Cc: Jeroen Houben; Stowe, Nola; pear-dev@lists.php.net > Subject: Re: [PEAR-DEV] Idea for pear sequence tables > > > > On Tuesday, September 16, 2003 13:44, Rob Hutton wrote: > > > Yes, this is true that there will be lock contention, but there would be > > lock contention to a certain extent on a "sequence" table also. The > > smallest piece that mosts DBs can lock for a write is a single > block, which > > in small tables like this, most likely contains more that one row, maybe > > even the whole table. When something was committed to disk, > then the whole > > block again has to be locked (although pre and post imaging hide this > > somewhat). > > > That said, it does not change the fact that I agree that it > would be better > > to put all of the sequences in one table. There are many > situations where > > unique ids per table, or at least in some tables, is a > requirement. In most > > cases it is desired per table simply so the sequences are reasonable. > > > The only reason that I can see to leave them in a separate table is the > > perception that it is faster. The reason that I say perception > is that in a > > small table like this, I would bet that the access time is > miniscule whether > > you are reading two dozen records, or one. > > > The down side of them being in separate tables is that you have > two dozen > > separate tables junking up the schema. This is not a trivial thing. > > > So, why would a "single" sequence table not be done? > > Hearing the reasons, looks as a good idea. For the moment there > are other areas which needs more attention, so I'm not going to > put efforts on this in a near future. If you can provide tested > patches for the most important drivers and think on a compat method > for avoiding the break of the current behaviour, I'd be positive to commit > it. > > -- > Tomas V.V.Cox mailto:cox@idecnet.com > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >