Re: Why not many2one with pk array type
- From: "x" <x@xxxxxxxxxxxxxx>
- Date: Mon, 30 Jan 2006 16:04:04 +0200
How about many to many ?
r1(a pk,b)
r2(c pk,d)
r3(a,c)
Would you design this as
r1(a pk,b, set(c))
r2(c pk,d)
or as
r1(a pk,b)
r2(c pk,d, set(a)) ?
What if the relation r3 has some other attributes, say e,f,g ?
The many to one design is:
r1(a pk ,b )
r2(c pk, d )
r3(a pk, c)
You can look at r3 as r3(a, c) or as r3(c,a). It doesn't matter.
If some constraints are in place, one can join r1 and r3 in r13 and use it
as a base relation:
r13(a pk, b , c)
r2(c pk,d)
Again you are free to look at r13(a,c) or at r13(c,a).
If you want to look at all the information from the parent and the child
node, you are free to look at r123(a,b,c,d)=r13 join r2 on c.
Are you talking about data in a DBMS or about the mismatch of data structure
when interfacing with other software components ?
In the latter case no one is stopping you to use the same model for the
other software components or/and to write a translator between the two
models.
Using the relational model, all your data become explicit and you gain a
vocabulary for talking about it from which you can start building.
You may argue that the relational model is too powerful for building GUI
interfaces and you don't want to build a translator :-)
.
- References:
- Why not many2one with pk array type
- From: Sandy . Pittendrigh
- Why not many2one with pk array type
- Prev by Date: all foreign key should have index?
- Next by Date: Re: Reminder, blatant ad
- Previous by thread: Re: Why not many2one with pk array type
- Next by thread: Rqst for Inventory Database Best Practices
- Index(es):
Relevant Pages
|
|
