Umfangreiche Datenbank-Inhalte in Drupal 8 einbinden

Es kommt auf die Struktur der Daten an, was damit bezweckt werden soll, und wie die Daten zukünftig gepflegt werden sollen.

Ohne eine saubere Analyse ist es schwierig bis unmöglich, eine Strategie zur Verwendung oder dem Import zu entwickeln.

Wenn du Erfahrung mit relationalen Strukturen hast, und in Drupal einigermaßen sattelfest bist, bekommst du das hin.

Ob du Module benötigst, und wenn ja welche, hängt sehr stark von der Datenstruktur und deren Verwendung ab.

Hallo Ronald,
bei der Struktur relationaler Daten sehe ich nicht so den Spielraum. Sie sind normalisiert und es gibt ca. 300 Fremdschlüssel. Um genau zu sein, sie sind in Boyce-Codd-Normalform.
Der Zweck ist die einfache Repräsentation der Daten: Es sollen die Inhalte der Mastertabelle mit den Daten der Detailtabellen auf einer Seite abgebildet werden.
Die zukünftige Pflege ist eine gute Frage: Mein Wunsch wäre die weitere eigenständige Pflege der Datenbank und regelmäßige (halb-)automatisiertes Einspielen der Daten ins CMS.

CMSe haben eigene Datenstrukturen.

Wenn es um bestehende Daten geht, die lediglich zur Anzeige gebracht werden sollen, aber extern gepflegt werden, ist ein CMS meiner Ansicht nach nicht der richtige Ansatz.

Hier bietet sich dann eher ein individuelles Zugriffsmodell, das mit Templates getrieben wird, an.

Dazu muss man allerdings die Datenstrukturen kennen, die angezeigt werden sollen.

Hallo,

also wenn Du ein solches vorgegebenes Datenmodel hast,
dann nimm besser ein Framework wie Yii oder Symfony.
Mit diesen kannst Du Applikationen bauen, die auf einem relationenlen Datenmodel
basieren.
Mit Drupal wirst Du da nicht glücklich.

MfG

Robert

nimm das Framework und die Templatengine, die du am besten kennst, oder suche dir jemanden, der etwas davon versteht.

Eine bestehende Struktur in ein bestehendes CMS zu zwingen, ist schwierig, und macht nicht glücklich, insbesondere, wenn die bestehende Struktur weiterhin bestehen bleiben muss.

Eine Migration ist nur dann sinnvoll, wenn sie das Altsystem ablösen soll.

Aber auch dann ist eine umfangreiche Analyse und genaue Migrationsplanung unumgänglich.

Drupal ist zwar fast eine eierlegende Wollmilchsau, aber man muss es nicht mit aller Gewalt an die Wand zu fahren versuchen.

Danke für Eure Antworten. Ich glaube aber, entweder sind sie zu unkonkret, als dass ich sie nachvollziehen könnte oder wir reden aneinander vorbei.

Vielleicht könntet Ihr mir konkret die folgenden Fragen beantworten:
* Warum ist eine Templateengine wie Symfony eine gute Wahl, das Symfony-basierte Drupal 8 aber eine schlechte? Was kann ich mit Symfony machen und mit Drupal nicht. Bietet Drupal nicht auch im Grunde eine Templateengine?
* Ich hatte geschrieben

D. h. es werden entsprechende Seitentemplates erstellt, in die an unterschiedlichen Stellen Daten eingespielt werden. Diese Daten werden in PostgreSQL per SQL-View zusammengestellt und können entweder direkt von dort geholt werden (wenn Drupal das anbietet) oder erst automatisiert in Drupal eingespielt und dann abgebildet werden. Es geht also nicht darum, "eine bestehende Struktur in ein bestehendes CMS zu zwingen" oder um ein "vorgegebenes Datenmodel". Es gibt vorhandene Inhalte, die ich beliebig per SQL zusammenstellen kann und und nach meinen Vorstellungen ausgeben möchte. Der einzige Unterschied zur üblichen Drupal-Nutzung, besteht darin, dass ich die Daten nicht direkt in Drupal eingebe, sondern importiere. Ist so etwas in Drupal 8 tatsächlich nicht vorgesehen?

PS. Es gibt auch darüber hinaus Gründe für mich, Drupal zu nehmen.

es handelt sich also um eine Anwendung, auch wenn Drupal sehr offen ist, und in vielen Bereichen eher ein Framework ist.

Wenn du jedoch "nur" Daten mit fremdartiger (aus Drupalsicht) Struktur darstellen möchtest, und auch die zukünftige Pflege in einem Fremdsystem weitergeführt werden soll, nutzt du so gut wie nichts vom CMS, musst aber einige Klimmzüge machen, um innerhalb dieses deine Darstellung hineinzubasteln.

Deshalb ist es sinnvoller, gleich eine Anwendung mit der bestehenden Datenstruktur zu bauen, und auf den Overhead eines CMS zu verzichten.

Willst du aber ein CMS, das nur so nebenbei externe Daten darstellen soll, ist die Sichtweise eine andere.

Dann musst du ein paar Klimmzüge in Form eigener Module basteln, um die externen Daten anzeigen zu können, der Rest steht aber schon.

Das geht aber aus deiner Anfrage nicht hervor.

Einiges an Arbeit kostet es in jedem Falle. Vor Allem zunächst einmal ein schlüssiges Konzept.

Symfony is ein PHP Framework, das zu großen Teilen in Drupal 8 integriert wurde. Vor allem wurde dessen Template-Engine "Twig" übernommen.

Wenn es nur um die Darstellung und evtl. Durchsuchbarkeit der Inhalte einer fremden Datenbank geht, die weiterhin mit einer anderen Anwendung gepflegt werden sollen, dann hilft evtl. folgender Ansatz.
Man gebe Drupal lesenden Zugriff auf diese Datenbank und schreibe ein Modul, daß die Daten wie gewünscht ausliest und darstellt. Ohne eigenes Custom-Modul wird es dann wohl nicht gehen.
Man kann eigene Entitäten in der Drupal-DB schaffen, um die Daten zum Teil zu verknüpfen. Das ist insbesondere hilfreich, wenn man einfachen Zugriff mit anderen Drupal.Technolgie z.B. mit Search API schaffen möchte.
Gewonnen hat man dann auf jeden Fall die Drupal Theme-Engine, Caching-Technologien inkl. dem aktuellen Bigpipe Ansatz und bei Bedarf eine Benutzer-Verwaltung usw.

will man nur eine Oberfläche für eine externe Datenbank, ist Drupal ein Overkill.
Der Aufwand für die Einbindung der Darstellung dürfte nahezu identisch zu dem Aufwand zur Erstellung eines Darstellungsprogrammes sein.

Deshlab muss Drupal der Mehrwert sein. Drupal als Templatemachine ist nämlich auch verkehrt ;-)

Danke, jetzt sehe ich klarer.
Ein paar Fragen stellen sich mir noch:

1) Zwar basiert Drupal auf Symfony, zum Anzeigen dieser Seiten programmiere ich aber ein Custom Module. Komme ich dabei mit Symfony in Kontakt, sprich wird die Darstellung als Twig-Template generiert oder wird Symfony in Drupal8 nur intern genutzt?
2) So wie ich es verstehe, muss ich für jede Template-Seite ein eigenes Custom Modul schreiben, richtig? Wenn ich also aus meinen Daten eine Seite person (mit zusätzlichen Adress- und Berufsangaben) generieren möchte, ist das ein Custom Modul; eine Seite auto (mit Fahrzeugtyp und Farbe etc.) wäre ein weiteres?
3) Wenn man OO-PHP ordentlich beherrscht, dann sind Custom Modules für meine Zwecke aber kein großer Aufwand, oder? Ich möchte ja nur Daten auf der Seite platzieren. Zumindest suggerieren das die Einsteigertutorials, die ich gelesen habe.
4)

Was meint hier "zum Teil"? Ist eine komplette Verknüpfung nicht sinnvoll bzw. nicht praktikabel?
5) Wenn ich Dinge benötige wie eine Benutzerverwaltung, umfangreiche Suchfunktionen, vielfältige Feedback-Formulare etc. dann könnte ich mir das sicherlich auch irgendwie in Symfony basteln, aber Drupal dürfte dann doch komfortabler und vor allem wartbarer sein, oder?

Danke für Eure Hilfe!

Hi nochmal,

bei diesen Vorgaben:
Relationale Datenbank,über 300 Tabellen 100'000 Einträge

Ich gehe davon aus, dass Du schon von der DB her die relationale Integrität wahren möchtest (InnoDB + foreign key constraints, evtl. Transactions?).
Da fährst Du besser mit einem Framework wie Yii oder Symfony.
Yii kann aus den Tabellen gleich MVC Klassen generieren.
Symfony2 generiert Model und Controller Klassen, Views musst Du selber machen.
Von Drupal rate ich für Deine Vorgaben leider ab.

Gruss

Robert

PS:
Sorry, hab ich erst später gesehen:
Wenn es Dir nur um die Anzeige der Daten geht, kannst Du das natürlich auch in Drupal machen!

das ist quark.

Module sind für Funktionalität, die Drupal selbst nicht, oder nicht in der benötigten Weise bietet.

Templates sind für die Darstellung von Inhalten.

Views sind für die Datenselektion (mit Einfluß auf die Darstellung)

Wenn man mit Drupal sauber arbeitet, hat man eine klare Trennung zwischen Inhalten und deren Darstellung.

Gleiche Inhalte können unterschiedlich dargestellt werden, oder die gleiche Darstellung kann für unterschiedliche Daten verwendet werden.

So, jetzt habe ich dich vollends verwirrt.

Je nachdem, was in diesen Tabellen hinterlegt ist, und wie darauf zugegriffen werden soll, ergeben sich Lösungsansätze.

Datenbanken mit 1 Mio. Records sind problemlos, wenn die Strukturen bekannt sind, und der Verwendungszweck klar definiert ist.

Du kannst auch auf die Originaldatenbank zugreifen, wenn die dafür ein einsprechendes Zugriffsmodul schreibst, oder diese als mySQL-DB vorliegt.

Mit Drupal ist nichts unmöglich. Es kann jedoch Arbeit machen.

Mit Postgres (wie in diesem Fall) und noch ein paar anderen Datenbanken kann Drupal auch umgehen. Da es hier aber weniger Nutzer und Entwickler in der Community gibt, findet man entsprechend weniger Unterstützung.