Re: Pragmatically changing a "Record Number"

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 :-)