tedd wrote:
At 6:18 PM -0400 9/3/07, brian wrote:
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.
...
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.
You are confusing a product ID with this index number. They are very
much not the same thing. A product ID (PLU, serial #, whatever) should
not change. This index does change, any time a row is removed from the
database. How can you suggest that this index can be "associated with
their widget" if the value can change at any time? There's no one-to-one
relationship between the widget and this index. At least, not over the
life of the widget's record in the database.
If your client wants a widget number, then, by all means, provide one.
But if you're going to rely on a figure that is liable to change at the
drop of a hat your database career will soon be over.
Again: the only relation this index contributes is destroyed just as
soon as row is removed. So why bother? An entire table should not need
to be re-ordered every time a row is removed in order to satisfy an
ill-conceived schema.
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.
This is utterly beside the point. So, give your widgets a product ID.
That's obvious. But, why would you want all of your widgets to assume a
new product ID just because one widget has been taken out of production?
Try to explain that to the client when absolutely nothing operates
correctly because none of the widgets has the correct ID.
Again: this index you are proposing cannot be a product ID because it
changes all the time.
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.
I think we are disagreeing with fundamental tenets of database schema
design. But whatever ...
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?
No
brian
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
