Questions & Answers

[Charlotte_Koeni]

Hallo Zusammen,

mich würde mal interessieren wie ihr die im Folgenden beschriebene Anforderung angehen würdet. Gibt es eine Best-Pactice-Empfehlung?

Wie verteilt man am besten Tabellenvorlagen bzw. Schmata über ein Paket. Geht das überhaupt ohne weiteres und so dass es benutzerfreundlich für den Redakteur ist?

Geplant ist, dass es im Masterprojekt NICHT alle Sprachen gibt, die es in den Slave-Projekten geben könnte. Das bedeutet man kann das Paket eigentlich nur initial verteilen und dann die Paketbeziehung wieder lösen, da man manuell im Schema die Sprachen nachziehen muss, je nach Slave-projekt.

Wenn jetzt doch im Masterprojekt alle Sprachen vorhanden wären, dann könnten die Redakteure zwar sofort anfangen zu pflegen, aber da ja alle Slave-Projekte das gleichen Schema und die gleichen Tabellen haben,  würden dann in allen Slave-Projekten alle Einträge sichtbar sein (evtl. auch totale leere Einträge, weil eben die entsprechende Sprache nicht vorhanden ist). Das ist also seehr benutzerunfreundlich.

Man könnte auch nach dem das Paket verteilt wurde die Paketbeziehung lösen und dann das Schema ändern, so dass die Tabellen neu angelegt werden und so würde jedes Projekt seine eigenen Tabellen erhalten.

Die beschriebenen Vorgehensweisen sind nicht so optimal, oder?

Viele Grüße

Charlotte König

[jpee]

Hallo Frau König,

meistens hat man in Projekten mit Master-Slave-Beziehung den Fall, dass ein Slave-Projekt seine eigene Datenbank besitzt. Das heißt die Struktur, also das Schema inklusive der Tabellenvorlagen wird vererbt, die Inhalte also die Entitäten bzw. Datenquellendatensätze jedoch nicht.

Trifft dies für Sie zu?

Für den Fall sind folgenden Lösungsansätze denkbar:

• manuell Schema kopieren mit austausch des dbnamens und Templateaktualisierung der Tabellenvorlagen über den TemplateStoreRoot-Dialog sowie manuellem Sprachenmapping.
• In der Paketverwaltung kann man ein Skript hinterlegen, welches nach dem Verteilen ausgeführt wird. Dort könnte man die manuellen Schritte automatisiert realsieren, also das kopieren des Schemas sowie das Sprachenmapping.

Viele Grüße

Johannes Perlet

[Charlotte_Koeni]

Hallo

bei unseren bisherigen Kunden gibt es leider für alle Projekte nur eine DB. Aber das hört sich ganz gut an und auch nicht so aufwändig wie meine Szenarien.

Muss der dbname ausgetauscht werden? Das ist doch der Name des Schemas, welches in der DB angelegt wird. Und wenn sowieso die DB eine komplett andere ist, dann ist es ja egal ob die Schemata gleich heißen.

Ich bin mir nicht sicher was Sie mit "Templateaktualisierung der Tabellenvorlage über den TemplateStoreRoot-Dialog" meinen, damit bin ich bisher noch nicht in Berührung gekommen. !?

Eine Verbesserung zu meinen Vorschlägen wäre ja schon, wenn man die gleiche DB für alle hat, aber in unterschiedlichen Schemata die Tabellen speichert. Dann würde man nur den Schema - Name ändern müssen (dbname) der Rest des XML-Schemas könnte man aber lassen.

Viele Grüße

Charlotte König

[jpee]

Hallo Frau König,

in meinem letzten Post habe ich Datenbank mit Schema in einer Datenbank gleichgesetzt.

In der Servereinstellung im Punkt Datenbanken ist die Bezeichnung Layer, also jeder Slave besitzt seinen eigenen Layer.

Das scheint dann vermutlich auch auf Ihre Architektur zu passen.

Viele Grüße

Johannes Perlet

[Charlotte_Koeni]

Ah ok.

Wie ist das eigentlich wenn ein Projekt mehrere Layer (also Verbindungen zu einer DB) hat und man dort dann ein Schema rein kopiert. Woher weiß das System welchen Layer es nehmen soll für das Schema? Und was wenn die DBs andere sind wie in dem Masterprojekt?

Gruß

charlotte könig

[jpee]

Wenn sie das Schema über den Dialog Extern bearbeiten öffnen, können Sie in der zweiten Zeile z.B.

<xs:element dbName="layername" name="p11097_10118" temporal="1" version="4.0">

das Mapping zwischen Layer und fsschema sehen, wobei der name freigewählt werden kann und der dbName den des zu benutzenden Layers entsprechen muss. Den Layer anzupassen wäre Aufgabe des Scripts das wir oben schon erwähnt hatten und müsste selbst implementiert werden.

Nähere Infos dazu finden Sie auch hier: https://community.e-spirit.com/message/1737#1737

Viele Grüße

Johannes Perlet

[Charlotte_Koeni]

Hallo,

vielen Dank für Ihre Antworten und den Link.

Ich habe das Prinzip verstanden und werde es mal versuchen umzusetzen.

Abgesehen davon wundert es mich, dass Sie schreiben, dass der "dbName" (xs:element) der Layername ist. Ich gehe davon aus, dass das der Schema-Name ist, denn wenn man sich dann die tatsächlich erstellten Tabellen in der Datenbank anschaut, dann ist genau der Name der hinter "dbName=" steht auch der Name des Schemas in der DB.

Folgendes ist mir nämlich unklar:

Wenn ich also eine Datenbank mit dem Namen "DB_A" habe und darin ein Schema erstelle, und dann in dem Schema im "dbName=" (xs:element) "P12345_ProjektID" steht. Woher weiß ich denn im Nachhinein (besonders wenn ich auch mehrere Layer zur Auswahl habe) dass "P12345_ProjektID" zur Datebank "DB_A" gehört.

Noch eine Bemerkung zu ihrem vorigen Kommentar:

In der Servereinstellung im Punkt Datenbanken ist die Bezeichnung Layer, also jeder Slave besitzt seinen eigenen Layer.

Das scheint dann vermutlich auch auf Ihre Architektur zu passen.

Genau. Layer = Datenbank. Nein, wir haben für ALLE Projekte nur eine Datenbank. Aber für Neukunden, wäre es vielleicht auch interessant, wenn man mehrere DBs hat - dann wäre man je Projekt komplett unabhängig.

Nachricht geändert durch Charlotte König

[jpee]

Hallo Frau König,

Sie haben recht:

• name = Name des Layers (wobei die Layer zu Ordnung glaube ich nicht extern geändert werden kann, sondern nur wie im oben angegebenen Link über ein Skript)
• dbname = Name des orSchemas

Pro Layer kann man in FirstSpirit eine DB, ein Schema und einen User zuweisen, man kann also auch für eine DB mit mehreren Schemen mehrere Layer anlegen oder mit mehreren DBs auch mehrere Layer.

Ich hoffe das hilft Ihnen weiter.

Viele Grüße

Johannes Perlet

[Charlotte_Koeni]

Hallo,

nein nicht ganz. Ich glaube, der "name" ist auch der Name des Schemas und zwar der Name der in FirstSpirit dafür verwendet wird (während der dbname, der Name ist der in der Datenbank selbst verwendet wird).

Aber ich frage mich immer noch wie ich im Nachhinein sehen kann zu welchem Layer mein Schema und somit meine Tabellen zugeordnet sind, ohne in die "richtige" Datenbank auf dem Server zu schauen. Durch das XML-Schema ist das nicht möglich. Initial steht ja in dbName UND in name das gleiche drin. Und zwar "pNummer_ProjektID". Wobei die "pNummer" die eindeutige FS-ID für das gerade angelegte Schema ist. Hier ist kein Hinweis darauf zu finden, wie der Layer heißt der verwendet worden ist.

Gruß

charlotte

[jpee]

Hallo Frau König,

über die Versionshistorie kann man beim Vergleich zweier Versionen im Reiter Attribute die Layerzuordnung sehen.

Oder auch im Skript im Link oben, da wird auch mit dem Layer gearbeitet.

Viele Grüße

Johannes Perlet