Re: Mixed PKs?
Re: Mixed PKs?
- Subject: Re: Mixed PKs?
- From: Chuck Hill <email@hidden>
- Date: Thu, 03 Jul 2003 08:18:03 -0700
A couple of comments. Giorgio is quite right about the possibility of the
need to change the PK. I've never worked for a business that would make an
absolute guarantee that anything would never, never change. I recall one
place that had a box and a half of printed invoices under a desk. Somehow
they had gotten printed with numbers (ah, the good old days :-) duplicating
a previous order. The troubles that first half box caused... EOF has a
say in this too - it considers the PK to be a read only attribute and
specifically rejects any changes. This is because the PK is used in the
EOGlobalID. So if you ever need to change this, forget using anything other
than SQL (or EOAccess calls to generate the SQL).
I'd go with the synthetic PK and use it for what it was intended: a key.
Then create a unique constraint (index) on Invoice ID and Detail ID and use
that to guarantee uniqueness. If you make it a named index you can catch
save failures and check for the index name. Slightly ugly, but EOF and
business friendly.
Chuck
At 12:11 AM 03/07/2003 -0700, Giorgio Valoti wrote:
>On Mercoledl, lug 2, 2003, at 16:07 US/Pacific, Ricardo Strausz wrote:
>> On miircoles, juli 2, 2003, at 07:41 America/Mexico_City, Giorgio
>> Valoti wrote:
>>>> On Monday, June 30, 2003, at 2:16PM, Ricardo Strausz wrote:
>>>>
<snip>
>>>>> does EOF supports multiple PKs generation?
>>>>>
>>>>> Let me be more specific: in a one-to-many relation (say
>>>>> Invoices->>Details) I want to give Details a double PK; the
>>>>> invoices PK and a consecutive number.
>>>>>
>>>>> Can EOF (in its lateest version) do this for me?
>>>
>>> EOF cannot generate compound primary keys, nor a RDBMS can for that
>>> matter. Compound PK are usually composed by two or more foreign keys,
>>> so they cannot be automatically generated. However, an auto-generated
>>> primary key can be used for performance reasons, but some more
>>> constraints should be enforced.
>>> In your specific case, the Details PK is enough to uniquely identify
>>> a record: adding the Invoice PK brings no advantages.
>>
>> In fact, it does; this brings back an old discussion on the uses of
>> PKs. There are people who stiks in the paradigm of using "non-sense"
>> PKs, but in the database I am modeling, the PKs have meaning to the
>> users (invoice number, and item in the example below) so the object is
>> unique up to these constrains (e.g., the third item in the invoice
>> number 1234).
>
>Well, a PK can or cannot have a meaning to the user, I agree. My
>position on this issue stems from the fact that when you a have
>meaningful PK, you have to be prepared to deal with the possibility
>that a PK could change, precisely because the PK has a "business
>meaning". That's not necessarily bad, but it can be annoying, so I
>prefer to avoid this, if I can. Obviously using a synthetic PK in your
>case, leads to the another issue, namely that you have to enforce a
>constraint about the uniqueness of the combination of the Invoice PK +
>the number of the Item and that's not easy with EOF.
>
>HTH
>
>--
>Giorgio Valoti
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.