Questions & Answers

[l-kozuch]

Hallo,

um eine Datenbank zentral nutzen zu wollen muss ja der entsprechende Datenbank-Layer mit dem Häckchen bei "Kein Schema Sync" versehen werden. Somit hat jedes Projekt das diesen Layer als DB nutzt, Zugrriff auf die zentrale Datenbank.

Nun habe ich parallel weitere Layer, welche ganz "normal" genutzt werden. Die Layer liegen ja physikalisch auf einer einzigen Datenbank. Gibt es Probleme wenn ich auf einer Datenbank (oracle) einen Layer als zentrale Datenbank nutzen will (mit Häckchen bei "Kein Schmea Sync") und einen anderen Layer als projektspezifische DB? Mit Problemen meine ich, ob eine Datenbank (oracle) zugleich als zentrale (Layer 1) und normale DB (Layer 2) verwendet werden darf, oder ist hier im Hintergrund eine zweite Datenbank notwendig (zweite oracle Datenbank)?

Viele Grüße

Lukas

[marro · Accepted solution]

Hallo,

da die Layer unabhängig voneinander sind, auch wenn sie auf derselben DB laufen, sollte es kein Problem sein, für einen Layer den Schema Sync zu deaktivieren und für einen anderen Layer nicht.

Viele Grüße,

Donato

[klein]

Hallo,

wenn ich die Frage richtig verstanden habe, dann benötigt man eigentlich nicht _zwei_ Layerdefinitionen, denn es genügt eine Layerdefinitionen, wobei in einem Projekt (Master-, Zentral, Hauptprojekt) dann das Häckchen bei "Kein Schema Sync" _nicht_ gesetzt wird und bei allen anderen Projekten (Slave-, Sekundärprojekt) dieses Häckchendoch gesetzt wird. Somit kann man ja die DB-Inhalte aus dem Masterprojekt auch in den Slaveprojekten sehen/verlinken.

[l-kozuch]

Nun stellt sich noch die Frage ob zwei Layer notwendig sind oder nur einer ausreicht:

Wir haben mehrere Schemas im Master Projekt - einige davon sollen als zentrale Datenquelle genutzt werden und einige nicht!

Meiner Ansicht nach benötige ich zwei Layer:

Master Projekt: Layer_1 für "normale" Schemas

Master Projekt: Layer_2 für zentrale Schemas

Sekundär/Slave Projekt: Layer_1 für "normale" Schemas

Sekundär/Slave Projekt: Layer_2 für zentrale Schemas (mit Häkchen bei "kein Sync")

Ist das so korrekt? Wenn ich nur einen Layer hätte, könnte ich doch im Sekundär/Slave das Häkchen bei "kein Sync" nicht setzen, da sonst alle "normalen" Schemas auch zentral wären oder?

Viele Grüße

Lukas Kozuch

[king]

Sehr geehrter Herr Kozuch,

wir nehmen an, dass Sie die Unterscheidung in:

• zentrales Schema
• "normales" Schema

auf der Grundlage der FirstSpirit projektspezifischen "kein Schema Sync"-Konfiguration treffen (hier am Beispiel einer exemplarischen DB-Layer-Auswahl im FirstSpirit-Projekt "wcms_c"):

Über diesen Schalter werden Änderungen an projektspezifischen DB-Modellen in FirstSpirit mit der realen DB synchronisiert (sofern die Checkbox NICHT aktiviert ist), d.h. etwaige neue Tabellen/Spalten kommen hinzu bzw. werden gelöscht.

Nach unserem Dafürhalten ist die Eigenschaft "kein Schema Sync" projektspezifisch zu aktivieren/zu deaktivieren - wirkt also NICHT GLOBAL auf dem gesamten konfigurierten JDBC DB-Layer! Sollte sich unser Verständnis nicht mit der Realität decken bitte das Problem deutlicher beschreiben!

[l-kozuch]

Hallo Herr King,

ja richtig, dass ganze findet natürlich projektspezifisch statt.

Kurze Erklärung was ich unter normal und zentral verstehe:

Zentral: Ein  DB-Schema was zentral genutzt werden soll (in beliebig vielen Sekundärprojekten) wird im Master Projekt angelegt, dann über Corporate Content in das Sekundärprojekt verteilt. In dem Sekundärprojekt muss auf demselben Layer das Häkchen bei "kein Sync" gesetzt werden, damit ich in der Datenquelle des Sekundärprojekts auch die Datensätze sehe, die im Master angelegt worden sind.

"Normal": Ein DB-Schema wird im Master angelegt (z. B. News) und mit Datensätzen befüllt. Im Sekundärprojekt befindet sich zwar das gleiche Schema (wird manuell importiert), es sollen aber nicht die Datensätze aus dem Master angezeigt werden. Somit darf das Häkchen bei "kein Sync" nicht gesetzt sein.

Daraus schließe ich, dass ich für DB-Schemas die zentral genutzt werden sollen, im Sekundärprojekt einen Layer brauche mit Häkchen. Die zentral genutzten DB-Schemas sollten meiner Meinung nach im Master Projekt und im Sekundärprojekt auf demselben Layer liegen!

Für Schemas die nicht zentral genutzt werden, brauche ich einen weiteren Layer. Im Master und Sekundärprojekt wird somit ein anderer Layer verwendet und das Häkchen wird im Sekundärprojekt nicht gesetzt.

(Siehe auch Doku FirstSpirit Paket-Verwaltung Kapitel 10)

Ich würde mich über einen Kommentar von eSpirit freuen 🙂

Danke und viele Grüße

Lukas Kozuch

[king]

Hallo Herr Kozuch,

sprechen Sie bei einem DB-Schema von einem FirstSpirit-Schema? Da wir eine Oracle-DB-Anbindung als Layer konfiguriert haben, wird FirstSpirit-seitig bei jedem Projekt, das ein FirstSpirit-Schema (s. Screenshot nabe) besitzt/erstellt:

ein Oracle-DB-Schema dynamisch angelegt. Es folgt der folgenden Namenskonvention "P<scheme_node_firstspirit_id>_<project_id>"

Für dieses dynamisch durch FirstSpirit erstellte Schema, kann jedoch nicht konfigurativ entschieden werden, ob dafür der Schalter "kein Schema-Sync" aktiviert werden soll oder nicht. Diese Konfiguration ist lediglich auf der Ebene des DB-Layers möglich - nicht jedoch auf dynamisch in FirstSpirit verwalteten Oracle-Schemen. Dazu der vollständigkeithalber nochmals der Screenshot anbei:

Wie hier zu sehen ist, sind lediglich für die im Projekt zugeordneten DB-Layer die Eigenschaften setzbar - nicht jedoch auf Ebene der in einem Layer verwalteten Schemen.

[l-kozuch]

Hallo Herr King,

jep DB-Schema = FirstSpirit Schema im Client unter Datenbank-Schemata.

Leider gehen die Links nicht, sodass ich ihre Argumentation nicht ganz verstehe. Ich weiß leider auch nicht was "im Hintergrund" von FirstSpirit in Kombination mit der oracle passiert. Ich bin mir aber relativ sicher, dass wir zwei Layer brauchen.

Vielleicht bringt ja Herr Leinich mehr Licht ins Dunkle.

Viele Grüße

Lukas Kozuch

[rrichter]

Hallo Herr Kozuch,

wenn Sie mit Standard-Layern arbeiten, benötigen Sie ja sogar einen Standard-Layer pro Schema im Master-Projekt.

Diese müssen natürlich je nach Nutzung im Zielprojekt dort entweder das Häkchen gesetzt (lesend) oder nicht gesetzt haben (lokal schreibend).

Bei DBA-Layern (in die man mehrere Schemata importieren kann) gilt natürlich das, was Sie oben schreiben. Auf jeden Fall benötigt man mindestens zwei Layer-Definitionen, wenn man eine wie von Ihnen beschriebene Konfiguration hat.

Viele Grüße,

Raphael Richter.

[l-kozuch]

Hallo Herr Richter,

ja so sehe ich das auch. Hätte ich die Kombination mit normalen Schemas und zentralen Schemas nicht, wäre ja ein Layer evtl. ausreichend. Da ich aber einige Schemen zentral (mit Häkchen im Slaveprojekt) und einige nicht zentral nutzen will, führt kein Weg an zwei Layern vorbei.

Viele Grüße

Lukas Kozuch