At 12:11 PM -0400 9/4/07, brian wrote:
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.
No, the problem is not that I am confusing widget numbers, but rather
your definition of what widget numbers should be doesn't meet the
needs of the client. You have one note in your songbook.
The problem here is that you're being argumentative instead of trying
to understand that not everyone is limited to your perspective. I've
understood everything that you've said, and agree with most of it,
but you fail to acknowledge a single statement I've made. This is
very similar to how we started this thread in the first place when
you completely misread something I wrote and then turned it all
around to your liking. Apparently, you are doing it again.
The client I have, who wants his record numbers to work the way I
described, is a photographer. When he works with his db of pictures
he wants to see record numbers as he steps through his listing. If he
see's something he wants to edit in his database, then he wants write
down that record number so that he can go back and find it again
during that specific editing session. Likewise, if he wants to remove
a picture from his from his database, then it he wants it to be gone
now.
He understands, and doesn't care, that the next time he travels
through his database that the numbers above his last deletion have
changed. In fact, I don't even have to keep the numbers in a field in
his database -- instead I could easily use the creation data-stamp
for a sort and present his pictures to him that way. But, he wants
that field number there, so that he can continue his editing later,
if he decides to quit -- he wants his current editing session to
remain "as-is" until he changes it -- so the field is there for him.
The point is -- this is an example of a reference number that the
client wants and uses successfully. Who am I to argue with him. In
fact, who is anyone to argue with something that works for him? You?
You want to impose your view of how he should work? Keep in mind,
this is the client and they say, and pay for, what they want.
I think you'll find in life that not all aspects of dealing with
clients fall nicely into the way you think things should be done.
It's probably best for you to get used to it now than later.
Enough said on this subject, besides I don't think you're reading
what I write correctly anyway.
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
