mysql compound primary key
xdfk 10.01.2004 - 17:17 785 5
xdfk
pädagogisch wertvoll
|
wieder mal ein kleines mysql problem.... At least one primary key is compound (i.e. consist of more then one attribute) teil der angabe unseres profs fuer eine beliebiges beispiel das wir in mysql implementieren sollen. natuerlich hab ich die angabe immer ueberlesen und muss jetzt im nachhinein eine sinnvolle verwendung von einem compound primary key finden ich hab als beispiel eine kleine foren db angefangen zu basteln tables: forums, threads, articles, users bei users hab ich mir gedacht koennt ich als compound ja unick und uemail als primary key machen. wuerde sinn ergeben weil unick &uemail zusammen eine unique identity ergeben wuerden.(vorher hatte ich einfach uid als primary key was ja recht logisch und einfach ist) kann ich einfach uid, unick, uemail als compound key definieren und macht das noch sinn? weil eigentlich wuerde ja uid reichen. uid verwend ich noch in den anderen tables um einen thread/article einem user zuordnen zu koennen.... bzw wie verwend ich jetzt dann den compound key? ich kann ja nimmer einen article der uid zuordnen sondern der muesste ja dem compound primary key von users (unick&uemail) zuzuordnen sein. fragen ueber fragen oder hab ich den sinn von einem compound primary key falsch verstanden.
|
atrox
in fairy dust... I trust!
|
eine gute verwendung für zusammengesetzte primäre schlüssel ist zb die auflösung einer n:m beziehung.
|
xdfk
pädagogisch wertvoll
|
eine gute verwendung für zusammengesetzte primäre schlüssel ist zb die auflösung einer n:m beziehung. bitte bitte fuer datenbanken anfaenger genauer erklaeren. bzw in bezug auf mein beispiel erklaeren? naechstes problem: habe als primarey key (uid,unick,uemail) definiert nur jetzt funktioniert das auto increment bei uid nimmer. oder incrementiert er uid jetzt nur wenn er auf 2 benutzer mit selbem unick und uemail trifft? (waer absoluter bloedsinn)
Bearbeitet von xdfk am 10.01.2004, 19:11
|
Rektal
Here to stay
|
Eventuell hast du vergessen auto_increment extra fuer die Spalte anzugeben? Wenns angegeben ist, inkrementiert es immer bei einem INSERT (ausser du gibst den jew. Spalte selbst an)
|
xdfk
pädagogisch wertvoll
|
Eventuell hast du vergessen auto_increment extra fuer die Spalte anzugeben? Wenns angegeben ist, inkrementiert es immer bei einem INSERT (ausser du gibst den jew. Spalte selbst an) keine ahnung wo der fehler lag hab das aber schon geklaert. hab jetzt den compound primary key ueber uid unick und uemail. verwend das ding aber nimmer weiter. auto_increment funktioniert jetzt seltsamerweise wieder. naja falls irgendwer trotzdem zeit hat mir ein beispiel fuer den compound key genauer zu erklaeren.. oder vielleicht hat ja irgendwer einen guten link zum thema. thx anyway
|
atrox
in fairy dust... I trust!
|
ich versuche es mal am beispiel deiner foren-db zu erklären:
es gibt viele thread, es gibt viele user: ein user kann auch viele threads gestartet haben, aber ein (bestimmter) thread kann nur von einem user gestartet worden sein - eine klare 1:n beziehung
was aber, wenn ich festhalten möchte, welcher thread von wem gelesen wurde? es kann sowol ein thread von mehreren usern gelesen worden sein, als auch jeder user kann beliebig viele threads lesen - eine n:m beziehung.
so ein fall wird in relationalen datenbanken für gewöhnlich mit einer zwischentabelle in zwei 1:n beziehungen aufgelöst: dh. ich mache eine neue tabelle, mit thread_id und user_id, beide als schlüssel. auf die weise, kann ich für jeden gelesenen thread einen datensatz erstellen, der thread_id und user_id als gemeinsamen schlüssel beinhaltet. zusätzlich kannst du noch attribute wie last_read oder ähnliches aufnehmen. du kannst jetzt mit je einem join bei der abfrage feststellen, welcher user welche threads gelesen hat, als auch zu jedem thread feststellen von welchen usern sie gelesen worden sind.
PS: zum thema relationelle datenbanken, 1, 2, und 3te normalform gibt es AFAIR einen link im Tutorial Thread.
|
Anmeldung