Hi,
Es sprach Adam Jones: > Jan Niklas Fingerle wrote: >> > it's >> > not even usable for referential integrity AFAIK. >> >> I fail to see, why you shouldn't be able to have a primary or unique >> key on (a,b,c) and a foreign key to a different table on (a,b). Please >> explain. > > If a table requires three keys to guarantee uniqueness, and you only > use two in a foreign key, that relationship does not have referential > integrity. now, this is the other way round of what I spoke of. Diez wanted to have a 1:n relationship. Let's consider Tables A: (a,b,c) where (a,b,c) is the primary key, some Table B (id, a, b) where (id) is the primary key and some Table C (a,b) where (a,b) is the primary key. Case 1: Foreign Key B->A ======================== Yes, you cannot have this foreign key, because the referential integrity is broken. Imagine there was a foreign key anyway - with the Data A:([1,2,3],[1,2,4]) and B:([5,1,2],[6,1,2]) you'd have an n:m relationship, so this cannot be what Diez spoke of. BTW: Just drop the notion of a foreign key and you can use this relationship in SQLAlchemy whithout any problem that I'm aware of. Case 2: Foreign Key A->B ======================== The other way round, the problem is the same. Since we have an n:m relationship this cannot be what Diez spoke of. Case 3: Foreign Key A->C ======================== This is what I spoke of and which is perfectly valid. We have a 1:n relationship, so I assumed this is what Diez was talking about. Case 4: Foreing Key C->A ======================== This, or course, is the same mess as cases 1&2. Just use case 3 and you are there. If anybody believes this to be a valid case, please show me an example... So, the question is, what direction the foreign key is pointing. For 1:n relationships this must be case 3, so no problem there. Cases 1&2 are n:m relationships. Of course you cannot have referential integrity on n:m relationships. So what, you can use this relationship in SQLAlchemy anyway. Now, I'd like to know what Diez really meant. I still fail to see a *problem* in itself as well as in relation to SQLAlchemy. > Imagine a library that is organized by aisle, section, and > shelf. This is your primary key? This would be a library in which on every aisle/shelf there would be (at most) one book of each section. I'd rather not imagine it any further. > Then imagine having someone only give you the aisle and shelf > and telling you to go put books away. I understand what you're aiming at, but you don't disagree with my "case 3" which is all that I spoke of in my previous mail. Cheers, --Jan Niklas -- Diese Mail habe ich mit SquirrelMail versandt. Sie ist deshalb nicht mit GPG signiert. Eine unsignierte Mail - auch diese - kann prinzipiell sehr leicht gefälscht werden. Bitte prüfe / prüfen Sie daher bei Bedarf durch persönliche Rückfrage o.ä., ob diese Mail tatsächlich von mir stammt. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
