TYPO3 Mailingliste: nicht fragen - lesen!

Hallo!
Ich habe mal eine Frage zu Relationen und wie sie in Typo3 als Tabellen
verwaltet werden.
Die Frage, warum 1:n-Relationen nicht "vernünftig" normalisiert in Typo3
verwendet werden, habe ich hier schon gelesen
(http://lists.netfielders.de/pipermai...er/038321.html),
allerdings würde mich interessieren, ob das mit IRRE nicht doch geht.

Im Wiki zu IRRE wird z.B. eine entsprechende TCA-Konfiguration für
normale Fremdschlüsselbeziehungen beschrieben:
http://wiki.typo3.org/index.php/Inli..._Foreign_Table

Hier
http://wiki.typo3.org/index.php/Inli...ent_To-Do-List
steht auch der folgenden Satz:
"OK handle 1:n with pointer field on foreign table ("foreign_field")"

Weiß jemand, ob das entsprechend damit funktioniert?

Ich möchte nicht zwingend IRRE nehmen, aber wenn dies die einzige
Möglichkeit ist, normalisierte Tabellen für 1:n-Beziehungen zu
verwenden, dann mache ich das entsprechend.
Ich finde es auch erstaunlich, dass dieses "Problem" sonst nicht
besonders relevant zu sein scheint. Es ist ja gut, wenn sich das
Framework um die Datenhaltung kümmert, aber wenn man bei einem solch
grundlegenden Anspruch an die Grenzen stößt, finde ich das
bemerkenswert, zumal es für mich schon einen Unterschied macht, ob ich
40 oder 60 Tabellen verwende(n muss).

Vielen Dank!

Michael


P.S.: Kann es sein, dass das Archiv bei netfielders nicht vollständig
ist oder wurde folgender Beitrag zurückgezogen?
news://news.netfielders.de:119/mailm...netfielders.de
(Ich hoffe, man kann diesen Link entsprechend öffnen.)
_______________________________________________
TYPO3-german mailing list
TYPO3-german (AT) lists (DOT) netfielders.de
http://lists.netfielders.de/cgi-bin/...o/typo3-german

_______________________________________________
TYPO3-german mailing list
TYPO3-german (AT) lists (DOT) netfielders.de
http://lists.netfielders.de/cgi-bin/...o/typo3-german

> Notwendig deswegen, weil in diesem Feld festgehalten wird, wie oft dieses
> Element im Moment mit anderen verknüpft ist. Diese Zahl wird nämlich in
> verschiedenen Bereichen des BE verwendet, damit der Nutzer erkennen kann, ob
> das Element noch anderweitig benutzt wird, oder ob er es bedenkenlos löschen
> kann.

Hm, mal abgesehen davon, dass man die Zahl der verknüpften Elemente
sicher auch durch ein select count() herausbekäme (was
performancetechnisch natürlich etwas langsamer wäre), störe ich mich
auch gar nicht so an diesem zusätzlichen Feld.
Etwas unglücklich finde ich eher, dass die Relation auf der "falschen"
Seite in Form einer kommaseparierten Liste gespeichert wird, anstatt ein
Fremdschlüsselfeld zu verwenden. Dafür gibt es meiner Ansicht nach nicht
wirklich eine schlüssige Begründung und schneller geht das Daten Holen
dadurch bestimmt auch nicht.

> Dieses Verhalten zu umgehen wäre daher wenig sinnvoll.

Da hast du wohl Recht.
Da werde ich wohl in den sauren Apfel beißen und fleißig
Zwischentabellen anlegen (lassen).
_______________________________________________
TYPO3-german mailing list
TYPO3-german (AT) lists (DOT) netfielders.de
http://lists.netfielders.de/cgi-bin/...o/typo3-german

_______________________________________________
TYPO3-german mailing list
TYPO3-german (AT) lists (DOT) netfielders.de
http://lists.netfielders.de/cgi-bin/...o/typo3-german

> Die CSV Variante ist ja nicht zwingend vorgeschrieben, wenn auch weit
> verbreitet.

....und die, die der Kickstarter verwendet, wenn ich die Checkbox bez.
m:m-Table nicht anklicke.

> Du kannst das Ganze ja auch für 1:n über eine MM Tabelle machen.
> Und IMHO macht auch das wieder Sinn, denn sonst müsstest Du für jede
> mögliche Verknüpfung zwischen Elementen verschiedener Tabellen ein eigenes
> Fremdschlüssel Feld anlegen

....was für normalisierte Tabellen die gängige Vorgehensweise ist.
Die Beziehung zwischen pages und tt_content ist ja auch so gelöst, also
so anwegig ist das ja nun wirklich nicht.
Der Unterschied zwischen einem zusätzlichen Feld und einer zusätzlichen
Tabelle ist aber schon eklatant, zumal das eben noch einen weiteren Join
kostet. Bei komplizierteren Beziehungen kostet das halt einfach
Performance. Dass es das Modell unübersichtlicher macht, mag für einen
Entwickler jetzt nicht ganz so entscheidend sein, aber ich finde es
mitunter schon ganz nett, wenn ich das Modell auch noch anhand der
Tabellen leicht verstehen kann.

> (oder die Fremdschlüssel in eine CSV Liste
> schreiben), was entweder die Tabellen von der Anzahl der Felder her unnötig
> aufblasen oder das ursprüngliche Problem wieder aufwerfen würde.

Das wär ja nun wirklich evil.

> Die Lösung über uid_local, uid_foreign und tablenames ist daher der
> sinnvollste Kompromiss.

Ansichtsache, aber ich unterwerfe mich natürlich dem Framework. ;-)

> IRRE hätte hierbei noch den Vorteil, daß MM tables
> weitere Felder enthalten dürfen, die für FE oder BE output eingesetzt werden
> könnten.

Damit werden sie quasi zur eigenen Entität und man hat zwei "echte"
1:n-Beziehungen. Nicht, dass mich das stört (das will ich ja
eigentlich), aber wirklich konsequent ist das nicht.
_______________________________________________
TYPO3-german mailing list
TYPO3-german (AT) lists (DOT) netfielders.de
http://lists.netfielders.de/cgi-bin/...o/typo3-german