Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Outer join for a many-to-many relationship
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Divers
Thread ID:
00292467
Message ID:
00292721
Vues:
20
>Yes,thank you for the response. What you describe is what I am trying to get to. Please see my last reply to Cetin for more of a description on what I am trying to get there from.
>
>The 'P00000' and 'L00000' are not duplicates in their own tables. They are foreign keys in foreign tables pointing back to the primary tables. In the primary table they are unique and serve as place holders. In the foreign tables they indicate records that have been examined, but not resolved.
>
>Al Allison

You described one table to Cetin that sounds like a table of payment transactions, with a messed-up field that mixes personal SSNs with business fed numbers. You are telling me about "foreign tables" and "primary tables" and I'm still not sure which of these things you were given and which ones you created. The specific answer depends on that.

Since your goal is to normalize this mess you were handed (sounds awful :( ), I will repeat: in your end-product of normalized tables and relationships, you will not want or need things like 'P00000' and 'L00000' in any of the tables. You could put such things in 'errors tables' of transaction records you couldn't resolve. But, even there, you probably don't need them. A table or cursor that lists licenses that have no people does not need a people field.

I expect that you will end up with a persons table, a licenses table, and a join table that joins person keys with license keys in the usual many-many relationship. Persons without licenses and licenses without persons don't belong in the join table.

Similarly you could have a businesses table with a key of "fed number" or something, and a join table joining businesses with licenses and another join table joining businesses with persons. Finally, you could give each of these join tables an auto-incrementing primary key. Then you could create a transaction table that would list all the transaction information in your original table, containing keys for the person-license and business-license join tables in fields that would be alternately blank.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform