On 3/6/06, Jim Moseby <JMoseby@xxxxxxxxxxxxxxxxx> wrote: > > > > What I find interesting in all of this exchange -- however -- is that > > everyone agree's renumbering the "id" of a dB is something you don't > > do, but no one can come up with a concrete (other than relational) > > reason why. > > > > If you don't care that a given record may have a different, unpredictable > record number each time its queried, and if you're sure no one is going to > inherit this application and be stymied by your unorthodox approach, and if > you know that in the future you will not need to access this data by a > static record number, it doesn't matter. Otherwise, my advice would be to > add a timestamp column and sort by that instead. > > JM > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > > I think the main reason is fora more extensible design. Sure, you may only have the 1 table now, and think you never will enhance your functionality...but as soon as you do comes up with a new scenario, you'll have to change the current behavior...easier to plan for that ahead of time. Technically, it works the way you want it...there's no right or wrong way, just degrees of flexibility, and it so happens this method seems inflexible from what I gather. -- Anthony Ettinger Signature: http://chovy.dyndns.org/hcard.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
