|
|
Posted by Jerry Stuckle on 11/19/20 11:48
Dikkie Dik wrote:
>>> Quite simple. If the primary key in your application is numeric, you
>>> got it from the database. Otherwise, how would you know the key value?
>>
>>
>> Because you know it?
>>
>> For example, if I'm keeping a table of my customers' credit cards, I
>> might
>> use:
>>
>> customer_id (int, foreign key)
>> card_number (big int, primary key)
>> card_holder_name (varchar)
>> expiry_date (timestamp)
>>
>> If I'm inserting a new record into the table then I already know the
>> primary key, don't I?
>>
>
> No, you don't. You know a FIELD value of your record, NOT its primary
> key. That you wish to combine them (that is always going to get you in
> trouble sooner or later) does not change anything. For clarity: A
> primary key is only a unique pointer to a record and nothing more.
> Especially, primary key values should never be related to the data in
> the record.
>
Actually, that depends on the primary key. It might not be an autoincrement
column, for instance. I've had it be a equipment id (inventory), part number,
(inventory again), SSN (banking transaction), phone number (non-profit call
list) and many other things. A primary key only identifies a unique row; it
does not have to be an auto-increment column, and in many cases something else
does make more sense.
> Let me show it. Suppose this card object is a new one. In this case, you
> do NOT know its primary key. You can't, because the primary key value
> does not exist yet. Oh, you might know what it WILL be, but I could also
> know what it would be if I used an autonumber. The card number column in
> you table serves to purposes: it holds both the identity of the record
> and some data.
Again, it depends on your primary key. The program logic shouldn't even care
what the primary key is - just field values.
> 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.
> 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.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|