Re: Re: Design points (was: parent_ctor())

Kristian Köhntopp wrote: > Stanislav Malyshev wrote: > > AFAIK, meaning of foreign key is the opposite. I.e., this is not a link > > between tables, it is a constraint on two table's contents. Links are done > > with joins, you don't need any tricks for it. Are we talking about > > different SQLs? > > No, you are correct, my examples were inexact. It is an advantage > of SQL that the relationships between types are not as fixed as > relationships between C types. Also, relationships between SQL > types can be enforced better than relationships between C types, > and this is where foreign keys and REFERENCES statements come > into play. I have given the matter some more thought and my example wasn't as bad as i initially thought. The values in column d of table bla are primary keys in fasel, that is, they have semantic only within the context of that table fasel. The appendix "references fasel.d" to the definition of column bla.d denotes that. The "join" operation (specifically, the equijoin of a foreign key and the matching pk) is perhaps somehow more like the dereference operator in C, that is, the *-prefix. You can in principle join anything against anything, just as you can force C to follow a (void *) 0xdeadbeef, but anything but a *mybla.d would perhaps make as much sense. This is rapidly becoming offtopic now. My intent was to clarify why proper handling of references is crucial from a design POV. I hope I succeeded in that. Kristian -- Kristian Köhntopp, NetUSE AG Siemenswall, D-24107 Kiel Tel: +49 431 386 436 00, Fax: +49 431 386 435 99 Using PHP3? See our web development library at http://phplib.netuse.de/