Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Converting VFP data to SQL Server data
Message
Information générale
Forum:
Microsoft SQL Server
Catégorie:
Autre
Versions des environnements
SQL Server:
SQL Server 2005
Divers
Thread ID:
01438777
Message ID:
01438785
Vues:
40
>>>>>
>>>>>Creating PKs first for EACH table :-)
>>>>
>>>>Good suggestion. When I converted tables to SQL Server I added to each table an identity column. And I think of it as the surrogate PK field of the table. Each table also has a what I called in VFP a candidate field for which a user creates an entry (e.g. "CUSTOMER_ID"). When you are saying PK you mean the identity column or the candidate field (unique) that user enters?
>>>
>>>
>>>Each table has to have Primary key.
>>>The identity column is good for this (it is a little harder to manage it from the FrontEnd than uniqueidentifier (GIUD)).
>>>But ALL referential integrity of the DB should be done via that Primary key.
>>>All queries from your front end should have that PK in mind :o)
>>>Usually (not necessary) PKs have nothing related to the information in the table. They just didn't hold any information about the record (like RECNO() in VFP).
>>>That is because that way you easier could change the valuable information w/o need to change the related table.
>>
>>I am not sure that my referential integrity should be done via the Primary Key. Let me give you an example.
>>Customer Table:
>>PK CustPK (identity)
>>CustomerID (unique entry, candidate key)
>>
>>Customer Order Table:
>>CustomerID
>>
>>That is, the PK field of the parent table is not in the child (foreign) table. Only Candidate key is in the child (foreign) table. Therefore, my referential integrity will be set on the Candidate (unique) field, correct?
>
>
>Yes,
>Maybe I didn't express myself clear.
>Yes the Referential integrity must be done via the PARENT table primary key and Foreign Key in the Child Table(s).
>BUT every table (no matter parent or child it is) SHOULD have Primary key.
>
>A very rough example why:
>
>Parent Table 
>--------------------------
>Id           Name
>--------------------------
>1            Example 1
>2            Example 2
>
>
>
>Child Table 
>--------------------------
>ParentId     SomeOtherField
>--------------------------
>1            Example 1
>1            Example 1
>1            Example 1
>
>2            Example 2
>
>
>As you see you have 3 records in the child table for the ParentID = 1.
>And HOW you will UPDATE/DELETE only the FIRST of these records if you didn't have PK for that TABLE?

I guess the confusion comes from what I am using as Primary Key. What I was referring to as Candidate key should be called the Primary key. Then what would I call my identity field? Just identity field?; I don't know. Or maybe I ought to redesign my database and use my identity field as primary key and have the same field (like identity in parent table) in the child table(s). Something to think about.

Thank you very much for your help.
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform