Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Primary Key
Message
De
30/07/2001 15:08:00
 
 
À
30/07/2001 14:06:47
Walter Meester
HoogkarspelPays-Bas
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Titre:
Divers
Thread ID:
00532997
Message ID:
00537387
Vues:
20
>Craig,
>
>Sorry for the late response, i've had a week off.
>
>>Walter... you're right. I'm not going to argue the point. I'll simply state that I disagree with your arguement. For any lurkers, I refer you to Codd and Date and you can make your own decisions from there.
>
>Like they are going to find anything that backups this issue....
>Codd nor Date tell anything about using surrogate keys in a DBMS that hold deleted records in their tables.
>
>Codd nor date tells that each record (deleted or not) should have a primary key.
>They do tell: Each Tuple should have a primary key. Tuples are not the same as records, especially in xBase languages.

That's your reading of the text. Mine differs.

>
>According to Date and Codd, deleted tuples are non-existant tuples. So a deleted primary key is non-existant also.
>
>If you do regard a deleted PK as a existing one how are you going to solve the following:
>
>In a database there is a INSERT RESTRICT RI rule that you can only insert a record in the orderlines table if the article exists in the articles table.
>
>If I delete the article. Can I still insert an orderline with the deleted article ?
>
>** Deleted PKs are non existant PKs:
>Since there is no PK corresponding with the inserted article FK, the RI rule fails: The insert is prohibited, as expected.
>
>** Deleted PKs are existant:
>Since there is a PK corresponding with the inserted article FK, the RI rule succeeds: The insert is allowed. huh ?? Only after you pack the table, the RI rule works as expected.
>
>This issue, i've already discussed with JimB, and he could not give an answer to this one, neither did no-one else here.
>
>You can hide behind your statement, that we've had this discussion before (I don't remember that we have had this discussion before), but all you do is saying that you agree with JimB's standpoint. Although i've got the deepest respect of JimB's contribution on many fields, he's wrong on this subject. And when dicussing this subject, the direction is soon shifted to the vague world of business-rules and n-tier approaches, like this has anything to with it.

Again, a matter of opinions. I say he's right. You say he's wrong. I'll let the lurker decide for themselves.

>
>There are many problems with the 'use surrogates only' approach, which you failed to recognize. Also, your plain answer 'use sorrugate. There is an article on my website.' is most likely not the help the questioner is asking for. When someone is running in such problems, he probably already has got a system running. switching from intelligent keys to surrogate keys is not an easy task. The chances are that the whole system has to be rewritten, views have to be redefined etc.
>
>Only because you believe in an idiotic religion of surrogates only, you are not willing to solve the problem with a clean FOR !DELETED() clause in the primary index.

That's because, IMO.. it isn't clean.

>You've not shown that you've got any knowledge of this subject. All you do is reffering to Codd and Date. Great to which specific part ??? I don't know. You agree with JimB. Because you know him and he is a nice guy and you feel the chances are that he's is wrong is more likely i'm wrong ??? hmmm...

I don't have the time to look it up right now. Too much going on. I have a late release and am even further behind on other things.

However, I could state the same request for your arguement. Can you show me from Codd and Date's writings that you are correct?

>
>This leave me only with one conclusion: This is not only ignorance and having too much pride. It's also plain stupid.
>
>Walter,
Craig Berntson
MCSD, Microsoft .Net MVP, Grape City Community Influencer
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform