Solved: Fragen zur Anbindung von Datenbanken

Hewera-Harz · ‎09-21-2016

Ich habe da mal Fragen zur Anbindung von Datenbanken

Wir haben bislang in unseren Systemen die Derby verwendet (ja ich weiß, soll man nicht für produktive Projekte).

Da wir eine demnächst eine Umstrukturierung der Projekte vornehmen, wäre es nun günstig, sich auch direkt um die Datenbankanbindung der Projekte zu kümmern.

Kann man alle Daten für Datenquellen in einem zentralen Projekt pflegen?

Ich beschreibe mal was wir vorhaben.

Wir werden demnächst ein zentrales Projekt aufsetzen, in dem alle Inhalte und Medien gepflegt werden.

Von dort aus werden wir die Inhalte und Medien per Corporate Content und Corporate Media in die einzelnen Webprojekte verteilen.

Eine Überlegung ist es, die Datenquellen Verwaltung auch in das zentrale Projekt zu verlegen.

Dazu wollen wir folgendermaßen vorgehen:

Export der Projekte und Import mit Wechsel des Datenbank-Layers auf einen Standard-Layer (MySQL) --> Damit haben wir die Daten dann in der externen MySQL
Export der Datenbank Schemata (FirstSpirit) aus den einzelnen Projekten und Import in das zentrale Projekt
schreibender Zugriff und Schema Syc für das zentrale Projekt, nur lesender Zugriff und kein Schema Sync für die Web-Projekte

Da wir bei einigen Tabellen aber auch Seitenreferenzen speichern, stellt sich nun die Frage, wie man bei der Pflege der Daten im zentralen Projekt an die PageRefs der jeweiligen Projekte kommt.

Oder muss man in diesem Fall die Pflege der Daten in dem entsprechenden Web-Projekt belassen (schreibender Zugriff) und im zentralen Projekt nur eine lesende Anbindung realisieren?

Ist der Standard-Layer ok oder wäre der DBA-Layer besser?

Ein Test für einen Import und Wechsel des Datenbank-Layers auf einen mit folgender Layer Konfiguration (=Standard-Layer) hat funktioniert.

# test

jdbc.DRIVER=com.mysql.jdbc.Driver

jdbc.PASSWORD=****

jdbc.SCHEMA=fspirit

jdbc.URL=jdbc:mysql://mywebe/fspirit

jdbc.USER=cms

jdbc.layerclass=de.espirit.or.impl.mysql.MySQLLayer

Die Testtabellen aus einem Testprojekt heraus wurden in der Datenbank fspirit mit Systemspalten (fs_gid ...) und selbst konfigurierten Spalten angelegt.

Sachdienliche Hinweise für meine Fragen sind gerne willkommen.

Danke und Grüße

Petra Hewera-Harz

PS:

Ich denke, dass man die Doku in Bezug Datenbankanbindung/-schemata überarbeiten sollte, um hier mehr Klarheit zu bekommen.

Irritiert sind bei dieser Thematik die sich meines Erachtens teilweise widersprechenden Aussagen.

In der Doku heißt es, dass "Die Struktur und die Inhalte einer externen Datenbank dürfen nicht verändert werden.

Im Gegensatz zu internen Datenbanken, ist für externe Datenbanken nur ein lesender aber kein schreibender Zugriff möglich.".

Hm!, die interne Datenbank Derby soll man produktiv nicht nutzen und externe Datenbanken soll man nur lesend anbinden.

Gleichzeitig wird beschrieben, wie man einen gemeinsamen Zugriff auf Datenbanken realisiert: "Dabei sollte sichergestellt werden,

dass nur maximal ein Projekt schreibenden Zugriff auf die Datenbank erhält und für alle weiteren Projekte nur der gemeinsame,

lesende Zugriff auf die entsprechenden Datenbank-Inhalte möglich ist." Zum Datenbank-Layer heißt es: "Im Feld „Datenbank-Layer“ muss ein bestehender Datenbank-Layer zu einer Datenbank ausgewählt werden,

in der die einzelnen Datenbanktabellen für dieses Schema gespeichert werden sollen."

hoebbel · ‎09-30-2016

Hallo Frau Hewera-Harz,

ich glaube, dass das Problem hier ist, dass hier zwischen technischen Definitionen und den verschiedenen Anwendungsfällen unterschieden werden muss.

Die technische Definition kann relativ einfach ausgedrückt werden:

Es gibt einen Tabellenraum, also den Raum in der Datenbank, der die entsprechenden Tabellen umschließt und in den einzelnen Datenbanken unterschiedlich benannt wird (Schema, Datenbank,...). In FirstSpirit wird dieser Raum Schema genannt. Und zwar sowohl in der Konfiguration des Layers (also der Anbindung der Datenbank) als auch im SiteArchitect (für die Darstellung der Tabellen)

Um einen entsprechenden Tabellenraum anzulegen, benötigt man in der Datenbank DBA Rechte (also administrative Rechte), welche häufig Anwendungen nicht gegeben werden.

Wenn FirstSpirit entsprechende Rechte bekommt, so kann die Layerdefinition so angelegt werden, dass dort kein Schema angegeben wird. Dann wird FirstSpirit für jedes mit diesem Layer verknüpfte Datenbankschema einen neuen Tabellenraum anlegen. Im Umkehrschluß bedeutet dies aber auch, dass die Layerkonfiguration nicht auf einen spezifischen Tabellenraum zeigt. Diese Layerkonfiguration wird, aufgrund der benötigten Rechte, DBA Layer genannt.

Wenn in der Konfiguration des Layers direkt auf einen entsprechenden Tabellenraum zeigt, so werden deutlich weniger Rechte in der Datenbank benötigt, um diesen sinnvoll nutzen zu können. Da dies die übliche Konfiguration bei vielen Kunden ist, haben wir diesen Layer "Standardlayer" genannt.

Dieser Layer hat die Eigenschaft, dass er genau auf einen Tabellenraum zeigt, es über diesen also direkt möglich ist, entsprechende Tabellen zu identifizieren.

Der "normale" Anwendungsfall für Standard-Layer ist nun, dass ein Datenbank-Administrator für jedes Schema in jedem Projekt einen entsprechenden Tabellenraum in der Datenbank anlegt und dann entsprechende Standardlayer in FirstSpirit erzeugt werden, die auf diesen Tabellenraum zeigen.

In die Projekte werden diese Standardlayer normalerweise schreibend eingebunden, so dass über FirstSpirit dann Tabellen und Datensätze in der Datenbank angelegt werden können.

Im Gegensatz zu den DBA-Layern kann man Standardlayer aber auch dazu benutzen, bereits vorhandene Daten aus einer Datenbank auszulesen, da diese ja direkt auf einen entsprechenden Tabellenraum in der Datenbank zeigen.

Hierbei handelt es sich normalerweise um Daten, die aus einer anderen Anwendung stammen (z.B. Personalstammblätter) und die in dem FirstSpirit Projekt genutzt werden sollen.

Dies ist die Nutzungsweise, die in FirstSpirit als "externe Datenbank" bezeichnet wird.

In Abgrenzung zu diesem Begriff werden Datenbanken, die unter FirstSpirit Kontrolle stehen, auch häufig als interne Datenbank bezeichnet.

Und schließlich gibt es noch den Sonderfall, den Sie beschreiben - Sie nutzen eine Datenbank in einem zentralen Projekt (also eine schreibend angebundene, "interne Datenbank") und wollen diese in anderen Projekten zusätzlich einbinden. Dort müssen Sie diese "interne Datenbank" lesend einbinden (also genauso wie oben beschreiben für "externe Datenbanken"). Dies ist die Stelle, an der die Begriffe sich mischen. Hier wird nun die "interne Datenbank" aus dem Quellprojekt in den Zielprojekten als "externe Datenbank" bezeichnet, obwohl diese Datenbank nur Daten beinhaltet, die unter FirstSpirit Kontrolle stehen.

Ich hoffe, dass ich mit dieser kurzen Abhandlung die Begrifflichkeiten etwas deutlicher machen konnte und dass diese nicht zu weiterer Verwirrung führt

Viele Grüsse aus Dortmund,

Holger Höbbel

View solution in original post

Peter_Jodeleit · ‎09-21-2016

Die Terminologie "intern" und "extern" bezieht sich in FirstSpirit bezüglich Datenbanken auf "wo wird das Schema gepflegt". Wird es in FirstSpirit gepflegt, ist das in der Terminologie eine "interne" Datenbank, wird eine vorhandenes Datenbank-Schema in FirstSpirit angebunden, eine "externe" Datenbank.

Derby kann sowohl "intern" als auch "extern" angebunden sein, der Standard-Anwendungsfall ist aber wohl als "interne" Datenbank. Allerdings ist Derby keine Datenbank, die besonders gut skaliert (und sie hat auch noch ein paar andere Einschränkungen), daher wird diese nicht für den produktiven Gebrauch empfohlen.

Ich hoffe, diese Erläuterung hilft etwas.

Zum Thema "Benutzung von FirstSpirit-Schemata über mehrere Projekte" kann ich keine Empfehlung geben, das hängt von mehreren Faktoren ab, die individuell bewertet werden müssen.

Peter

hoebbel · ‎09-23-2016

Hallo Frau Hewera-Harz,

ich glaube der folgende Artikel wird Ihnen weiterhelfen:

http://www.e-spirit.com/de/blog/inside-firstspirit/detailseite/2014/01/23/connecting-read-only-datab...

Viele Grüsse aus Dortmund,

Holger Höbbel

marza · ‎09-29-2016

Hallo Petra,

benötigst Du noch weitere Hilfe oder haben Dir die Antworten von Peter und Holger bereits geholfen?

In diesem Fall wäre es super, wenn Du die "richtige Antwort" entsprechend markierst, damit auch andere Community-Teilnehmer diese auf den ersten Blick finden. Solltest Du zwischenzeitlich eine eigene Lösung gefunden haben, wäre es nett, wenn Du diese hier bereitstellst.

Viele Grüße

Marian

Hewera-Harz · ‎09-29-2016

Hallo,

leider erfüllte für mich keine der Antworten den Status "richtig".

Hilfreich waren sie aber schon.

Den Artikel unter inside-fspirit habe ich mir durchgelesen, aber noch nicht praktisch nachvollzogen. Ich frage mich aber, warum der read-only Datenbank-Layer nicht einfach in der Projektkonfiguration von Anfang an auf lesend gestellt wird. Ich hoffe, dass mir dies klar wird, wenn ich den Vorgang praktisch nachgestellt habe.

Ich bin immer noch der Meinung, dass die Doku in Bezug auf das Thema Datenbanken mal überarbeitet werden müsste, da Sie auch in Verbindung mit dem Standard Layer, für den ja ein Schema eingetragen wird und der damit eine Anbindung einer externen Datenbank darstellt, von einem schreibenden Zugriff spricht.

Zitat (online Doku - /help/odfs/vorlagen-grundlagen/aufbau-von-vorlagen/datenbank-schemata/schema-hinzufuegen/index.html😞

Standard-Layer: Soll direkt auf einem vorhandenen Datenbank-Schema gearbeitet werden, muss ein Standard-Layer ausgewählt werden. Dieser Layer kann in mehreren FirstSpirit-Projekten verwendet werden, die alle Inhalte aus der gleichen Datenbank lesen. Damit es bei der Verwendung eines Standard-Layers nicht zu Überschneidungen kommt, sollte jeweils nur eines der beteiligten Projekte das Schreibrecht auf der Datenbank besitzen (s. o. „Gemeinsamer Datenbankzugriff“).

In der Dokumentation für Administratoren wird unter 4.9.8 die Anbindung einer externen Datenbank behandelt.

Vorher wird unter 4.9.4.2 wird der Standard-Layer definiert:

<database>.jdbc.SCHEMA ...

Dieser Parameter definiert das von FirstSpirit zu

verwendende Schema auf dem DBMS (Datenbank-Management-

System)....

Sofern dieser Parameter definiert ist, handelt es sich um einen

Standard-Layer.

>> Mein Schluss daraus: Eine Datenbankanbindung mit einem Standard-Layer ist damit immer eine externe Anbindung, weil ein vorhandenes Schema verwendet wird.

Laut Doku sollen externe Datenbanken immer nur lesend angebunden werden und das ist ein Widerspruch zu dem Abschnitt über Standard-Layer in der Online Doku (s.o.).

Wie ich sehen konnte, bin ich ja nicht die erste und einzige, die dieses Thema verwirrt und die Antworten auf solche Anfragen haben es auch nicht eindeutig entwirrt.

Auch wenn ich beide Antworten bislang nur als "Hilfreich" eingestuft habe, möchte ich mich dafür bedanken.

Viele Grüße

Petra Hewera-Harz

hoebbel · ‎09-30-2016