ER-Modell der Typolight DB?

[NRWunited]

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

[NRWunited]

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.

[leo]

Da es keine Untertabellen im herkömmlichen Sinne wie bei einer normalisierten DB gibt kommt es eigentolich bei Beziehungen immer nur auf ID und PID drauf an.

Und wieso genau begründet eine ID-PID-Verknüpfung keine Untertabelle im Sinne eines normalisierten DB-Entwurfes?

[Thomas]

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.

[NRWunited]

Und wieso genau begründet eine ID-PID-Verknüpfung keine Untertabelle im Sinne eines normalisierten DB-Entwurfes?

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 ;-)

[deerwood]

Hi alle,

Und wieso genau begründet eine ID-PID-Verknüpfung keine Untertabelle im Sinne eines normalisierten DB-Entwurfes?

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.

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

[leo]

Selbstverständlich sind die vielen ID-PID-Verknüpfungen ganz "klassische" 1:N Beziehungen

Das denke ich doch auch

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.

Auch ohne Tricks: parent.id = child.pid und child.id = grandchild.pid.

Nicht "klassisch" gelöst sind N:M Beziehungen.

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:

$this->Database->execute("SELECT * FROM tl_user WHERE groups LIKE '%\"8\"%'"); 

[deerwood]

Moin,

Auch ohne Tricks: parent.id = child.pid und child.id = grandchild.pid.

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?

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:

$this->Database->execute("SELECT * FROM tl_user WHERE groups LIKE '%\"8\"%'"); 

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)?

LG, Georg

[deerwood]

Moin Thomas,

Ich glaube, da kommt die Redundanz ins Spiel!

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):

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 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 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).

LG, Georg

[NRWunited]

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?

Also ich nutze die MySQL Workbench erst seid kurzem, machte mir aber soweit einen sehr soliden Eindruck.

Ich glaube, da kommt die Redundanz ins Spiel!

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.

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.

[Thomas]

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.

[Setsunaa]

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 !

[deerwood]

Moin,

ein erster Eindruck, wie das TYPOlight Datenmodell mit Hilfe der MySQL Workbench aussehen kann:



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

[deerwood]

Hi,

Dass du das händisch machen musst war doch von anfang an klar. In TL ist keine Logik in der DB abgelegt. Das macht alles PHP und die kann WB nun mal nicht auslesen. Würde ja auch keinen Sinn machen.

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 . 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).

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.

WB ist ja zum Planen von DB-Strukturen da und nicht um analysieren bestehender Strukturen.

Das sehe ich anders ... und MySQL wohl auch. Zitat (Forward and Reverse Engineering):

... MySQL Workbench also enables you to reverse engineer an existing database or packaged application to get better insight into its database design. ...

Auch lesens/erprobenswert ist das "Change Management" auf der verlinkten WB Seite.

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

[deerwood]

Moin,

Ich dachte das wäre nur in der Commerziellen Version möglich oder hat sich das inzwischen geändert?

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.

LG, Georg

[BugBuster]

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.

[deerwood]

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:



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

[NRWunited]

Moin alle,
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.

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?

[FloB]

… ansonsten muss man auf ein ER-Modelling Tool eines Datenbanksystems ausweichen, dass Arrays, Tabellen und Objekte innerhalb einer Relation zulässt.

Zwischenfrage: Kennst du da zufällig ein paar?

[NRWunited]

Zwischenfrage: Kennst du da zufällig ein paar?

Hab eben mal bei Oracle geschaut, aber auf Anhieb nur das hier gefunden:

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?

[FloB]

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"?

[deerwood]

Hi FloB,

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"?

Auf Anhieb fällt mir da nur PostgreSQL ein. Zitat::

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.

LG, Georg

[deerwood]

Hi NRWunited,

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?

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.

LG, Georg

[NRWunited]

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"?

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.

[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.

[FloB]

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.

[NRWunited]

Wenn man das in der DB ablegt kann ich wirklich nur noch mit PHP drauf zugreifen. Irgend wie verliert sich dann der Sinn einer DB, denn das schöne an DB's ist ja, dass man über SQL aus viielen Sprachen draufzugreifen kann und immer einheitliche Dinge bekomme.

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.

[deerwood]

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.

2ter_eindruck..png

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 .

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

[deerwood]

Moin leo.unglaub,

Hmmmm, ich verstehe es irgend wie trotzdem nicht ganz. Zumal ein Array ja nicht gleich ein Array ist. Wenn ich ein PHP Array mit einem aus C oder JAVA vergleiceh fallen mir da viele Unterschiede ein. Denn mit einen PHP array kann man 100 mal mehr machen als mit einem Java Array.

Du hast Dir nun das EINZIG wirklich gute Feature von PHP herausgepickt, das ist echt gemein . 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.

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

[BugBuster]

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.

[deerwood]

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.

eindruck_03..png

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.

[lindesbs]

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

[deerwood]

Moin lindesbs,

ich gestehe, dass ich das meiste Deiner Antwort nicht verstanden habe, magst du das nochmal für Doofe formulieren? Insbesondere:

SourceCode nach den Tabellennamen extrahieren -> Crawler automatisisert dies.

Von welchem Crawler ist die Rede? Und Du schlägst vor, die SQL Statements zu extrahieren / zu analysieren?

Mithilfe dieser Masken kannst du dann direkt im Code kontrollieren, was dort gemacht wird, und entsprechende Zeilen in deinem Crawler ignorieren lassen.

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)?

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

[lindesbs]

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.

[lindesbs]

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 :

---------------------------------------
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

[lindesbs]

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 :

DBCrawler..jpg

(ich musste das Bild fuer Forum verkleinern und in einer schlechteren Aufloesung speichern, Original ist hier : http://dev.typolight-forge.org/attac.../DBCrawler.jpg)

[deerwood]

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:

    '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',
        ),
      ),
    ), 

ich sehe da nichts, das auf die FK-Eigenschaft hinweist, oder?

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):

    public function __construct()
    {
        $this->import('BackendUser', 'User');
        parent::__construct();
        $this->User->authenticate();
    } 

Danke nochmals und LG, Georg

[lindesbs]

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.

[deerwood]

Hallo Stefan,

Was genau meinst Du mit Rest FKs & FK-Eigenschaft ?
Dies ist mir bis jetzt noch gaenzlich unbekannt.

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.

LG, Georg

[deerwood]

Moin,

nach dem Finden der Oster-Eier war mir langweilig und deshalb habe ich mal GraphViz (GV) erprobt ...

test_01..gif

... 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