mysql compound primary key

Seite 1 von 1 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/mysql_compound_primary_key_103683/page_1 - zur Vollversion wechseln!

xdfk schrieb am 10.01.2004 um 17:17

wieder mal ein kleines mysql problem....

Zitat
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 schrieb am 10.01.2004 um 18:36

eine gute verwendung für zusammengesetzte primäre schlüssel ist zb die auflösung einer n:m beziehung.

xdfk schrieb am 10.01.2004 um 18:47

Zitat von atrox
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)

Rektal schrieb am 10.01.2004 um 20:54

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 schrieb am 10.01.2004 um 22:41

Zitat von Rektal
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 schrieb am 11.01.2004 um 00:02

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.