|
Verfasst am: 11. 10. 2011 [11:21]
|
|
jank
Themenersteller
Dabei seit: 01.04.2009
Beiträge: 147
|
Hallo zusammen,
ich stehe gerade vor einem kleinen Problem:
Ich habe 2 Domain Models:
Projekt
Person
Jedoch hat das Model Projekt 2 n:m Beziehungen zum Model Person:
Projekt.Manager n:m Person
Projekt,Mitglieder n:m Person
Das ist so aufgebaut da die Personen mal die eine mal die andere Rolle übernehmen manche jedoch immer nur die selbe.
Nun ist mein Problem im PersonRepository die Personen zurückzugeben welche wirklich Projekt.Manager z.B wirklich Projekt.Mitgieder sind.
Gelöst habe ich das momentan über eine verschachtelte SELECT Abfrage als query->statement.
$query->statement('SELECT * FROM tx_project_domain_model_person WHERE uid IN (SELECT uid_foreign FROM tx_project_project_manager_person_mm)');
$query->statement('SELECT * FROM tx_project_domain_model_person WHERE uid IN (SELECT uid_foreign FROM tx_project_project_member_person_mm)');
Dieses Vorgehen hebelt natürlich die Datenbank-Abstraktion aus.
Kennt jemand eine "bessere" Lösung dieses Problems?
gruß jank
|
|
Verfasst am: 21. 10. 2011 [08:24]
|
|
oliver_g
Dabei seit: 30.05.2011
Beiträge: 71
|
Wozu immer dieses "akademische" Feature der Datenbankabstraktion mit rumschleppen? Wie oft kommt es vor, dass man einfach mal so das Datenbanksystem (z.B. von MySQL zu Oracle) ändert? Wer braucht so was eigentlich in der Praxis?
Wenn du also nicht speziell ein Datenbank-Meta-System, welches mit verschiedenen DB Anbietern umgehen können soll, entwickelst, brauchst du diese "Abstraktion" nun wirklich nicht.
Wichtig ist, dass du das Problem lösen konntest.
Gruß
|
|
Verfasst am: 24. 10. 2011 [11:21]
|
|
jank
Themenersteller
Dabei seit: 01.04.2009
Beiträge: 147
|
Hallo oliver_g,
es geht ja nicht immer nur um die Lösung, sondern um den Lösungsweg...
Ich dachte vielleicht gibt es eine konforme Lösung die mir nicht eingefallen ist... aber vermutlich (noch) nicht.
Aber du hast schon recht, es wird selten vorhommen, dass eine anderes Datenbanksystem zum Einsatz kommt.
Jedoch muss man dies in Betracht ziehen, vorallem, wenn die Extension ins TER veröffentlicht werden soll.
Ich habe auch schon an ein zusätzliches Model wie bei dem Beispiel aus dem Buch "Zukunftssichere TYPO3-Extensions mit Extbase & Fluid" CD-1:n-Track-n:1-Musikstück gedacht...
Projekt-1:n-Funktion-n:1-Person... das ist aber auf Grund der nur 2 verschiedenen Funktionen einer Person einfacher über 2 n:m Beziehungen zu lösen gewesen, vorallem wenn diese im Frontend aktualisiert werden sollen.
Mal schauen vielleicht werde ich das noch mal versuchen.
Gruß
gruß jank
|
Verschachteltes SELECT Statement -> bessere Lösung
