Surely we're into basic database design. If you have an auto_increment record key that needs changing from time to time then you've designed the database incorrectly. Use a 'normal' key field such as "Product_Id" and have your application generate the number. Simple. No? On 9/4/07, tedd <tedd@xxxxxxxxxxxx> wrote: > At 6:18 PM -0400 9/3/07, brian wrote: > >>Renumbering anything is pretty quick these days. To me, things that > >>are "horribly inefficient" are also slow. So, I don't agree. If I > >>remember correctly, I can even renumber a 100K item dB > >>auto_increment index in less than one second -- but I wouldn't > >>recommend it. I think that's pretty quick. > >> > > > >It may be just fine in your case, but from a DB design standpoint it > >most certainly is not efficient. Why re-order the entire table for > >something like this? Altering an entire table because one row has > >been deleted suggests to me that the schema needs to revisited. > > From a technical standpoint, I agree with you. It's far better to let > the records fall as they may according to the sort, whatever that may > be. > > However, we (or at least I) often work with clients who don't see > that. Instead they see records that they place into their database > that hold information about their widgets and they like to see a > record number associated with their widget. And, when they add a new > widget record, they want to see that count increased and when they > delete a widget record they want to see it gone and a gap, where they > can renumber at their will. > > This makes no difference to me, I can do anything they want. But the > point is that customers usually not don't know the finer points to > what "should" or "should-not" be done, but rather they way they think > things should be done. Understand? After all, it's their business -- > not ours. > > Our charge is to provide them with as much correct information as > they can absorb and then do just what they want beyond that. > > Believe me, arguing with clients about how things should be done has > it's limits. At some point, you just have to listen and do what they > want in spite of what is optimal. > > > >>Presentation is made during presentation, obviously, by using css > >>and proper html and pulling data from your dB to assemble > >>presentation. If the client wants Roman notation, it's a simple > >>process to provide that. > > > >So now you want to rewrite your triggers to use Roman notation? I > >wasn't aware that MySQL had such terrific Roman numeral math support. > > I rewrite stuff all the time to make the presentation exactly what > the client expects. Roman numeral math support is really a no brainer > to create -- that's comp 101 sruff. > > >>There is no "separating data and presentation" in this issue. > > > >I don't buy that. Doing it that way is attaching unnecessary > >presentation-specific baggage to your data. The column is only as > >relational as it was the last time it changed. That is, it was > >pointing to a completely different record then. This isn't a > >"separating data and presentation" issue? > > We are disagreeing if having a record number is necessary or not? > From my perspective, if it is left up to me -- it's unnecessary and > my dB's don't have any. However, if the client wants it, then the > client get's it and it then becomes necessary. > > As for relational, I'm not talking about a relational dB field, but > rather a simple record that the client can imagine. Relational fields > are used to present the record, they certainly would not be involved > in any renumbering schemes -- don't you see what I am talking about? > > Cheers, > > tedd > -- > ------- > http://sperling.com http://ancientstones.com http://earthstones.com > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Graham -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
