Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
How to deal with n-tuples when n is variable?
Message
From
10/09/1999 12:28:43
 
 
To
09/09/1999 22:11:51
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00263226
Message ID:
00263411
Views:
26
>According to my current understanding of relational database theory, each row of a table must contain exactly the same number of columns.
>
>So is there is conventional means for handling cases where one might be tempted to create rows of variable length?
>
>For example: Suppose I want a table that matches mothers to each of their children. Theoretically, one could break the 'fixed number of columns' rule by creating a table having a unique, variable length record for each mother. Of course, then all of the neat database operations become very complex, inefficient, etc.
>
>I can see some obvious ways to handle this while maintaining the 'fixed number of columns' rule. For example, one could define enough columns to hold the maximum number of children expected (thereby sacrificing space efficiency). Or one could choose to have multiple rows for any one mother (then 'mother' can no longer be a primary key). Or one could use Memo fields, and impose some kind of customized formatting in the memo fields that would be cracked by a customized parser. Or...
>
>Don't get me wrong. I'm not lobbying for variable length records, I'm merely curious as to what are the widely accepted means for accomodating those situations where using them might seem a natural way to deal with variably sized tuples.
>
>I guess the way I'd be tempted to solve this problem would be to create a mothers table with a unique record for each mother which specifies the number of children and the name of, say the oldest.
>The latter would be used in a relation into a table of children where each child's record points to its next younger sibling (or to null).
>
>Is this basic approach (with refinements for obvious problems) what is commonly used, or is there a more widely accepted approach?
All good answers that have been submitted. Whether you store the children information in a child (no pun intended) table or in a people table there is no reason you could not add a field for each child to store where in the line of children this one resides (first, second, etc.)
Previous
Reply
Map
View

Click here to load this message in the networking platform