|
|
Posted by Dikkie Dik on 11/19/42 11:48
<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.
>
>> 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.
Navigation:
[Reply to this message]
|