On Thursday, March 14, 2013 5:13:04 PM UTC+1, Cédric Krier wrote: > > On 14/03/13 17:05 +0100, Wolfgang Keller wrote: > > > > If you're advocating it then you probably won't need to know any > > > > further arguments since you've already understood the issue > > > > yourself: That data integrity is what counts. And without composite > > > > keys, that can't work for any non-trivial application that requires > > > > a thoroughly normalised schema of significant complexity, since > > > > proper unification of records in such a schema requires composite > > > > keys. One of the issues that's practically impossible to solve with > > > > surrogate keys is explained in database design textbooks under the > > > > title "overlapping foreign keys". > > > > > > I'm not sure to understand exactly the "overlapping foreign keys" (as > > > you did not give any reference). > > > > Just look it up in any decent database design textbook. ;-) > > > > In Belgium, the faculty of computer science at the university of Namur > > resp. Rever have online "entry level" tutorial PDFs for free that > > mention it. > > > > It's a standard issue just like normalisation (in fact it's sometimes > > mentioned as being correlated with 3NF/BCNF) and I am not going to > > "discuss" whether composite (natural) keys are necessary or not. > > > > Besides, there are certainly loads of other unification issues that > > absolutely require composite keys, this is just an exemplary example > > that has a distinctive, well-known name and that is commonly taught in > > database design classes. I am not even a computer scientist and still my > > professor at university has mentioned it. > > > > Basta. > > Thank you for not giving any links that confinces me that it is a "must > have". > > -- > Cédric Krier >
Hi Folks, @Cédric: first of all, sorry for the yesterday Top-Post (I hope this one will work). The feature of "composite primary keys" is very handy, but let me address it from a different point of view. When importing data into any "relational Software" like Tryton, you might want to update existing records or add new records if none is existing | where record is an instance of an real life object. With just a primary key it is basically never possible to do that without intensive scripting and still that's not save, more than one record might apply for a rule. A record never can be identified by an integer "primary key" from the outside world. Using composite keys, I call them "Identifying fields", implemented on class level, where never an object can be added violating the unique key "field a and field b ...field c ... and field n" makes sure, that when importing data the decision of "update an existing record" or "add a new one" is distinct (deleting is not covered here). I use that feature basically every other day with the software I (right now | still ) earn my living with. I'm not sure how often "standard Tryton" Projects run into that problem because I am just starting with it, but: I personally think its a must have for software that wants to replace existing solutions or whenever you have to import data (on a larger scale). My idea of implementing it on the top level would be a argument for fields like "identifying = True". Regards Jakob Coeps Consulting
