Druckbare Version
Hi allerseits,
ich wollte eigentlich nur mal wissen ob es zu TYPOlight ein schönes, visualisierendes ER-Modell gibt, z.B. für die MySQL Workbench. Ich kann mir die Fremdschlüssel Beziehungen zwar oftmals denken, aber wenn es da schon was zur Ansicht gäbe ...
Danke und Grüße aus Düsseldorf
:)
Alles klar, danke für die Antwort. Stimmt schon, die Beziehungen sind meist nur auf pid beschränkt, trotzdem wäre es nett gewesen mal so eine gesamt Übersicht zu haben, aber egal.
Und wieso genau begründet eine ID-PID-Verknüpfung keine Untertabelle im Sinne eines normalisierten DB-Entwurfes?Zitat:
Zitat von leo.unglaub
Ich glaube, da kommt die Redundanz ins Spiel!
Ich weiß nicht welche Erfahrungswerte es da in Bezug auf sehr große Datenbanken gibt, aber ich kann mir gut vorstellen, dass es ab einer bestimmten Größe durchaus Probleme verursachen könnte, viele Einträge mit Bezug auf unterschiedliche Tabellen in eine Tabelle zu schreiben.
Ich hoffe, ich konnte mich einigermaßen ausdrücken.
Ich fände aber auch interessant mal das ER-Model zu sehen, da man so die Beziehungen zwischen den Einzelnen Tabellen besser verstehen lernen kann.
Ich glaube er sieht die erste Normalform schon verletzt durch einige recht große Relationen, die man ggf. noch weiter unterteilen könnte. In sehr großen Datenbanken fallen dadurch halt oft ein paar mehr Fremdschlüssel Beziehungen ab. Aber da ich im Kurs "Datenbank Systeme" eh nicht der Überflieger war schweige ich hier mal lieber ;-)Zitat:
Zitat von leo
Hi alle,
Selbstverständlich sind die vielen ID-PID-Verknüpfungen ganz "klassische" 1:N Beziehungen, vorausgesetzt PID in Tabelle A verweist immer auf die ID in Tabelle B, und nicht manchmal auf die ID in Tabelle C (gesteuert durch ein anderes Feld in A z.B. Ob das in TL so sein kann, überblicke ich im Moment nicht, ich glaube aber nicht, siehe auch DCA ptable bzw ctable). Allein für die vielen 1:N Beziehungen in TL würde sich ein DB-Modell lohnen. Ich denke, ich werde mich bei Gelegenheit mal daran setzen, eines zu machen, zumindest für den Core 2.8.x. Dazu würde ich DBDesigner benutzen, das XML als Dateiformat benutzt.Zitat:
Zitat von leo
Parent:Child 1:N wird von DC_Table auch voll und ganz unterstützt. Parent:Child:Grandchild weitestgehend wohl auch (mit kleinen Tricks), soweit ich das verstanden habe.
Nicht "klassisch" gelöst sind N:M Beziehungen. Beispiel User und UserGroup, jeder Benutzer kann in 0 bis vielen Gruppen sein, jede Gruppe kann 0 bis viele Benutzer haben. Klassisch hätte man eine Hilfstabelle zwischen beiden (mit je einer PID auf tl_user und einer PID auf tl_user_group und eventuell weiteren Attributen, die spezifisch für die Zuordnung sind).
TL löst das aber so, dass es bei tl_user im Feld 'groups' ein serialisiertes Array mit den IDs der Gruppen ablegt. Vorteil: man spart sich "komische" Hilfstabellen; Nachteil: man kann nicht mehr per SQL SELECT... JOIN auswerten. Hat man einen Benutzer an der Hand, dann kann man schnell seine Gruppen-IDs herausfinden, muss dann aber Gruppen-Attribute mit einem weiteren SELECT beschaffen. Hat man umgekehrt eine Gruppe an der Hand und will z.B. die Benutzer listen, dann muss man sämtliche Benutzer aus der DB holen und deren 'groups' Feld untersuchen.
Für ein Datenmodell wäre aber dieses Implementations-Detail nicht interessant, sondern die Tatsache der N:M Beziehung.
Edit: werde wohl doch die MySQL Workbench (Nachfolger von DBDesigner) nutzen ... das letzte mal, als ich danach gesehen hatte, war die noch weit weg von benutzbar, aber sie scheint inzwischen echt brauchbar, oder?
LG, Georg
Das denke ich doch auch :)Zitat:
Zitat von deerwood
Auch ohne Tricks: parent.id = child.pid und child.id = grandchild.pid.Zitat:
Zitat von deerwood
Ja, auch das stimmt. In TYPOlight 3 wird das voraussichtlich anders gehandhabt werden. In der Zwischenzeit kann man sich zumindest für "suche alle Benutzer der Gruppe 8" mit folgendem Workaround behelfen:Zitat:
Zitat von deerwood
PHP-Code:$this->Database->execute("SELECT * FROM tl_user WHERE groups LIKE '%\"8\"%'");
Moin,
Siehe das englische Forum, da geht es um parent/child/grandchild und den Back-Button von grandchild zu child (bei sort mode 4 für Kinder/Kindeskinder). Vielleicht hast Du ja eine bessere Lösung als den "clever trick" von Helmut?Zitat:
Zitat von leo
Danke für den Workaround und die Info, vorraussichtlich anders meint dann eher klassisch (eventuell mit nur einer einzigen Hilfstabelle für sämtliche N:M-Beziehungen)?Zitat:
Zitat von leo
LG, Georg
Moin Thomas,
Hmm, alles was ich bisher vom TL Core gesehen habe, hatte keine redundante/wiederholende Speicherung von Werten (mit den daraus folgenden, möglicherweise fatalen, Folgen, z.B. bei Löschung eines Datensatzes). Nun soll dies kein DB Kurs sein und ich nehme an, dass die meisten Leser hier halbwegs mit relationalen DBs und ihrer Normalisierung vertraut sind, dennoch, für die, die es wissen wollen (an einem Beispiel):Zitat:
Zitat von Thomas
Nehmen wir an, wir haben Kunden und deren Aufträge (1:N). Naiv (so als typischer Excel-Nutzer) würde man eine einzige Tabelle anlegen, in der man Spalten sowohl für den Kunden, wie auch seine Aufträge anlegt (z.B. Kd-Nummer, Kd-Name usw. und Auftrag-ID, Auftrag-Datum, Auftrag-Summe). Sieht erst mal OK aus, in Excel kann man ja leicht nach allen Spalten sortieren und was schadet schon die mehrfache (redundante) Speicherung ein und der selben Kunden-Daten, sobald er einen zweiten Auftrag plaziert ... kurz umsortiert und per Copy/Paste die Daten nachgetragen. Fein ist auch, dass man das sofort übersichtlich auswerten/filtern kann.
Bei Adress-Änderung wird es schon ein wenig anstrengend, man darf nicht vergessen, die Kunden-Daten in ALLEN Zeilen zu ändern. Sortieren/Filtern und Copy/Paste hilft hier immer noch, wenn man denn daran denkt.
Nun storniert ein Kunde einen Auftrag. Klar, einfach die Zeile mit dieser Auftrags-Nummer löschen und alles ist wieder im Lot? Weit gefehlt! Nichts ist im Lot, falls der stornierte Auftrag der einzige Auftrag des Kunden war ... dann sind auch sämtliche Kunden-Daten verschwunden (Ansprechpartner, email usw).
Sowas habe ich im TL Core bisher nicht feststellen können. Entities/Objekte (also Kunde bzw. Auftrag aus dem obigen Beispiel) werden fein säuberlich getrennt in ihren eigenen Tabellen verwaltet, falls ein Kunde einmal existiert hat, dann wird er NICHT gelöscht, auch wenn sein letzter Auftrag gelöscht wird (warum auch immer, z.B. archiviert).
Ich befürchte, ich habe NICHT ganz verstanden, was Du hier meinst. Falls Du die Anzahl von Datensätzen in einer oder mehreren Tabellen meinst (auch mit JOIN oder LEFT JOIN): selbst bei Millionen von Datensätzen schmunzelt MySQL vielleicht mal kurz und liefert dann alle Ergebnisse SEHR viel schneller, als PHP damit umgehen kann (vernünftige Indizes vorausgesetzt).Zitat:
Zitat von Thomas
LG, Georg
Also ich nutze die MySQL Workbench erst seid kurzem, machte mir aber soweit einen sehr soliden Eindruck.Zitat:
Zitat von deerwood
Ich glaube es geht nicht nur unbedingt um Redundanz. Wenn ich mich richtig erinnere, zerlegt man z.B. User Tabellen auch noch einmal Themen spezifisch (Adresse, Kontaktdaten, Einstellungen ...), denn es wird ja z.B. nicht jeder Bereich zwingend ausgefüllt sein, es gibt z.B. nicht jeder seine Adresse an. Eine Relation "user_adressen" würde dann nicht proportional zur Relation "user" anwachsen und wäre (bei seehr vielen Usern) ggf. einfacher/schneller zu durchsuchen und die Tabelle "user" würde dadurch entlastet werden. Sollte man unbedingt alles in einer Relation haben wollen, kann man dafür doch immer noch ne View anlegen.Zitat:
Ich glaube, da kommt die Redundanz ins Spiel!
Aber wirklich lohnen tut sich der Aufwand wohl nur bei Tabellen die extrem (sozusagen gigantisch X-) ) groß werden. Für eine Tabelle wie "tl_modul" würde es sich wohl eher nicht lohnen, die Anzahl der Einträge sollte ja eher überschaubar bleiben.
Guten Morgen!
Ja, genau dahin geht meine bescheidene Befürchtung.
Aus der Praxis heraus weiß ich, dass Tabellen mit sehr viel Text, z.B. Beschreibungen, in einem Suchmodul zu unschön langen Abfragen führen können, ja sogar zum Abbruch der Aktion, wenn entweder der Server nicht dem entsprechend konfiguriert wurde oder aber die DB Struktur nicht vernünftig mit Indizies usw. versehen sind.
Da nicht alles das Wissen haben, könnte es da zu Unstimmigkeiten und Unmut führen.
He ich mische mich mal etwas ein...auch wenn ich nicht der extreme Profi bin, aber ich bin hier drüber gestolpert, als ich zwecks child.pid = parent.id gestolpert bin und für mein "vorhaben/auftrag" leider garnichts bringt, denn dann müsste ich meine zusätzliche Tabelle zu sehr splitten...und das gefällt mir vom design nicht wirklich ;)!
@Thomas ich kann es nur bestätigen, das ein langes query nicht unbedingt langsam sein muss, es kommt ja auch auf die Art drauf an. Ein stinknormales Select * from ... ist schneller, als wenn ich am ende noch ein where, like oder limit benutze. in deinem beispiel kommt es ja auch sehr darauf an, wie du deine Suche aufbaust. Denn du kannst die DB belasten oder ihr auch arbeit abnehmen. Ich hoffe ich sage jetzt nichts falsches aber ich kenne es noch, das bei großen Mengen Inhalt, ein like tödlich sein kann...
aber danke, auch wenn es nur ansatzweiße darum ging was ich brauchte konnte ich aus dem verlauf die benötigten infos holen ;)!
Moin,
ein erster Eindruck, wie das TYPOlight Datenmodell mit Hilfe der MySQL Workbench aussehen kann:
https://community.contao.org/de/atta...4&d=1269064458
Bei diesem Screenshot schwebte meine Maus über 'tl_article', die farbigen Hervorhebungen macht dann die Workbench. Ich habe natürlich nicht all die 34+10+56 "more" Spalten manuell eingegeben (und auch nicht die mehreren Hundert Spalten in den nicht gezeigten 31 weiteren Tabellen), das kann die Workbench dann schon selbst via "Reverse Engineering" (hier via PHPMyAdmin Export als SQL-Script ohne Daten).
Aber, zumindest auf diesem Weg, sind keinerlei Relationen im Modell vorhanden (die Striche 1:N zwischen den Tabellen-Kästen). Das musste ich dann selbst machen (mühsam, fehlende Features in der Workbench oder Unverständnis meinerseits).
Die PHP/serialized Array Handhabung von N:M in TYPOlight muss ich auch noch in den Griff bekommen. Die Workbench geht natürlich von "klassischer" Modellierung aus. Dazu lasse ich mir was einfallen und werde das demnächst mal vorstellen.
Recht unzufrieden bin ich mit dem "Autoarrange" der Workbench, soweit ich das bisher getestet habe ... im Moment rate ich davon ab, sie vermarmelt mir jedes manuell erzeugte Layout zu "schlicht unbrauchbar". Da habe ich vor Jahren schon besseres gesehen ... aber ich bin auch noch nicht fertig mit den Tests.
Dennoch: im Moment sieht es so aus, dass ich sämtliche 34 core Tabellen von Hand positionieren muss (und in Layer packen usw). Wird also echt mühsam werden.
LG, Georg
Hi,
Ja, das war mir im Wesentlichen klar, vor allem für N:M. Eigentlich wollte ich meine Meldung als Erfolg und Lob für die WB verstanden wissen :D . Sie nimmt mir immerhin die immense Fleissarbeit ab, sämtliche Tabellen/Felder korrekt zu erfassen! Mein "mühsam" bezieht sich darauf: eine 1:N Beziehung zwischen 2 Tabellen herzustellen ist einfach (Tool wählen, 1. Klick auf die N-Tabelle, 2. Klick auf die 1-Tabelle). Aber die WB legt dann in der N-Tabelle ein neues Foreign-Key-Feld an, man kann nicht etwa beim 1. Klick das Feld "pid" wählen um zu bewirken, dass es der Foreign Key wird. Das muss man dann mühsam von Hand korrigieren (in der N-Tabelle den Tab "Foreign Keys" aktivieren, beim neu angelegten FK "pid" anwählen und das neue Feld abwählen, den Tab "Columns" aktivieren und dort das neue Feld wieder löschen).Zitat:
Zitat von leo.unglaub
Edit: "Unverständnis meinerseits". Wie peinlich (immerhin hatte ich es geahnt). Die Workbench KANN genau das, was ich im letzten Absatz angemeckert hatte. Seht den Screenshot oben und wählt das Tool 1:N mit der Pipette (ganz links unten). Das macht genau das, was ich will ... und besser, als ich es hätte vorschlagen können! Faszinierend.
Das sehe ich anders ... und MySQL wohl auch. Zitat (Forward and Reverse Engineering):Zitat:
Zitat von leo.unglaub
Auch lesens/erprobenswert ist das "Change Management" auf der verlinkten WB Seite.Zitat:
... MySQL Workbench also enables you to reverse engineer an existing database or packaged application to get better insight into its database design. ...
Nochmals: ich bin guten Mutes und bisher mit der WB (5.2.16 OSS Beta) sehr zufrieden; sie ist inzwischen besser, als der DBDesigner. Dennoch wird es eine Weile dauern, bis das Modell komplett fertig ist.
LG, Georg
Moin,
Hier der Link zur Seite mit einem Feature-Vergleich zwischen FreiKommerziell. Der freien Version fehlt echt nicht viel, jedenfalls hat sie Reverse Engineering und auch Change Management.Zitat:
Zitat von leo.unglaub
LG, Georg
Oha, da hat sich was geändert.
RE über SQL Script ging ja schon länger, aber das die nun auch direkt mit der Datenbank sich verbinden kann dabei, ist für mich neu, meine Version kann das nicht.
Werd ich wohl mal ein Update machen / neue Version installieren.
Moin alle,
ich habe hin und her überlegt/probiert, wie ich N:M "the TYPOlight 2.x.x way" in der MySQL Workbench gut darstellen kann. Ich falle aber immer wieder zurück auf die "klassische" Art und Weise mit "komischen" Hilfstabellen:
https://community.contao.org/de/atta...9&d=1269316236
Vom Sachverhalt ist das korrekt (wenn man denn physische Datenmodelle lesen kann). Schade ist, dass das Feld "tl_user.groups" (siehe den roten Pfeil, der natürlich NICHT im Modell vorhanden sein wird) nicht direkt beim :hover über der Beziehung erkennbar ist, sondern nur aus dem Namen der Hilfstabelle. Im Namen hätte ich (in der freien Version) statt des '-' auch '.' verwenden können, ich befürchte aber, dass das in der kommerziellen Version nicht validiert.
Mein Plan ist, im Kommentar zu N:M Hilfstabellen wie "tl_user-groups" die Implementation als serialized Array zu dokumentieren. Falls in anderen N:M-Beziehungen (dem jeweiligen serialized Array) weitere Eigenschaften der Beziehung gespeichert wären, würde ich wohl weitere Felder in die jeweilige Hilfstabelle aufnehmen und im Kommentar beschreiben.
Was denkt Ihr? Habe ich eventuell ein "logical" Modelling in der WB übersehen?
LG, Georg
Hmm, ich glaube nicht das du da etwas übersehen hast, die WB ist halt nun mal nur für MySqlDBs gedacht. Die Speicherung einer Array Gruppenliste in Form eines BLOBs ist da halt nicht vorgesehen, ansonsten muss man auf ein ER-Modelling Tool eines Datenbanksystems ausweichen, dass Arrays, Tabellen und Objekte innerhalb einer Relation zulässt.Zitat:
Zitat von deerwood
Ich hätte die WB wohl lieber nicht vorschlagen sollen, mir war nicht klar in wie weit TL da vom normalen Modell abweicht. Kommt die Problematik denn an vielen Stellen vor?
Zwischenfrage: Kennst du da zufällig ein paar?Zitat:
Zitat von NRWunited
Hab eben mal bei Oracle geschaut, aber auf Anhieb nur das hier gefunden:Zitat:
Zitat von FloB
Oracle SQL Developer Data Modeler
http://www.oracle.com/technology/pro...ler/index.html
Bin mir nicht sicher wie gut die Handhabung da ist. Hatte gehofft für den DBDesigner gäbe es noch ein passende Plugin, aber wie es ausschaut ist die MySql Workbench wohl der Nachfolger davon.
Bin eben noch die nette Liste hier gestolpert:
http://de.wikipedia.org/wiki/Liste_v...ungswerkzeugen
Ggf. ist da ja noch was brauchbares bei.
Ist für TL3 eigentlich so was wie Doctrine oder Propel vorgesehen?
Danke schonmal, aber meine Frage war mehr auf DB-Systeme bezogen (sorry). Gibt es da außer Oracle noch Systeme (möglichst OpenSource), die Arrays / Objekte in Feldern "anerkennen"?
Hi FloB,
Auf Anhieb fällt mir da nur PostgreSQL ein. Zitat::Zitat:
Zitat von FloB
LG, GeorgZitat:
Objektrelationale Eigenschaften: PostgreSQL erlaubt die Speicherung nichtatomarer Datentypen in Arrays oder in geometrischen Datentypen. Beides sind Erweiterungen von PostgreSQL, die nicht im SQL-Standard enthalten sind. Alle Datenbankobjekte, ob Tabelle, View, Sequenz oder einzelner Datensatz haben in PostgreSQL eine eigene Objektidentität. Außerdem wird die Vererbung von Tabelleneigenschaften auf abgeleitete Kindtabellen unterstützt.
Hi NRWunited,
Doch, die WB ist schon OK und die Sonderbehandlung von N:M war mir ja von vornherein klar. Wie viele Stellen es geben wird überblicke ich noch nicht, potentiell ist jedes BLOB Feld ein Kandidat für "irgend etwas Komisches", weil sie meist für die Speicherung serialisierter Werte genutzt werden. Was dann darin wirklich steht und welche Bedeutung für das Datenmodell sich ergibt werde ich aus dem Code herausfinden müssen. Denkbar wäre z.B. auch ein Array mit Werten zum Füllen einer Selectbox, "klassisch" wäre das eine 1:N Hilfstabelle. Ich werde mich nach und nach durcharbeiten.Zitat:
Zitat von NRWunited
LG, Georg
Wie oben schon erwähnt bin ich kein Experte was DBs angeht, hatte nur im Hinterkopf das entsprechende objektrelationale DBMS gibt, die Tabellen, Arrays und Objekte als Typ akzeptieren. Was ist denn mit "PostgreSQL", gibts da nicht zumindest Array Typen? Ging mir halt nur darum, dass es dafür ggf. passende ER-Modelling Tools gibt um die TL Struktur besser abzubilden.Zitat:
Zitat von FloB
Danke deerwood, NRWunited. Hab mich inzwischen schlau gemacht – zumindest nicht assoziative Arrays sowie weitere Features, wie eine Art von Subtabellen (als Feldtyp "getarnt") und Kindtabellen, werden von PGSQL unterstützt. Feine Sachen. Ich find PostgreSQL immer interessanter :).
Aber gut, für eine ordentliche m:n-Verknüpfung sollte man wohl eher auf eine Hilfstabelle zurückgreifen. Für andere Felder in TL wäre aber so eine Subtabelle genau das richtige.
Mir fällt da spontan die memberlist mit den öffentlichen Feldern ein: Das ist eigentlich nur ein Array, das die entsprechenden Felder der tl_member enthält, die angezeigt werden. Gibt noch viele Stellen im Core, bei denen man die Arrays direkt speichern könnte. Vorteil ist, dass man auch konkreter suchen kann als bei einem serialisierten Array mit LIKE. So ein Feld in eine eigene Tabelle auszulagern ist nicht immer sinnvoll.
Datentyp Array bei PostreSQL.
Ich glaube der Grund Arrays & Co in einer DB abzulegen ist einfach nur eine vorrübergehende Lösung auf dem Weg zu rein objektorientierten Datenbanken. Wenn du als Datentyp z.B. ein geometrisches Objekt hast, wäre es ja unpraktisch dies in einem normalen Datentypen abzulegen. Also legst du es z.B. als Array-Objekt vom Typ Kreis an. Du machst da keinen gezielten Select um den Radius raus zu bekommen. Entweder kennt die DB diesen Objekt Typen und kann entsprechend damit umgehen oder die Sprache in die es überführt kennt ihn. Gerade jetzt wo HTML5 mit SVG und Canvas vor der Tür stehen, kann ich mir da sehr gute Einsatzgebiete vorstellen.Zitat:
Zitat von leo.unglaub
Moin,
in der Anlage ein allererster Stand des Datenmodells als WB Datei. Erwartet bitte noch nicht viel, ich habe mal gerade ein wenig in modules/backend hereingerochen. Was man aber schon jetzt erkennen kann (tl_content) ist, dass es MEHR 1:N Beziehungen gibt als die wenigen, die man auf Anhieb per DCA p/ctable erkennen kann. Und natürlich gibt es auch diverse N:M Beziehungen.
Ich werde jede Beziehung nach bestem Wissen/Erkenntnis kommentieren, bei der N:M Hilfstabelle (siehe Bild rechts unten) bzw. bei der 1:N Beziehung. Das lässt sich in einem einzigen Bild nicht alles zeigen, dazu muss man dann die WB installieren und die Beziehungen an- oder doppel-klicken.
Anhang 1550
Das Erkennen der zusätzlichen 1:N Beziehungen für 'tl_content' war nicht ganz leicht, es ging nur dadurch, dass ich einerseits im Backend herumgespielt habe, andererseits nicht nur alle BLOB Felder, sondern auch alle INT(10) Felder von tl_content im Code besichtigt habe. Nun ist tl_content wohl ein Extrem, ich hoffe, dass ich nicht all zu viele weitere solch schwierigen Tabellen noch vor mir habe :D .
Nebenbei habe/werde ich alle Foreign Key Attribute nach oben ziehen, so dass bei der verkürzten Darstellung in der Workbench die FKs immer sichtbar sind.
Über weitere Tipps, wie ich Beziehungen einfach erkennen kann, wäre ich dankbar. Wie etwa ein grep -i 'foreignkey' (das für tl_content allerdings die N:M Beziehung 'groups' markierte).
Dass das Reverse Engineering so mühsam ist, zeigt aber auch, wieviel Aufwand Leo in den Code gesteckt hat.
LG, Georg
Moin leo.unglaub,
Du hast Dir nun das EINZIG wirklich gute Feature von PHP herausgepickt, das ist echt gemein :D . Da kann KEINE andere Sprache native mithalten. Klar gibt es in Java/C/Perl/<whatever> Container, die ähnliches machen, aber von PGSQL kannst Du nicht erwarten, dass es all diese verschiedenen Implementationen von Hause aus unterstützt.Zitat:
Zitat von leo.unglaub
Ich finde es jedenfalls schon sehr hilfreich, wenn man nicht-assoziative Arrays direkt in der DB ablegen und IN QUERIES verwenden kann. Siehe FloBs Link zur Array-Doku weiter oben.
Aber ich nutze PGSQL zur Zeit nicht ... sollte ich mal wieder tun.
LG, Georg
Hallo,
mit welcher Version wurde die Datei erstellt?
Meine aktuell runtergeladene 5.1.18a (OSS Community Edition) sagt mir, inkompatible Version. :(
Ne 5.2.16.beta gibt auch noch sehe ich grad, wäre es die?
Nachtrag: Scheint wohl so, denn meine erzeugt eine Modell Version 1.3.1, deine eine 1.4.0.
Bestätigt, mit der 5.2.16.beta kann ich das öffnen. :cool:
Moin liebe Leser,
@BugBuster: ja, dies Modell ist für die WB 5.2.16 beta (wie oben bereits erwähnt).
Inzwischen bin ich das erste Mal durch mit system/modules/backend/* (ein zweiter Durchgang wird folgen). Und wie Ihr sehen könnt, sind reichlich neue 1:N und N:M Beziehungen dazu gekommen.
Anhang 1561
Langsam wird das Placement/Routing (die übersichtliche Darstellung der Tabellen und Beziehungen) zum Problem ... zumal noch deutlich mehr Beziehungen dazu kommen werden, wenn ich mich den weiteren Verzeichnissen in system/modules zuwende. Deshalb habe ich im Moment auch noch nicht sehr darauf geachtet. Allerdings habe ich auch schon meine bevorzugte Darstellung der Beziehungen als "Krähenfüße" angetestet ... war aber leider auch nicht überzeugend. Die WB ist bezüglich Routing echt schwach auf der Brust. Bei so komplexen Datenmodellen wünschte ich mir sowas wie das Routing für Platinen/Mainboards (2 Layer würden ja schon reichen). Interessierte Leser dürfen gern einmal selbst die Tabellen in der WB hin- und herschieben, bzw. eine andere Darstellung der Relationen wählen ... und mir Tipps zur besseren Anordnung geben :) .
Wenn das komplette Modell fertig ist, werde ich auch versuchen, Teil-Diagramme hinzuzufügen, die verschiedene Aspekte übersichtlich (reduziert) darstellen.
Ansonsten sind im Modell zu jeder Beziehung (und deren zugehörigen Feldern) Kommentare vorhanden. Falls die nicht stimmen sollten, bitte ich um Hinweise.
LG, Georg
PS: die merkwürdigen Anzeige-Namen der ZIP Dateien hier im Forum (im Moment ein verdoppelter '.' vor der Endung "zip" ) sind sicher nicht mein Problem. Die Upload-Datei bei mir heisst "xxx.zip" und nach Download erscheint sie auch wieder genau so (als "xxx.zip"). Ich befürchte, da muss die Forums-Software noch mal korrigiert werden.
Diese Aufgabe liesse sich doch zu einem Grossteil automatisieren. Du hast doch den DCA als GLOBALS, dort enthaölten alle ptable und ctables. Davon laesst sich automatish ein Grundgeruest bauen.
Nun liest du alle Namen der abellen deiner Installation aus.
SourceCode nach den Tabellennamen extrahieren -> Crawler automatisisert dies. Dabei haendisch ein Array fuellen, welches BADFiles hat. Diese aus dem Crawler herausnehmen. also DC_TABLE.php usw. Das solange crawlen, bis du eine gute Uebersicht hast, was genau passiert.
DELETE Queries von vornherein ausschliessen.
Mithilfe dieser Masken kannst du dann direkt im Code kontrollieren, was dort gemacht wird, und entsprechende Zeilen in deinem Crawler ignorieren lassen.
Das Ganze dann in dein Projekt und gut ist. So hast du die Grossarbeit erstmal nicht mehr.
Ich habe selbiges mal automatisiert fuer eine Uebrsicht meines wfm gemacht. Anzeige mittels graphviz : http://dev.typolight-forge.org/wiki/wfm
Moin lindesbs,
ich gestehe, dass ich das meiste Deiner Antwort nicht verstanden habe, magst du das nochmal für Doofe formulieren? Insbesondere:
Von welchem Crawler ist die Rede? Und Du schlägst vor, die SQL Statements zu extrahieren / zu analysieren?Zitat:
SourceCode nach den Tabellennamen extrahieren -> Crawler automatisisert dies.
Masken, die der Crawler erzeugt und mir direkt den Source Code zeigen? ist der Crawler etwas, was ich mir selbst programmieren soll (PHP oder PERL Script oder so)?Zitat:
Mithilfe dieser Masken kannst du dann direkt im Code kontrollieren, was dort gemacht wird, und entsprechende Zeilen in deinem Crawler ignorieren lassen.
Ich beschreibe noch mal kurz, wie ich bisher vorgehe:
- ich arbeite mich systematisch durch die Module (backend, frontend, dann alphabetisch)
- ich schaue zunächst in config/database.sql, um zu sehen, welche Tabellen dort definiert (mit PK) bzw. ergänzt (ohne PK) werden und dokumentiere das
- dann geht es durch dca/*, zunächst ptable und ctable,das ist einfach, aber deckt lange nicht alles ab
- in dca/* suche ich nach foreignKey, ist das Feld dazu BLOB und in eval 'multiple'=>true, dann ist das eine N:M Beziehung, deren Bedeutung kontrolliere ich im Backend bzw. suche im Code danach, um genau zu verstehen; ist das Feld int(10) und kein multiple, dann ist das eine 1:N, Codebesichtigung, falls nötig
- weitere BLOB und int(10) Felder, die nicht klar sind (ausser sowas wie etwa tstamp) vertage ich erstmal, bis ich komplett durch alle Module bin und werde mich dann im 2. Durchgang damit befassen.
Die Selbstreferenz von tl_page.pid zu tl_page.id (der Seiten-Baum) läßt sich so aber z.B. nicht aufspüren ... ist ja aber zum Glück völlig offensichtlich.
Gute Suchtools (mit regulären Ausdrücken und Context-Anzeige) habe nebenbei (grep, Eclipse, TotalCommander, PERL).
graphviz ist echt ein guter Tipp, hatte ich vor Jahren schon mal gesehen. Kann sein, dass mir das sehr beim Placement/Routing helfen könnte.
LG, Georg
Alle deine Punkte lassen sich nahezu komplett automatisieren. Ich schreibe Dir gerade ein Beispiel zusammen, wie das aussehen koennte.
Das aufwaendige ist halt spaeter, wenn im SourceCode in eigen serialisierten Arrays die Verkuepfungen zu anderen Tabellen sind.
Aber dafuer wird eine Liste erzeugt, womit man dann gezielt im SOurceCode schauen kann.
So, lade Dir mal von hier http://dev.typolight-forge.org/proje...les/tablestuff
diese Datei herunter : DBCrawler.php
Speichere sie lokal in deinem TL_ROOT/typolight Verzeichnis.
Melde dich am Backend an, und aendere dann in deiner URL das main.php auf DBCrawler.php.
Dann wird ein lesbares Abbild deiner Datenbank mit Beziehung auf deinen DCA erstellt.
Es werden die vorhandenen Tabellen mit dem DCA abgeglichen.
ptable,ctable, foreignkeys usw.
Auch deine Selbstreferenzierung wird ausgewertet, welches ja nichts anderes als ein SortingMode 5 ist.
Dies soll nur als Beispiel gelten, wie Du dir sehr viel Arbeit abnehmen lassen kannst, die Ausgabe ist natuerlich nicht maschinenlesbar. Aber wenn man das Format des AnzeigeTools kennt, erzeugt man halt die Datei fuer jenes Tool.
Man koennte nun noch mit auffuehren, das der SourceCode automatisch kontrolliert wird.
Auch ist in diesem Beispiel dein ID int(10) nicht dabei usw.
Aber das ist eine Idee, wie man mit Hilfe eines Crawlers die Arbeit von STunden auf Sekunden reduzieren kann.
Beispiel :Zitat:
---------------------------------------
Loading tl_user
groups use foreignKey : tl_user_group.name
forms use foreignKey : tl_form.title
calendars use foreignKey : tl_calendar.title
catalogs use foreignKey : tl_catalog_types.name
news use foreignKey : tl_news_archive.title
newsletters use foreignKey : tl_newsletter_channel.title
---------------------------------------
Loading tl_user_group
forms use foreignKey : tl_form.title
calendars use foreignKey : tl_calendar.title
catalogs use foreignKey : tl_catalog_types.name
news use foreignKey : tl_news_archive.title
newsletters use foreignKey : tl_newsletter_channel.title
---------------------------------------
Loading tl_page
ChildTable : tl_article
Selfreferenced : 5
groups use foreignKey : tl_member_group.name
layout use foreignKey : tl_layout.name
cuser use foreignKey : tl_user.username
cgroup use foreignKey : tl_user_group.name
So, damit es besser verstaendlich ist, habe ich die Graphviz Ausgabe mal gemacht.
Die Vorlage fuer dieses Bild wird dann erstellt. Generieren dauert auch nicht lange. Also ich habe diese Uebersicht nach etwa 5 Sekunden :
Anhang 1569
(ich musste das Bild fuer Forum verkleinern und in einer schlechteren Aufloesung speichern, Original ist hier : http://dev.typolight-forge.org/attac.../DBCrawler.jpg)
Moin lindesbs,
vielen herzlichen Dank für deine Scripte! Genial einfache Idee (hätte ich selbst drauf kommen sollen, aber ich bin ja noch recht neu by TL, speziell dem Code). Ich bin gerade dabei, Dein Gerüst noch ein wenig aufzupeppen (etwa N:M Hinweis aus 'multiple'=>true, später vielleicht auch noch Code Filename(Zeilennummer), mal sehen). Der Hinweis mit sorting mode = 5 aka Selbstreferenz ist auch sehr hilfreich.
Die INT(10) Felder kann ich mir aus der DB besorgen ( $this->DataBase->listFields($table_name) ) und sowas wie tstamp/sorting wegfiltern; allerdings habe ich kein Kennzeichen gefunden, das aus dem Rest FKs eindeutig erkennbar macht. Beispiel tl_content.articleAlias, ein var_export dieses Feldes:
ich sehe da nichts, das auf die FK-Eigenschaft hinweist, oder?PHP-Code:'articleAlias' =>
array (
'label' =>
array (
0 => 'Bezogener Artikel',
1 => 'Bitte wählen Sie den Artikel aus, den Sie einfügen möchten.',
),
'exclude' => true,
'inputType' => 'select',
'options_callback' =>
array (
0 => 'tl_content',
1 => 'getArticleAlias',
),
'eval' =>
array (
'mandatory' => true,
'submitOnChange' => true,
),
'wizard' =>
array (
0 =>
array (
0 => 'tl_content',
1 => 'editArticleAlias',
),
),
),
Falls jemand die Scripte auf einem im Internet erreichbaren Server einsetzen möchte, empfiehlt sich auch dieser Konstruktor, der das Backend-Login erzwingt (die URL muss man danach aber nochmals manuell eingeben, weil man nach Login in main.php landet ... oder 2 mal Browser-Back und refresh):
Danke nochmals und LG, GeorgPHP-Code:public function __construct()
{
$this->import('BackendUser', 'User');
parent::__construct();
$this->User->authenticate();
}
Was genau meinst Du mit Rest FKs & FK-Eigenschaft ?
Dies ist mir bis jetzt noch gaenzlich unbekannt.
Und : Ja den authenticate hatte ich vergessen.
War eine 15 Minuten Quick&Dirty Implementation. Man koennte bei nicht anmeldung gleich eine BackUrl vorgeben.... Mal sehen.
Hallo Stefan,
FK steht für Foreign Key und mit Rest meinte ich den Rest der Felder einer Tabelle der übrig bleibt, wenn man sie gefiltert hat, also alle INT(10) Felder die nicht tstamp/sorting heißen, haben eventuell die Eigenschaft ein Foreign Key zu sein. Im Fall von tl_content.artcleAlias (und einigen weiteren) habe ich das nur durch Code-Analyse bzw. Kontrolle im Backend herausfinden können, am DCA Array kann ich es nicht erkennen.Zitat:
Zitat von lindesbs
LG, Georg
Moin,
nach dem Finden der Oster-Eier war mir langweilig und deshalb habe ich mal GraphViz (GV) erprobt ...
Anhang 1598
... und bin recht zufrieden mit dem Placement/Routing. Wie Ihr seht, hat GV die Tabellen so gut angeordnet, dass nur eine einzige Relation andere überkreuzt (die N:M von tl_page zu tl_member_group). Und das Diagramm ist nicht übermäßig breit oder hoch.
Dies Diagram entspricht in etwa dem Workbench-Diagramm und ist zur Zeit noch maunell erzeugt (siehe Anlage). Allerdings so angelegt, dass sich das weitgehend auch automatisch erzeugen lässt aus DCA + Zusatz-Infos (z.B. für Foreign-Key-Felder, die sich nicht eindeutig aus den DCAs erkennen lassen, gelegentlich auch, um Einfluss auf die Sortierung von Feldern nehmen zu können).
Zur Notation: ich habe hier Krähenfüße verwendet, weil sie so selbstverständlich sind. Auf Seite der "referencing" Tabelle setzt die Relation immer direkt am Feld an (einem GV port; bei N:1 ein INT(10) "Foreign Key", bei N:M ein BLOB mit einem serialized Array von IDs).
Auf der anderen Seite der Beziehung (die "referenced" Tabelle) zeigt die Relation in etwa auf die Mitte der ganzen Tabelle und endet diverse Pixel VOR der dem Kasten. Das erlaubt GV mehr Freiraum für die Darstellung, meint aber immer, dass das Feld ID referenziert wird.
Was denkt Ihr dazu?
LG, Georg
Moin,
ich habe mir ein wenig Zeit gestohlen, GraphViz weiter zu erforschen:
https://community.contao.org/de/atta...2&d=1271302619
Zufrieden bin ich damit noch lange nicht, aber immerhin wurde die GraphViz DOT Quell-Datei automatisch aus meiner 2.8.0 TL Installation erzeugt (siehe Script im Anhang).
Jedenfalls lässt sich erkennen, dass tl_user/_group (der Backend-Benutzer und seine Gruppe) eine zentrale Rolle spielt (Überraschung?). Die tl_meber_group (Frontend-Benutzer-Gruppe) ist auch noch recht wichtig, der einzelne Frontend-Benutzer dagegen garnicht.
In meiner Installation ist die Erweiterung [survey_ce] vorhanden und beansprucht ebenfalls viel Platz nahe des Zentrums ... völlig zu Recht, weil sie für mich wichtig ist.
Ich würde mich freuen, wen der eine oder andere das anhängende Script mal erprobt und Rückkopplung gibt.
LG, Georg
Also dafür das es automatisch generiert wird finde ich es cool.
Wenn ich im Viewer "dotty.exe" was verändern wollte, gabs immer n totales Chaos mit Darstellungsfehlern und er "vergisst" einige Formatierungen bei den Beziehungs Pfeilen sobald ich was ändere. Hab mich aber jetzt noch nicht weiter großartig damit beschäftigt.
Die Verbindung von meinen Relationen tl_channel -> tl_show -> tl_video hat er jedenfalls gut erkannt.
Gruß Tim :)
Moin Tim,
danke für's Testen.
dotty == grotty ... das war vor vielen Jahren vielleicht mal "State of the Art". Ich benutze GVedit, aber eigentlich auch nur, um unter XP mal eben schnell "dot.exe" aufrufen zu können und gelegentlich den einen oder anderen Parameter testhalber zu ändern. Hauptsächlich nutze ich einen Editor meiner Wahl und rufe "dot.exe" aus einer cygwin bash Kommandozeile auf.
Graphviz ist kein interaktives Werkzeug, auch wenn dotty das vielleicht suggeriert (sofern das "UI" von dotty überhaupt etwas suggeriert) ... nach jedem Eingriff via dotty muss man das Layout sowieso neu erzeugen lassen, dann schlägt wieder "dot.exe" zu und macht all Deine manuellen Eingriffe zunichte.
GraphViz erscheint mir ganz brauchbar für ein erstes/grobes Placement und Routing ... aber beides ist nicht wirklich optimal (oder ich habe die richtigen Einstellungen dafür noch nicht gefunden).
Ich erwarte kein perfektes Layout von Graphviz und konzentriere mich jetzt eher darauf, die noch fehlenden Relationen (z.B. von tl_content zu diversen anderen Tabellen) aus TL zu erzeugen.
Graphviz ist also echt nur ein Zwischenschritt/Hilfsmittel auf dem Weg. Verschwende da bloss keine Zeit drauf!
LG, Georg
Liebe Leser,
da ich mit dem GraphViz Layout nicht wirklich zufrieden war, habe ich mich mal umgesehen und bin dabei auf den yEd gestoßen. Kostenlos, wenn auch nicht Open Source (die Jungs dort leben vom Verkauf ihrer Bibliothek). Ich bin wirklich echt begeistert von diesem Werkzeug und zeige hier nur einmal kurz EINE Variante der möglichen Layouts (hierarchisch, entspricht in der Struktur dem GraphViz Layout). Die volle Stärke des Layouts zeigt sich nebenbei nicht im anliegenden Bild, sondern erst interaktiv in yEd (siehe unten).
Ich warne Interessierte aber: yEd ist nicht nur ein wundervolles Werkzeug, sondern auch ein geiles Spielzeug ... nicht gerade eine Ego-Shooter, aber yEd hat so unglaublich viele Layout-Verfahren und Optionen, dass man sich tagelang damit beschäftigen kann ... und dabei immer neue Erkenntnisse gewinnt!
Und damit Ihr auch etwas zu spielen habt, hänge ich ein ZIP mit den yEd-Quellen für die TYPOlight DB an (noch unvollständig, es fehlen noch einige Foreign Keys). "TYPOlight_yEd_hierachical.graphml" ist bereits fertig ausgelegt, "TYPOlight.graphml" ist so, wie es aus meinem (beta) DBCrawler Script erzeugt wird: ohne jegliche Größen- und Positions-Angaben. Sieht echt blöd aus nach dem ersten Laden ... aber dann probiert doch bitte (in yEd):
- Werkzeuge > Knoten wie Beschriftung...
- Layout > Hierarchisch...
- Layout > Beschriftungen...
und spielt mit den Parametern herum.
Das Script ist, wie gesagt, noch beta, aber es fehlt echt nicht mehr viel. Sobald es fertig ist, bekommt Ihr es, zusammen mit Instruktionen/Hinweisen, wie man daraus gute Layouts macht.
LG, Georg
Auch wenn ich jetzt hier mal nen alten Beitrag pushe, sorry dafür, aber ich bin zufällig auf diesen Thread gestoßen und wollte nur mal einen kleinen Einwurf bezüglich der n:m Beziehungen machen:
Ich weiß nicht wie weit MySQL mit XML Support ist geschweige denn die DB-Treiber von PHP, aber diese N:M Beziehungen lassen sich mit XML Daten fast nativ formulieren ohne "Partitionierung".
Persönlich finde ich dieses Relationenmodell für solche Sachen wie Content-Management ungeeignet, da viele Daten mühsam hin und her adaptiert werden müssen (Formular <-> DB <-> HTML), wobei die einzelnen Representationen strukturell erhebliche Unterschiede aufweisen. XML wär da schon angenehmer (mit entsprechenden Parsern/Prozessoren).
Nur mal als alternativer Denkansatz für 3.0