Questions & Answers

[dleinich]

Hallo zusammen,

ich habe zwei Tabellen mit ähnlichen Inhalten (z.B. news und pressemitteilungen) sowie eine Tabelle kategorien, in der (man glaubt es kaum) Kategorien zu diesen Inhalten gespeichert werden und die über eine M:N Fremdschlüssel-Beziehung mit den Inhaltstabellen verbunden ist.

Nun sollen die News und Pressemitteilungen gemeinsam nach Datum sortiert in einer Absatzvorlage ausgegeben werden. In SQL mache ich üblicherweise einen UNION auf die Tabellen und arbeite mit dem Ergebnis.

Damit ich die Daten auch in FirstSpirit nutzen kann, habe ich zuerst eine neue Tabelle namens teaser angelegt, die alle gemeinsamen Informationen abbildet und auch hier die Fremdschlüssel-Beziehung zur keywords Tabelle hinzugefügt. Direkt in der Datenbank (MySQL in diesem Fall) wurde die Tabelle dann verworfen und durch einen View ersetzt, der alle Felder enthält und genau den oben angesprochenen UNION als Basis hat. Auch die Verknüpfungstabelle für die Fremdschlüssel-Beziehung wurde in einen View umgewandelt, damit die Verknüpungen beider Inhaltstabellen berücksichtigt werden.

Soweit so gut. Ich kann jetzt also in FirstSpirit auf den View zugreiffen (natürlich nur lesend) und entsprechende Seiten mit den zusammgefassten Informationen generieren. Hurra! Oder?

Das Problem das noch besteht, und damit der Grund dieses Postings, ist, dass mir das ganze Setup um die Ohren fliegt, wenn ich einen Eintrag der keywords freigeben möchte. Das das passiert ist logisch, da FirstSpirit natürlich versucht einige Felder (fs_release_to, etc.) der Beziehungstabelle zu setzen, das klappt aber natürlich nicht, da es sich um einen nicht beschreibbaren View handelt.

Die Frage ist also, ob es entweder eine Möglichkeit gibt FirstSpirit zu sagen, dass er eine Beziehungstabelle einfach nicht anfassen soll oder vielleicht sogar einen anderen, sinnvollen Weg gibt, um die beschriebene Funktionalität abzubilden.

Danke schon mal im Voraus für kreative Vorschläge zur Lösung!

[hoebbel]

Hallo Daniel,

erstmal der Hinweis zu dem Aufbau der in FirstSpirit verwendeten temporalen Datenbanken:

Bernd Eßmanns Blog

Das Problem, welches Du hast, hängt imho direkt damit zusammen. Da FirstSpirit jede Änderung an einem Datensatz als eigenen Datensatz speichert, könntest Du bei der Verwendung von UNION massive Probleme bekommen, da hier ja laienhaft aufgedrück implizit ein DISTINCT durchgeführt wird.

Wenn man den temporalen Aspekt der Datenbank berücksichtigt, habe ich die Vermutung, dass Du eigentlich zwei Views für dein Vorhaben benötigst:

Einmal für die Vorschau: Hier darfst Du nur Datensätze berücksichtigen, bei denen FS_VALID_TO = max(Long) ist.

Einmal für die Generierung: Hier muss dann FS_RELEASE_TO = max(Long) sein.

Eine Freigabe in diesen beiden Views ist dann nicht notwendig, da der View für die Generierung nur freigegebene Datensätze beinhaltet.

Folgende offene Punkte gibt es aber danach immer noch [falls meine Vermutung überhaupt korrekt ist]:

- Das Ganze ist natürlich nicht Export/Import sicher, da FirstSpirit den View als Tabelle beim Import anlegen wird.

- Historische Generierungen werden nicht funktionieren, da in den Views ja "nur" die aktuellen [freigegebenen] Datensätze aufgelistet werden

Wenn Dein View aber so aufgebaut ist, dass alle entsprechenden Datensatzversionen enthalten sind, warum benötigst Du dann überhaupt eine Freigabe auf diesem View? Der Inhalt des Views sollte für Redakteure entweder nicht angezeigt werden oder er darf nur mit dem Recht "Lesen" angezeigt werden. Die Freigabe erfolgt dann über die anderen Tabellen und wird im View explizit angezeigt.

Nachdem ich das Ganze jetzt zum zweiten Mal geschrieben habe [Firefox Absturz], lasse ich die Lösung mit dem Zusammenführen zweier CONTENTLIST Ergebnisse diesmal weg, da ich vermute, dass der View einfach nicht korrekt konfiguriert ist

Viele Grüsse aus Dortmund,

  Holger

[dleinich · Accepted solution]

Hallo Holger,

vielen Dank erstmal für deine Antwort, die mir ausnahmsweise aber mal nicht weitergeholfen hat. Wie dem auch sei, ich konnte mein Problem gerade noch lösen.

Grundsätzlich brauche ich, wie von dir schon richtig festgestellt, keine eigenständige Freigabe auf den Fremschlüssel-Tabellen-Views. Da FirstSpirit aber auch die Verknüpfungstabellen anfassst, wenn etwas freigegeben wird, diese aber zwischen keywords und teaser nur ein View ist, flog bei mir eine Exception.

Vorher hatte ich also eine Struktur wie unten, wobei:

• teasers ein View auf den UNION von news und pressemitteilungen ist
• Die M:N Verknüpfung zwischen teasers und kategorien ein View auf den UNION der Verknüpfungstabellen von news bzw. pressemitteilungen mit kategorien ist

Meine Lösung ist nun, dass ich eine zweite Tabelle angelegt habe, die die Tabelle keywords nachbildet und in der Datenbank durch einen View auf die Tabelle keywords ersetzt wurde. So habe ich jetzt ein komplett unabhängiges System für die teaser und niemand will irgendwem in den View schreiben.

Jetzt sieht es also so aus, wobei:

• teasers ein View auf den UNION von news und pressemitteilungen ist
• kategorienView ein View auf die Tabelle kategorien ist
• Die M:N Verknüpfung zwischen teasers und kategorienView ein View auf den UNION der Verknüpfungstabellen von news bzw. pressemitteilungen mit kategorien ist

Klingt kompliziert, ist vermutlich auch so. Vielleicht habe ich ja wirklich noch einen Denkfehler drin aber so scheint es erstmal wunderbar zu funktionieren.

Das die Geschichte nicht Import/Export sicher ist, ist mir bewusst, aber danke noch mal für den Hinweis. Historische Generierungen sollten hingegen eigentlich schon funktionieren, da die Views ja auf alle verfügbaren Datensätze gehen, das muss ich aber noch mal prüfen. Wäre aber auch kein KO Kriterium.

Beste Grüße,

Daniel