|
|
Posted by Jerry Stuckle on 05/14/06 22:32
Dikkie Dik wrote:
> <snip>
>
>>> You don't believe me? Just lookup your "known" record in the
>>> database. You won't find it. It does not exist. You will only find it
>>> if you know its primary key value. And for the record to have a
>>> primary key value, it must exist in the database first.
>>>
>>
>> True, it won't exist. But you don't necessarily know that unless you
>> check.
>
>
> Wrong. That is what I am trying to tell you all the time. Whether you
> should update or insert the record is something you know beforehand. If
> the user selects a card from editing, that card is retrieved from the
> database and marked (with any means you like) as existing. You should
> now be able to change any DATA value of the record.
> If the user clicked "enter new card" or just did not select an existing
> record, he is entering a new card which is marked as such. So before I
> edit anything, I already have checked the existence of the record.
>
> And it's quite simple: existing records get updated, new records get
> inserted.
>
> By the way, if you take the credit card number as a primary key AND get
> the existence from the database, you would only have to give someone
> else's credit card number to hijack his card. If the credit card already
> exists for another user in the database, you have a data validity
> problem, NOT a key problem (unless you abuse data for a key, off course).
> Oh, and if I correct a misspelled credit card in the system, I end up
> with TWO credit cards. I told you this is trouble to no ends.
>
First of all, I didn't say credit card number. But over the last 25+ years,
I've worked on numerous systems - from banking to manufacturing to accounting
and beyond. And I've worked on PC based systems getting 10-20 queries a day,
and mainframe systems getting hundreds of thousands of queries a minute.
And no, an auto-increment field is not always the way to go.
>>
>>> But apart from that, your code does know whether the record comes
>>> from the database or from another source. If you can't trust your
>>> primary keys, you could have the table wrapper just set a boolean
>>> when getting the record from the database. The original question was:
>>> how do you know that a record comes from the database? If you want to
>>> know that, your database code has to be held responsible for keeping
>>> track of that. If you can't do that with the primary key because it
>>> interferes with data, just find another way. Anyhow, your table
>>> wrapper knows if it came from the storage.
>>
>>
>> Again, the program itself should not know nor should it care about
>> primary keys.
>>
> Say what? The primary key uniquely identifies the record. Without it,
> you don't even know which record to update. As shown above, you should
> identify a record by its key, NOT by its data. That is why keys should
> never relate to data.
Exactly. The primary key is a DATABASE construct. A SSN may very well be the
unique identifier. In many systems such as banking and payroll, it is. An
account number may be the primary key in a number of systems - from banking to
shopping. Airlines use the frequent flier number as the primary key for their
frequent fliers, just as hotels use it for their frequent customers.
It is QUITE frequent to use data as primary keys, when the data itself is unique.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|