Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
How to use generated primary keys ?
Message
 
À
07/05/2000 13:46:58
Walter Meester
HoogkarspelPays-Bas
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Divers
Thread ID:
00367063
Message ID:
00367100
Vues:
48
>You're saying that if you delete a record, it still exists. Tell anyone outside the xBase world that if you delete a record it still exists: it does not make sense. He'll ask:

Walter,

I don't care what someone not using VFP has to discuss, this discussion is about VFP. What other systems do is irrelevant. BTW, I use surrogate PKs in ALL systems regardless of the dbms used.

>How about heterogenious solutions where VFP and SQL database should play together ? I think this a rather short minded thinking. Try to intergrate a solution where you have a database in ORACLE which uses intelligent keys, and synchronize lookuptables in a local VFP database (with replication): You'll have problems without a filtered primary index.

As I said above, I use surroaget keys always, in all systems, in all tables, in all places, at all times, everytime, every where. I don't have a problem with this at all. Surrogates work everywhere without reservation and without regard to the DBMS is use.

>This is not correct. A tuple must have a PK (again this is relational theory). The RM doesn't know the concept of a record. a VFPs equivalent to a tuple is just a non-deleted record.

Again with the semantics. We are talking about VFP here, remember?

>Take a foreign key in a deleted record, change it in anything you want. It does not error because the RI rules are not fired. the RI mechanism just IGNORES ANY DELETED RECORD. To the RI mechanism deleted records DO NOT EXIST. So a DELETED PK value does not exist either.

OK, so the code generated by the RI builder sucks, so what else is new?

>>>This is simply NOT true: the relational model says that any alternate key has an uniqueness constraint. Alternate key's ARE a part of the relational model.

This is not true, the RM says that PKs must be unique and non-null. The fact that there may be more than one candidate (that is it is unique and non-null) for the PK has nothing to do with the RM. It is simply a result of the domain definitions of the respective attributes. Once the PK is selected the RM essentially ignore any other candidates (except for the Boyce-Codd NF rule).

I'm done with the discussion for now. We have gone over this many times before, you have your ideas and I have mine. You will not convince me to accept your approach, of that I can guarantee you. I don't really have an interest in convincing you of mine. So, for me, this discussion is a waste of time. Signing off now.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform