Getrennte Datenbank für jeden Mandanten

[Oldperl]

Dazu dann ein Konvertierungsprogramm, dass die alte DB Struktur in die neue Struktur umwandelt.

Das brauch es garnicht
Die alten Tabellen entweder leer oder für den Demomandanten nehmen. Beim Anlegen eines neuen Mandanten die vorhandenen Tabellenstrukturen einfach kopieren und mit suffix versehen, wobei die Zahl im suffix der id des neuen Mandanten entspricht.
That's it

Gruß aus Franken

Ortwin

[JeromeW]

Hallo,

Oldperl hat folgendes geschrieben:

Das brauch es garnicht
Die alten Tabellen entweder leer oder für den Demomandanten nehmen. Beim Anlegen eines neuen Mandanten die vorhandenen Tabellenstrukturen einfach kopieren und mit suffix versehen, wobei die Zahl im suffix der id des neuen Mandanten entspricht.
That's it Wink

Ich dachte eher daran, wenn jemand bereits mehr als einen Mandanten in einer Contenido-Installation (bei der die Tabellen noch nicht getrennt sind) installiert hat und anschliessend mit der neue Version updaten will. Dann sollten doch für die alten Mandanten auch Tabellen mit suffix angelegt werden. Bei meinen bisher bescheidenen Contenido Kenntnissen nehme ich an, dass man dafür die Daten einiger Tabellen "auseinandernehmen" muss.

Grüße
JeromeW

[Oldperl]

Hallo JeromeW,

es ist wohl besser sich zuerst um den Ablauf bei einer Neuinstallation zu kümmern. Eine Migrations-Funktion kann man dann später immer noch machen. Auch kann man das, wenn die Funktion steht, mit im Setup (Update) integrieren.

Im Vorfeld sollte man sich noch überlegen, wo überall die DB-Abfragen geändert bzw. angepasst werden müssen, oder ob man evtl. in der $cfg[tab] für bestimmte Tabellen nur den suffix bei Aufruf des Mandanten (Client) anhängen kann/muss.

Gruß aus Franken

Ortwin

[JeromeW]

Hallo Oldperl,

ich habe die Datenbank und die Sourcen angeschaut, man braucht in der $cfg[tab] nur für bestimmte Tabellen den Suffix anhängen. Das Datenfeld idclient würde ich erst mal in den Tabellen belassen, das erspart Änderungen bei den SQL Abfragen. Ich nehme mal an, dass die Contenido-Entwickler konsequent die Tabellenzugriffe mit Hilfe der $cfg[tab] durchführen. (Außer externe Module wie z.B. vpguestbook.)

In der Tabelle clients ist das Datenfeld idclient gleichzeitig der Wert für den Suffix der anderen Tabellen, diese Tabelle erhält keinen Suffix und das Datenfeld idclient muss natürlich erhalten bleiben

Ich weiss nur noch nicht in welchem PHP Programmteil der Suffix gefüllt werden muss, auf jeden Fall direkt nach der Auswahl des Mandanten. Anschliessend wird dann noch ein Programm benötigt, dass die Tabellen für neue Mandanten mit entsprechendem Suffix dupliziert.

Wenn da nicht noch irgendwelche Sonderfälle auftauchen wie z.B. so etwas hier

rethus hat folgendes geschrieben:

Und das größte Problem ist, dass Datensätze die mandantenspezifisch sind, mit Contenido-Core-Datensätzen wild durcheinadner gewürfelt sind (soweit ich mich erinner)

dürfte die Realisierung nicht allzu aufwendig sein. Der größte Aufwand ist vermutlich die Migrations-Funktion. Eine eigene Datenbank für jeden oder mehrere Mandanten wäre allerdings mit wesentlich weniger Aufwand zu realisieren. Desweiteren brauchen dann keine Module geändert zu werden.

Das Ganze macht aber wirklich nur Sinn, wenn es zukünftig in das Contenido Release aufgenommen wird.


Viele Grüße
JeromeW

[JeromeW]

Hallo,

besser statt Suffix einen zweiten Präfix damit die Tabellen eines Mandanten in diversen mysql-Tools alle schön untereinander stehen.

Grüße
JeromeW

[rethus]

Das Ganze macht aber wirklich nur Sinn, wenn es zukünftig in das Contenido Release aufgenommen wird.

Un genau dass bremst - solange ich hier im Forum bin - schon die meisten Entwicklungen. Leider commited sich hier von 4fb keiner dazu... und die Community bringt zwar immer gute Ideen und leistet harte Arbeit, aber man bangt immer darum, dass es eh nicht ins neue Releas kommt.

Bisher sind meist die wirklich guten, großen Vorschläge und Anpassungen (Stichwort mod_rewrite) nicht ins CORE gekommen. Wen wunderts, dass da die Motivation - contenido um seiner selbst willen - voran zu bringen auf der strecke bleibt, und sich auf die Bereiche beschränkt, wo man selbst Verwendung für hat.

Contenido ist klasse, 4fb hat wirklich was auf die Beine gestellt - dennoch ist es aus Sicht des "Community-Gedanken" ein Desaster mit Contenido - nach wie vor... und daran wird sich wohl auch nichts ändern

[kummer]

Mal eine ganz grundsätzliche Frage: Mehrmandantensystem und dann für jeden Mandanten eine eigene DB oder auch nur eigene Tabellen? Aber wozu das denn? Damit man sich das bisschen Speicherplatz für eine Installation spart?

Dass sich die Mandanten nicht gut trennen lassen, ist wohl ein Problem. Das ist schon klar. Allerdings würde ich für jeden Kunden unbedingt eine eigene Installation machen wollen. Was, wenn der eine Kunde ein Update will und der andere nicht? Oder - das kann schon mal vorkommen - eine Kunde dich verlassen will oder auch nur auf ein anderes Hosting wechseln möchte?

[rethus]

Hi Andreas,

genau dass ist die Antwort auf deine Frage. Als TO ging mir der Sinn nicht nach einem Semi-Dualen System, sondern nach einem wirklichen Mandanten-System. Wenn die Mandanten-Daten jedes Kunden in einer separaten DB liegen, ist es ohne Probleme möglich, die kundenspezifischen Daten separiert zu behandeln.

Wie du richtig beschreibst, macht es bei Kunden, welche eine eigene Contenido installation haben wollen nicht wirklich Sinn... Auch nicht, wenn man von der Pflege der CMS-Systeme (sprich Upgrading, patching usw.) lebt.

Sinn macht es aber durchaus, wenn du mit dem Contenido ein System aufbaust, welches nicht in die richtung ausgerichetet ist, sondern bei dem durch die eigentliche Leistung des Systems - baukastensystem oder ähnliches - die einnahmen kommen. Da möchte man dann als betreiber schon gerne, dass dass gesamte System mit einem rutsch up-to-date ist.
Gleiches gilt natürlich für sämtliche eigene Projekte, die man so laufen hat. Ich mach lieber 1 Upgrade, als 10.

[kummer]

Alles richtig. Allerdings nur halb. Es ist doch so (verzeih mir, wenn ich etwas aushole): ein Update besteht immer aus einem Dateisystemteil (dem eigentlichen Code) sowie - meist nicht transparent - aus Anpassungen in der Datenbank. Wenn ich nun 10 Installationen einzeln vorliegen habe (um bei deinem Beispiel zu bleiben), dann wird ein Update des Dateisystems (also nur der PHP-Dateien) entweder einmal glücken und damit automatisch 10 mal genau so. Oder dann geht es nicht gut, weil noch ein Bug lauert, der das ganze stört. Auch dabei aber entweder 1 x = 10 x oder dann eben gar nicht. Etwas anders sieht es in der Datenbank aus. Leider ist es in der Regel wenig transparent, da in jedem Fall die Setup-Routine anzuwerfen ist, obwohl das im Einzelfall möglicherweise gar nicht notwendig wäre. Hier ist es nun durchaus so, dass es einmal glücken kann und damit noch keinerlei Sicherheit besteht, dass es die 9 übrigen Male auch so gut über die Bühne geht (da ja der Datenbestand nicht derselbe ist). Wenn also zusammen, dann will man auch die Datenbanken zusammen haben. Wenn du nun die Datenbanken trennst, hast du genau den Teil isoliert, der Probleme verursacht. Damit erreichst du präzise das Gegenteil dessen, was du anstrebst. Denn wenn Anpassungen in der DB erforderlich sein sollten, müsstest du die 10 vornehmen. Und jedes mal einzeln. Der Gewinn ist also null.

Es ist in der Praxis leider so, dass gerade bei grösseren Auftritten und einer Anpassung in der DB nicht alles rund verlaufen muss. Eine Hürde stellt dabei die maximale Ausführungsdauer von PHP kombiniert mit dem Fehlen von Transaktionen dar. Ein Rollback ist ausgeschlossen. Wenn das System hängt, dann ist der Schaden da. Das zweite Problem ist die Tatsache, dass - gerade eben wieder bei grösseren Auftritten - eine beschädigter Kategoriebaum eher schon die Regel als die Ausnahme ist (insbesondere bei Mehrmandanten und Mehrsprachensystemen). Allerdings bringt auch hier gerade die von dir vorgeschlagene Trennung keine Abhilfe. Du bist im Gegenteil gezwungen, das Update auch bei diesen Kunden vorzunemen und kannst diesen nicht einfach ruhen lassen, bis ein Release heraus kommt, dass auch mit diesem Mandanten funktionieren würde.

Aber ich sehe den Punkt schon. Du willst alles zusammen haben, eben genau bis auf die DB. Dazu sollte es ausreichen, für jeden Mandanten ein Verzeichnis zu haben und die Contenido-Daten als Symlink in das Verzeichnis zu ziehen. Du wirst dabei einfach das Problem haben, dass du das Setup bei einem Upgrade dann doch 10 wirst machen müssen. Mit einer DB je Mandant wirst du da wohl nicht herum kommen.

[rethus]

Naja, irgendwie sehen wir das an dieser Stelle wohl unterschiedlich - was ja grundsätzlich nicht verkehrt ist, hab kein Problem mich zu "zweinigen" (gegenteil von einigen (jemand. seine Meinung aufdrängen).

Ist ein System sauber getrennt - auch in der DB, so sind Core-Funktionen und Kunden-Datenbestand auch getrennt. Somit wird bei einem Upgrade des Systems kein Upgrade der Kundendaten nötig! Dies ist ja auch die ganze Logik dahinter, funktionen von Daten zu trennen.
Es ist immer eine Frage, wie weit man die einzelnen Daten und Funktionen sauber von einander trennt. Daher kann ich deinen Ausführungen nicht so ganz folgen.

Was schon richtig ist: gehts einmal gut, gehts 10x gut... und gehts 1x daneben, gehts 10x daneben... aber dafür hat man ja eine Testumgebung... und operiert nicht am offenen Herzen (wenns nicht sein muss)

PS: Zitat:

Das zweite Problem ist die Tatsache, dass - gerade eben wieder bei grösseren Auftritten - eine beschädigter Kategoriebaum eher schon die Regel als die Ausnahme ist (insbesondere bei Mehrmandanten und Mehrsprachensystemen).

Ein sauber getrenntes System je Mandant - ich spreche hier von einem wirklichen Client-Server-system... nicht semiprofessionell auseinander-gefrickelt - schafft hier in jedem Fall Abhilfe - vor allem wenn die Fehler vermehrt bei steigender Größe der Kategoriebüme entstehen..., denn mehrere Mandanten = mehrere - aber kleinere Kategorie-Bäume.

[idea-tec]

denn mehrere Mandanten = mehrere - aber kleinere Kategorie-Bäume.

Also das ist ausgemachter Quatsch, ein Mandant, der >1.000 Kategorien hat, hat auch nach der Trennung noch immer >1.000 Kategorien.
Abgesehen davon, besteht dieses Problem mit den Kategorien NUR und ausschließllich auf wenig perfomanten und/oder entsprechend unzureichend konfigurierten Servern.

Ich selbst habe mehrere Installationen, teils >6.000 Kategorien, mit bis zu >10 Sprachen und hatte das Problem noch nie! Allerdings betreibe ich auch eigene sehr hochperformante Kisten.

[kummer]

Abgesehen davon, besteht dieses Problem mit den Kategorien NUR und ausschließllich auf wenig perfomanten und/oder entsprechend unzureichend konfigurierten Servern. Ich selbst habe mehrere Installationen, teils >6.000 Kategorien, mit bis zu >10 Sprachen und hatte das Problem noch nie! Allerdings betreibe ich auch eigene sehr hochperformante Kisten.

Performance spielt auch eine Rolle, logisch. Aber durchaus nicht nur. Das Problem ist auch bei dedizierten Servern aufgetreten und hängt letztlich damit zusammen, dass die Umschichtung (a) überhaupt notwendig ist, (b) nicht innerhalb einer Transaktion erfolgt und (c) je nachdem auch mehr als eine Manipulation des Redakteuren gebraucht hat. Z.B. Baum aushängen (1 Request), Baum wieder einhängen (ebenfalls 1 Request). Und wenn der Redakteur das dann eben nicht macht, hiflt dir Systemleistung nichts.

Aber in der Tat bringt die Auflösung in mehrere DBs in dieser Hinsicht keine Besserung. Defacto ist das System dann gar nicht mehr mehrmandantenfähig. Das gleiche erreicht man alleine schon dadurch, dass man den Systemkern nur einmal vorliegen hat und als Symlinks in verschiedene Installationen legt. Bei einem Update macht das Dateisystem in der Regel auch die geringsten Probleme. Es sind genau allfällig notwendige DB-Updates, die Schwierigkeiten verursachen können; genau diese muss man bei einem Update bei dem vorgeschlagenen Vorgehen jedoch wiederholt vornehmen.

Huch, habe ich am Ende schon zuviel geschrieben..? Lange Texte ... - wie war das doch? - ach ja, "lange Texten gehören nicht zu den Argumenten die ich zählen lasse".

[idea-tec]

Performance spielt auch eine Rolle, logisch. Aber durchaus nicht nur. Das Problem ist auch bei dedizierten Servern aufgetreten und hängt letztlich damit zusammen, dass die Umschichtung (a) überhaupt notwendig ist, (b) nicht innerhalb einer Transaktion erfolgt und (c) je nachdem auch mehr als eine Manipulation des Redakteuren gebraucht hat. Z.B. Baum aushängen (1 Request), Baum wieder einhängen (ebenfalls 1 Request). Und wenn der Redakteur das dann eben nicht macht, hiflt dir Systemleistung nichts.

Riiiiischtiiiiisch
Ich hatte ja nicht geschrieben, dass der Core an der Stelle in Ordnung sei....

Fakt ist und bleibt: Die Kategorien-Geschichte muss einmal angegangen werden, da die vorne und hinten und immer wieder zu Problemen führt. Und eine DB-Trennung mach keinen taug, das machts (meine Meinung!) nur noch weniger anwenderfreundlich

[kummer]

Fakt ist und bleibt: Die Kategorien-Geschichte muss einmal angegangen werden, da die vorne und hinten und immer wieder zu Problemen führt.

Mein Rede... Es soll sich in der 4.8.13 ja auch was getan haben. Aber ich fürchte, aus Gründen der Rückwärtskompatiblität ist dort wenig verändert worden. Vermutlich einfach nur das nötigste.

Und eine DB-Trennung mach keinen taug, das machts (meine Meinung!) nur noch weniger anwenderfreundlich

Hab nichts anderes behauptet. Man kann es machen. Die Realisierung ist einfach. Der Nutzen allerdings null. Es ist dann sogar so, dass man alle Mandanten auf einmal updaten muss, was bei Einzelinstallation nicht notwendig wäre. Gleichzeitig muss das, was ggf. zu Problemen führen kann, mehrmals vorgenommen werden. Und zwar die DB-Aktualisierung.

[idea-tec]

Langer Rede kurzer Sinn: Wir blasen ins gleiche Horn und können es nun auch dabei belassen ...

<OT>
P.S.: Hast du meine eMail erhalten, wegen NaviUniversell?
</OT>