Sprachen vs. Mandanten

[calvini]

allerdings stellt sich aus meiner sicht weniger die frage, ob man etwas machen könnte, sondern, was man dadurch gewinnen würde. die redundanz durch das mehrfachanlegen von sprachen ist nun wirklich marginal

Ob es marginal ist, soll jemand entscheiden, der mit vielen Mandanten und mehreren Sprachen arbeitet ...

und wie bereits ausgeführt erleichtert es die selektion von artikeln einer bestimmten sprache und eines bestimmten mandanten. nebenbei bemerkt schlägt sich zuweilen redundanz in besserer performance nieder, weshalb sie manchmal angestrebt wird, solange sich keine anomalien daraus ergeben.

Dem widerspreche ich insofern, als das die von Dir angesprochene Redundanz normalerweise meint, Informationen (gewollt) mehrfach abzuspeichern, damit man auf verschiedenen Wegen darauf zugreifen kann (wie z.B. bei der Baumstruktur der Kategorien, einmal als verkettete Liste (cat) und einmal als sequentielle Liste (cat_tree)). Das macht durchaus Sinn, erfordert aber auch Unterstützung durch Funktionen, die die redundanten Strukturen erzeugen bzw. abgleichen. Mit der Datenbank alleine geht das nicht.
Im aktuellen Fall sehe ich das nicht so. So wie die Datenbank angelegt ist, ist die Zuordnung Mandant-Sprache eine n:n Zuordnung. Dabei nach Artikeln einer Sprache zu suchen und darauf zu hoffen gleichzeitig nur Artikel eines Mandanten zu finden, ist in meinen Augen schlichtweg falsch. Und ganz konsequent wäre es bei dem aktuellen Datenbankmodell natürlich, wenn man bei der Sprachzuordnung nicht die idlang sondern die idclientslang verwenden würde (das wäre dann tatsächlich eine Form der von Dir angesprochenen Redundanz).

ohne es selber schon einmal ausprobiert zu haben, könnte ich mir vorstellen, dass probleme bei der synchronisation auftreten werden, wenn dieselbe sprachen-id in mehreren mandanten verwendet werden wird.

Was meinst Du mit Synchronisation?

[emergence]

Was meinst Du mit Synchronisation?

ab version > 4.5.x gibt es die möglichkeit artikel und kategorien zwischen den einzelnen sprachen abzugleichen(synkronisieren)

[HerrB]

In den kommenden Versionen können Artikel und Kategorien über Sprachgrenzen hinweg übertragen werden, dies wird als Synchronisation bezeichnet.

Es ist nun bestätigt, dass es halt mal ungünstig designed wurde (die Antwort hätte ich auch gerne vor 2 Jahren erhalten) und es bedeutet mit Sicherheit eine Riesenarbeit, das jetzt zu korrigieren und - insofern stimme ich Kummer zu - gewinne ich durch eine Änderung nichts an Funktionalität (formalistisch ist es schöner und $lang entspricht immer dieser einen Sprache - das ist halt ganz hübsch).

Jut.

Damit bist Du herzlich eingeladen, Contenido in dieser Richtung zu überarbeiten (ich würde von den aktuellen Snapshots ausgehen, nicht von V4.4.x). Natürlich ist es 4fb überlassen, Deine Änderungen zu berücksichtigen.

Dazu brauchen wir dann noch eine Migrationsstrategie für bestehende Installationen, eine Funktion zum Verwalten der Sprachen (unter Administration), die Funktionen für die Sprachwahl der Mandanten und das Setup muss überarbeitet werden, das Handbuch und die Standardmodule müssen überprüft werden.

Na ja und 4fb muss noch die Zeit aufbringen, sich mit dem Ergebnis auseinanderzusetzen - spätestens daran wird es scheitern, da die guten mächtig beschäftigt sind und vor Ende des Jahres in dieser Richtung wohl keine Zeit bestehen wird.

Gruß
HerrB

[calvini]

In den kommenden Versionen können Artikel und Kategorien über Sprachgrenzen hinweg übertragen werden, dies wird als Synchronisation bezeichnet.

Das sollte ja im Bezug auf die aktuelle Aufgabenstellung kein Problem sein, wenn es so programmiert ist, dass es nur Sprachgrenzen, aber nicht Mandantengrenzen überschreitet.

Was den Rest betrifft: Leider werde ich vor Juli nicht dazu kommen, mich damit auseinanderzusetzen (dann bin ich aber gerne dazu bereit). Ich sehe das allerdings nicht so unendlich umfangreich wie Du es geschildert hast. Schlimm wäre es, wenn das Datenbankmodell anzupassen wäre.

So fehlt eigentlich 'nur' eine Möglichkeit, einem Mandanten die Sprachen zuzuordnen. Bei der Auswahl Sprachen im Menü Administration müssten alle Elemente aus lang angezeigt werden, das Selektionsmenü für die Mandanten entfällt. Ansonsten ist der Menüpunkt Sprachen ja schon genau da angesiedelt, wo er hingehört: Auf einer Ebene mit Mandanten, Benutzern und Gruppen.
Beim Mandanten müsste dafür eine Checkbox-Liste mit allen verfügbaren Sprachen angezeigt werden, die die dort angeklickt werden, werden in clients_lang gespeichert.
Einziges 'wirkliches' Problem: Die Zugriffsberechtigung. Da müsste eine Matrix Mandant/Sprache angezeigt werden (was aber eh sinnvoll wäre).
Der ganze Rest läuft wie bisher, da sich ja das Datenbankmodell nicht ändert (das Kopieren des Datenbestandes eines Mandanten in eine neue Sprache erfolgt dann natürlich logischerweise nicht mehr beim Anlegen der Sprache, sondern beim Zuordnen). Die ganze Funktionslogik ist schon vorhanden, sie müsste 'nur' anders eingesetzt werden. Bestehende Datenbestände müssen nicht migriert werden.
Ins Handbuch müsste ein Hinweis, dass man nicht nur nach einer bestimmten Sprache suchen darf, wenn man eigentlich nach einer bestimmten Sprache eines bestimmten Mandanten sucht (sollte zwar obsolet sein, aber ich gebe zu, das wahrscheinlich 97 Prozent aller Programmierer gerne solche Sachen machen ).
Und Module, die Mandanten nicht berücksichtigen und sich nur auf die Sprache verlassen, sollten sich nicht Standard-Module nennen dürfen .

[HerrB]

Und Module, die Mandanten nicht berücksichtigen und sich nur auf die Sprache verlassen, sollten sich nicht Standard-Module nennen dürfen .

Übetreib nicht. Die meisten Module (auch die im Forum) beachten erst in der zweiten und dritten Überarbeitung mehrere Mandanten und/oder Sprachen. Ist alles eine Frage des Aufwands.

Auf jeden Fall viel Erfolg, ich freu' mich drauf.

Gruß
HerrB

[calvini]

Ist alles eine Frage des Aufwands.

Schon klar. Ich halte es lieber so, beim Programmieren 2 Stunden mehr zu investieren, um dann beim Anwenden nicht 4 Stunden zu verlieren, weil irgendwas nicht geht. Aber da Microsoft es ja erfolgreich vormacht, wie man mit Bananensoftware arbeitet, werde ich für diese Vorgehensweise nicht allzuviele Unterstützer finden .

[HerrB]

Aber da Microsoft es ja erfolgreich vormacht, wie man mit Bananensoftware arbeitet, werde ich für diese Vorgehensweise nicht allzuviele Unterstützer finden

Ähm, Vorsicht. Wir alle (davon gehe ich jetzt mal aus) sehen das genauso. Du verwendest Contenido seit zwei Monaten, wir seit mehreren Jahren. Wir sind weder bescheuert noch blöd - es muss die Zeit zur Verfügung stehen und daran hapert es immer (ich z.B. muss auch noch Geld verdienen und von "Being Mr. PHP" bin ich Meilen entfernt).

Z.B. stecke ich meine Zeit in Fehlerbereinigung und sinnvolle Features - ohne das Grundsystem in Frage zu stellen. Warum? Vielleicht, weil es mich überfordern würde, ich nicht übersehen könnte, wie sich das auf andere Nutzer und vorhandenen Projekte von 4fb auswirkt und weil es Gründe geben wird, warum es so ist - und wenn es die fehlende Zeit ist (hey, d.h. nicht dass ich nicht trotzdem Fragen würde). Vielleicht.

Akademische Überlegungen der Art "hätte man nicht auch a und b machen können" sind zwar hochinteressant und schmeicheln - je nach Antwort - das Ego, bringen aber praktisch zu wenig.

Verstehe mich nicht falsch, es ist schön, wenn jemand, der es kann, interessante Fragen aufwirft. Richtig prickelnd ist es aber erst dann, wenn dieser sich dann auch die Zeit nimmt, die Sache entsprechend zu überarbeiten und dann auch später für Korrekturen zur Verfügung steht (ups, da war ja noch dieser Fehler; klar nehme ich mir die Zeit, das für die neue Version anzupassen).

Insofern freue ich mich, dass Du an Bo(a)rd bist, Fragen stellst und offensichtlich Energie in Contenido stecken möchtest bzw. steckst. Ich bin (positiv) gespannt, welche Features durch Deine Aktivitäten zur Verfügung stehen werden und welche Bugs durch Dich ausgemerzt werden können.

Ich für meinen Teil würde mir jedoch wünschen, wenn Du nicht alle anderen als unfähige Deppen, die an Bananensoftware werkeln, bezeichnen würdest - sei es direkt oder indirekt. Danke und Amen.

Gruß
HerrB

[emergence]

ich verschieb das ganze mal... ist ja nicht so das es unintressant ist...

[kummer]

So wie die Datenbank angelegt ist, ist die Zuordnung Mandant-Sprache eine n:n Zuordnung. Dabei nach Artikeln einer Sprache zu suchen und darauf zu hoffen gleichzeitig nur Artikel eines Mandanten zu finden, ist in meinen Augen schlichtweg falsch.

ich bin auch schon darüber gestolpert, als ich versucht habe, aus der selben sprache mandantenübergreifend daten zusammen zu ziehen. in dieser hinsicht - da gebe ich dir absolut recht - wäre anders rum vorteilhaft. falsch ist es indessen überhaupt nicht und - nebenbei bemerkt - hoffen braucht man nicht. man weiss es ganz genau: wenn du eine abfrage über eine bestimmte sprach-id vornimmst, wirst du nur daten eines einzelnen mandanten erhalten. und das ist nun freilich nicht zufall, sondern so im db-design fest gelegt.

wenn du nicht zum ersten mal mit datenbanken arbeitest, wirst du auch schon fest gestellt haben, dass man beim anlegen der tabellen die eine oder andere überlegung einfliessen lässt. massgeblich dabei ist jeweilen die zielsetzung. wenn also gewünscht ist, nur die artikel eines mandanten zu erhalten, dann ist das db-design so wie es ist völlig in ordnung. und keineswegs falsch. wenn man daten mandantenübergreifend zusammenziehen will, dann hast du natürlich recht, dann wäre es falsch. um eine vernünftige beurteilung der sachlage vornehmen zu können, müsstest du in der folge wissen, wass der db-designer vorgehabt hat.

wie bereits angetönt war ich auch schon in der situation, wo ich gerne einen bezug der verschiedenen sprachen bei verschiedenen mandanten gehabt hätte. im normalfall sind jedoch verschiedene mandanten voneinander völlig unabhängig.

aber nun noch eine kleine bemerkung am rande: wenn also alle sprachen für alle mandanten verfügbar wären (nur so rein hypothetisch), dann würde man noch weitere tabellen benötigen (die es aber zurzeit noch nicht gibt). z.b. eine für die Sprachenbezeichnungen (die ja wiederum abhängig von der primärsprache sein dürften), dann müsste mindestens eine weitere tabelle angelegt werden, die auskunft darüber gibt, ob eine sprache bei einem bestimmten mandanten überhaupt in gebrauch ist oder nicht.

mindestens die sprachbezeichnungen sind dabei gar nicht so unwichtig, da sie z.b. innerhalb von modulen verwendet werden können und möglicherweise (ich habe da grad so ein beispiel) vom kunden ganz bestimmte bezeichner gefragt sind.

und - ebenfalls nur so nebenbei - wären dann natürlich die idartlang und idcatlang durchaus nicht mehr eindeutig. zurzeit sind sie es. über alles betrachtet ist das db-design so falsch also nicht. wenn man das allgemeingültige db-design sucht (gewissermassen die weltformel in sachen datenbank), dann sucht man bei contenido wohl am falschen ort. ob man insgesamt fündig werden dürfte, ist eine andere frage.

[HerrB]

aber nun noch eine kleine bemerkung am rande: wenn also alle sprachen für alle mandanten verfügbar wären (nur so rein hypothetisch), dann würde man noch weitere tabellen benötigen (die es aber zurzeit noch nicht gibt). z.b. eine für die Sprachenbezeichnungen (die ja wiederum abhängig von der primärsprache sein dürften), dann müsste mindestens eine weitere tabelle angelegt werden, die auskunft darüber gibt, ob eine sprache bei einem bestimmten mandanten überhaupt in gebrauch ist oder nicht.

Das mit der Tabelle wäre so schlimm nicht. Wenn man die jetzigen Informationen in eine Tabelle auslagert und statt der Definition unter Administration -> Sprachen nur eine Zuordnung durchführt, braucht man nur eine Tabelle.

Für Sonderfälle a la "hessisches Deutsch" gäbe es dann haltg mehr globale Sprachen...

Gruß
HerrB

[kummer]

ich halte insgesamt die unterordnung der sprache unter den mandanten über alles betrachtet als gutes db-design. immerhin erhält es die autonomie jedes einzelnen mandanten. im regelfall sind das ja unterschiedliche kunden mit durchaus partikularen interessen.

es gibt fälle - ich war auch schon mit einem solchen konfrontiert - wo es hilfreich gewesen wäre, auf dieselbe sprache in einem anderen mandanten zugreifen zu können. aber der normalfall ist das ganz sicher nicht. da die datenpflege innerhalb jedes mandanten abgeschlossen ist und von unterschiedlichen kunden durchgeführt wird, dürfte es den globalen zugriff (also über mehrere mandanten hinweg) im prinzip gar nicht geben.

aber eine überlegung scheint mir bei allem einfach doch noch wichtig: ein mandant kann dann wohl kaum die die pflege der sprachen vornehmen, wenn diese globale gültigkeit erhalten sollten. man darf wohl kaum zulassen, dass ein mandant die sprachen administriert, wenn dies dann auswirkungen auf alle anderen mandanten im gleichen system hat.

letztlich ist es für mich eben doch eine rein akademische frage, ob sprachen aufgrund ihrer natur global verfügbar sein sollen oder nicht. denn im regelfall dürfte es gleichwertig sein, eine zweite installation von contenido vorzunehmen oder eben einen mandanten anzulegen. abgesehen vom speicherverbrauch natürlich.

den anspruch eines 'echten' oder eben 'natürlichen' db-designs aufgrund der semantik, respektive aufgrund der reinen begrifflichkeit finde ich völlig verfehlt. mit dem db-design wird ein bestimmtes ziel verfolgt. und dies muss in diesem fall in meinen augen bedeuten, dass in der hierarchie der mandant zuoberst steht, da es sich im normal um einzelne kunden handelt, dessen autonomie im grösstmöglichen mass zu erhalten ist.

wenn versucht wird, daten aus anderen quellen einzubeziehen, dann ist das mandantenübergreifende sammeln von daten möglicherweise einfach nicht der ideale weg (nach meiner meinung sogar ganz sicher nicht). da müsste man vielleicht überlegen, ob nicht rss oder soap gefragt ist. oder auch einfach ein direkter zugriff.

wenn ein mandantenübergreifender bezug bestehen muss, kann diese im übrgen sehr einfach und ohne irgendwelche anpassungen im erd erfolgen. man wähle als sprachbezeichner einfach den internationalen länder-, respektive sprachencode (z.B. de, de-ch, fr usw.). diese sind absolut eindeutig und erfüllen in der folge alle bedingungen eines datenbankschlüssels. unter den gegebenen bedingungen (rdbms: mysql) spielt es nämlich keine rolle, ob in der datenbank ein entsprechender constraint gesetzt ist oder nicht.

ich möchte keinen erd-streit vom zaun brechen; allerdings ist diese problematik in meinen augen wirklich unbedeutend. zum einen gibt es probate lösungen, welche datenbanktechnisch unproblematisch sind. und zum anderen gibt es - schaut man das erd genauer an - stellen, die wesentlich dringender der lösung bedürfen. ich denke da z.b. an die referenzierung von bildern, bei welchen eine ganzzahl in ein textfeld geschrieben wird, dass in einem anderen kontext als textinhalt verwendet wird. oder - noch wichtiger - die tatsache, dass es ohne workaround derzeit nicht möglich ist, komplexe daten als konfiguration zu speichern (also keine objekte und nicht einmal arrays). wenn angesichts begrenzter ressourcen arbeiten zu priorisieren sind, würde ich dem in diesem thread dargelegten problem eine eher geringe priorität einräumen.

[HerrB]

ich halte insgesamt die unterordnung der sprache unter den mandanten über alles betrachtet als gutes db-design. immerhin erhält es die autonomie jedes einzelnen mandanten.

Yep, sehe ich, seitdem ich mit der DB-Struktur arbeite (mittlerweile seit Jahren) auch so.

aber eine überlegung scheint mir bei allem einfach doch noch wichtig: ein mandant kann dann wohl kaum die die pflege der sprachen vornehmen, wenn diese globale gültigkeit erhalten sollten. man darf wohl kaum zulassen, dass ein mandant die sprachen administriert, wenn dies dann auswirkungen auf alle anderen mandanten im gleichen system hat [und folgend]

Yep, das meinte ich mit "es fehlt die übergeordnete Ebene". Genauso ist es: Ein Mandant ist ein gänzlich neuer Kunde - der seine ganz eigene Freiheit haben möchte. Nun könnte man sich drüber streiten, warum idlang nicht pro Mandant hochgezählt wird, aber das ist akademisch...

ich möchte keinen erd-streit vom zaun brechen; allerdings ist diese problematik in meinen augen wirklich unbedeutend.

Yep. Jeder, der anfängt, sich mit der DB-Struktur auseinanderzusetzen und schon mal was von Datenbanken gehört hat, fällt darüber (ich mache da keine Ausnahme, ich kann es aber mittlerweile als Jugendsünde abhaken ).

wenn angesichts begrenzter ressourcen arbeiten zu priorisieren sind, würde ich dem in diesem thread dargelegten problem eine eher geringe priorität einräumen.

Wie Darth-Vader sagen würde: FULLACK

Aber jetzt haben wir eine schöne Erörterung des Themas... Es ist viel zu tun, packen wir es an (süddeutsch: pack mer's).

Gruß
HerrB

[calvini]

Kann mich leider in der nächsten Zeit nicht damit beschäftigen, wollte aber noch ein paar Kleinigkeiten nachfragen:

man weiss es ganz genau: wenn du eine abfrage über eine bestimmte sprach-id vornimmst, wirst du nur daten eines einzelnen mandanten erhalten. und das ist nun freilich nicht zufall, sondern so im db-design fest gelegt.

Wo? In der Datenbankstruktur (= DB-Design?) ist die Zuordnung Sprache-Mandant eine n:n Zuordnung (Tabelle clients_lang). An keiner Stelle der Datenbankstruktur ist festgelegt, dass eine Sprach-Id nur einem einzigen Mandanten zugeordnet werden kann.

aber nun noch eine kleine bemerkung am rande: wenn also alle sprachen für alle mandanten verfügbar wären (nur so rein hypothetisch), dann würde man noch weitere tabellen benötigen (die es aber zurzeit noch nicht gibt). z.b. eine für die Sprachenbezeichnungen (die ja wiederum abhängig von der primärsprache sein dürften), dann müsste mindestens eine weitere tabelle angelegt werden, die auskunft darüber gibt, ob eine sprache bei einem bestimmten mandanten überhaupt in gebrauch ist oder nicht.

Diese Tabellen gibt es bereits: lang und clients_lang. Dass Sprachen (momentan) nicht selbst nochmal sprachabhängig definiert sind (das wäre dann die Tabelle lang_lang), hat meines Erachtens nichts mit der Aufgabenstellung zu tun.

und - ebenfalls nur so nebenbei - wären dann natürlich die idartlang und idcatlang durchaus nicht mehr eindeutig. zurzeit sind sie es.

Das habe ich ja bereits angemerkt. Sie sind es, weil die Funktionen von Contenido (und nicht die Datenbankstruktur) sie eindeutig machen.

Was die Mandanten betrifft: Wenn man sich die Benutzerverwaltung betrachtet, kann man meiner Meinung nach nicht davon ausgehen, dass ein Mandant ein völlig eigenständig verwaltbarer Teil einer Contenido-Installation ist. Ohne einen Systemadmin wird es im aktuellen Status nicht wirklich funktionieren. Sollen tatsächlich verschiedene Kunden Contenido nutzen und sich nicht gegenseitig ins Gehege kommen, trotzdem aber volle Verfügungsgewalt auch über Benutzer und Gruppen haben, wird man nicht um mehrere Contenido-Installationen umhin kommen. Mandanten kann man meines Erachtens momentan sehr gut nutzen, um verschiedene Projekte zu trennen, die aber immer noch unter einer "Oberaufsicht" liegen.

In diesem Zusammenhang zu den Überlegungen in den Folgepostings: Übertragt Eure Überlegungen zu den Sprachen mal auf Benutzer und Gruppen. Alle drei liegen meiner Ansicht nach auf einer Ebene und sollten dementsprechend auch identisch verwaltbar sein. Was meint ihr?

Und ganz zum Schluß und nur nebenbei am unteren Rande angemerkt: Die teilweise vorgebrachte Polemik halte ich für unangebracht und kontraproduktiv. Wenn jemand meine Aussagen für unsinnig hält, soll er es mir direkt sagen, und nicht ein Posting schreiben, das zu 50% aus Nebenbei-Bemerkungen besteht.

[kummer]

calvini, nimms bitte nicht persönlich. es bestreitet ja gar niemand, dass ich im erd fehler finden lassen. wer danach sucht, wird ganz sicher auch fündig werden. es stellt sich einfach die frage, ob und wie die anpassungen ohne vollständige überarbeitung erfolgen sollen. und - wenn man sie denn vornimmt, die überarbeitung - wie es im einzelfall ausgestaltet sein soll. ich bin lediglich der meinung, dass es sich das erd nicht einfach aus den begriffen logisch ableiten lässt. und auch - ich bitte um verzeihung -, dass sprachen nicht notwendigerweise in der hierarchie zuoberst anzulegen sind. das ergibt sich einfach aus unterschieldichen blickwinkeln. man kann einerseits unter mandanten verschiedene projekte unter gemeinsamer oberaufsicht verstehen (wie du es machst) oder eben vollständig voneinander getrennte kunden, die inhaltlich nichts mit einander zu tun haben. und im zweiten fall besteht in der folge nicht der geringste anspruch, daten der gleichen sprache von verschiedenen mandanten zusammenzuziehen.

da unterschiedlichste ansprüche bestehen, muss es auch gestattet sein, über die art und weise der umsetzung zu diskutieren. es mag sein, dass man, wenn man ein lehrbuch am schreiben ist, auf absolut schlüssige erds kommen kann. aber das liegt wohl mehr an der simplifizierung der aufgabenstellung. in der alltagspraxis wird man nicht immer umhin kommen, das eine oder andere mal eine redundanz hin zu nehmen oder eben einen weg zu gehen, der nicht unmittelbar der semantischen logik der begriffe folgt.

zu deiner ursprünglichen frage: probiers doch einfach aus. es wird module geben, die nicht mehr die erwarteten resultate erbringen, da sie davon ausgehen, bei abfrage nur einer sprache auch nur resultate des aktuellen mandanten zu erhalten (und das werden sie auch dann machen, wenn vollständig geklärt ist, dass es falsch ist - oder eben nicht). aber du kannst dann ja die entsprechenden module einfach korrigieren. insofern spielt die ganze diskussion keine rolle. es wird funktionieren und es wird bereiche geben, die unerwartete resultate erzeugen werden. da ist dann halt einfach hand anzulegen.

[calvini]

man kann einerseits unter mandanten verschiedene projekte unter gemeinsamer oberaufsicht verstehen (wie du es machst) oder eben vollständig voneinander getrennte kunden, die inhaltlich nichts mit einander zu tun haben.

Wie siehst Du diese vollständige Trennung im Bezug auf Benutzer und Gruppen? Habe da bisher noch nicht viel eigene Erfahrung gesammelt, aber schon einige Diskussionen hier im Forum verfolgt. Daraus und aus dem wenigen, was ich bisher selbst probiert habe, ziehe ich die Vermutung, dass eine vollständige Trennung (über Mandanten) nicht realisierbar ist. Vollständige Trennung geht nur über eine zweite (dritte etc.) Installation.

zu deiner ursprünglichen frage: probiers doch einfach aus. ... insofern spielt die ganze diskussion keine rolle.

Momentan verwende ich sowieso nur selbst programmierte Module, und das auslösende Problem (Kopieren von ganzen Kategoriebäumen nicht nur innerhalb eines Mandanten sondern auch zwischen verschiedenen Mandanten) habe ich mittlerweile gelöst, indem die entsprechende Routine beim Kopieren einfach die Sprach-Ids des alten Mandanten in die des neuen Mandanten 'übersetzt'. Mir ist dabei halt nur aufgefallen, dass das Datenbankmodell (ohne Zwang) etwas erlaubt, was von den Funktionen nicht genutzt wird und dass es deshalb eventuell zu Fehlern kommen kann. Ich fand die daraus entstehende Diskussion lehrreich und interessant.