tedd wrote:
At 12:11 PM -0400 9/4/07, brian wrote:
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.
I have not once "defined" what a widget number, product code, whatever
should be. You're imagining things now. There LARGE_NUMBER of formats
that a "widget number" can have. I couldn't care less how you (or your
client) chooses to do so.
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.
Why are you getting all pissy now? I certainly haven't been. Have i not
been including enough smileys or something?
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.
Well, if your client needs to print out something that relates back to
the record, print out the primary key. Print out the PLU.. Print out the
[insert UNIQUE_VALUE here].
Better yet: design the app so your client doesn't have to get out a
pencil. But i digress ...
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
So why all the fuss about having to keep this problem-child "index"
field in the table, then? If it doesn't have to be in there then why are
you insisting on including it?
-- 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.
Not one thing that you've described here comes anywhere close to making
a case for designing a database schema in such a manner. All of the
above can be accomplished without having to re-order your table each
time a record is removed.
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.
You're being pissy again. It really reflects poorly on you and, i
suspect, it's keeping you from truly understanding what it is that i'm
trying to help you with.
Enough said on this subject, besides I don't think you're reading
what I write correctly anyway.
I read it twice ("correctly", even!). Mostly because your stubborness
fascinates me. Like a moth to a flame, really.
brian :-)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
