Hallo,
ich experimentiere gerade mit meiner ersten Extension. Dabei sollen Mitarbeiter und deren Hobbies verwaltet werden (1:N-Beziehung). Die Arbeiten im Kickstarter (2 Tabellen anlegen, Database Relation setzten, ...) hat soweit gut funktioniert. Auch das Anlegen und Zuordnen von Mitarbeiter- und Hobby-Datensätzen funktioniert einwandfrei. Der Kickstarter erzeugt auch schon automatisch eine Frontend-Ausgabe der Tabelle Mitarbeiter. Diese Ausgabe hat mich jedoch zum Erstaunen gebracht, da die Beziehungen eines Mitarbeiters in einer Kommaseparierten-Liste (MySQL-Datentyp BLOB) abgelegt sind. Was haben sich die Entwickler dabei gedacht??? Die Tabelle ist damit noch nicht einmal in der ersten Normalform (Vorderrung nach atomaren Attributen).
Normalerweise würde man bei einer 1:N-Beziehung den Primärschlüssel der 1 Seite als Fremdschlüssel auf der N Seite eintragen. Dann könnte man z.B. abfragen, welche Hobbies der Mitarbeiter mit der id=1 hat:
SELECT h.hobbies
FROM Mitarbeiter m, Hobbies h
WHERE m.id = h.mitarbeiter_id //join
AND m.id = 1;
Der Join ist so aber bei BLOB nicht möglich.
Z.Z. erzeugt Typo für einen Datensatz vereinfacht folgende Ausgabe
Maier 1,4,6
Müller 1,3
wobei die Zahlen hinter den Namen die id`s der zugeordneten Hobbies sind (BLOB).
Wie kann ich nun Mitarbeiter mit ihren Hobbies ausgeben? Also so:
Maier Volleyball, Badminton, Biken
Hallo,
das nennt man historisch gewachsen. aber du kannst problemlos im kickstarter bei der relation die mm-checkbox aktivieren, dann wirst du zufriedener sein
Danke für die schnelle Antwort.
Das man bei einer 1 zu viele Beziehung
viele zu viele aktivieren muss ist nicht unbedingt selbsterklärend 😃
man muss es auch nicht, aber es erleichtert einem das leben. und eine 1:N-beziehung ist ja eigentlich nur eine spezielle form einer N:M beziehung...
Ammand, ich habe deine Antwort nicht verstanden.
"... eine 1:N-beziehung ist ja eigentlich nur eine spezielle form einer N:M beziehung... ???"
Bei einer n:m- Beziehung benötigt man eine Beziehungstabelle, in die zumindest die beiden PK's als Attribute eingetragen werden müssen (jeweils als FK, zusammengesetzter PK).
Bei einer 1:n Beziehung gibt es (normalerweise) keine Verknüpfungstabelle.
du denkst zu technisch...
anton schrieb
Bei einer 1:n Beziehung gibt es (normalerweise) keine Verknüpfungstabelle.
du sagst es ja schon: normalerweise...
normalerweise wird das so gehandhabt, weil man damit auf eine verknüpfungstabelle verzichten kann. dennoch kann man es ganz gut auch mit einer verknüpfungstabelle lösen. in diesem fall hast du eine n:m-beziehung, bei der n=1 ist. also ist doch eine 1:n beziehung nur ein spezialfall einer n:m-beziehung. ob man dann diese relationen mit einer verknüpfungstabelle oder nicht implementiert, ist nur eine frage der umsetzung.
Da typo3 bereits viele funktionen für n:m-beziehungen bereitstellt, hat dir georg (just2b) ja auch empfohlen, die entsprechende checkbox im kickstarter zu aktivieren. typo3 interessiert es dabei nicht, ob es jetzt bei der n:m beziehung n=1 oder n>1 ist... 😉
ich glaube, dass ich sehr strukturiert denke.
deshalb bin ich auch java und nicht php-entwickler.
ups... mal schauen, wie die php-ler reagieren 😃
übrigens, mit typo3 n:m beziehung kann ich leben,
auch wenn man sie zur 1:n beziehung missbrauchen muss.
du kannst mit PHP genauso gut objektorientiert programmieren.
ich könnte jetzt kontern: java? das ist sowieso nur ne anfängersprache... 😉
aber back to topic!
jede 1:m- oder n:1-beziehung ist nur eine spezielle form einer n:m-beziehung. wie man diese dann umsetzt, ist jedem freigestellt. im allgemeinen wird es so gehandhabt, dass man bei einer 1:m- oder n:1-beziehung auf die verknüpfungstabelle verzichtet. doch wer sagt, dass das so sein muss? ich kann diese beziehungen genau so mit einer verknüpfungstabelle abbilden, das ist mir doch freigestellt!
was ich damit sagen will: 1:m-beziehung heisst nicht, dass ich die fremdschlüssel einer tabelle in einer anderen tabelle direkt referenziere. diese schlussfolgerung ist ein trugschluss (auch wenn es der einfachkeit halber meistens so gelöst wird)!