Versionierte Tags? - Unclassified NewsBoard

Reply · Quote

Yves

(Administrator) 2007-11-28, 21:33 #1

User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members

Show profile ·

Link to this post

Subject: Versionierte Tags?

Ich stehe bei der Weiterentwicklung des UNB2-Designs momentan vor einer wegweisenden Entscheidung, bei der ich etwas Unterstützung gebrauchen könnte. Vielleicht kann sich der eine oder andere Interessierte die Beschreibung kurz durchlesen und mir mit ein paar Gedanken dazu weiterhelfen? Wäre nett.

Die Beschreibung befindet sich im Boardunity-Forum, Antworten sind dort wie hier möglich.

♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬

Reply · Quote

jense 2007-12-04, 19:18 #2

Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members

Show profile ·

Link to this post

Ich kann auf Anhieb nicht die exakte Definition finden: sind tags als Schlüsselwörter zum Inhalt oder als Art (Wiki, Blog, Forum, etc.) des Inhalts zu verstehen?

Alala, Alala, Gimme three wishes - CSS

Reply · Quote

Yves

(Administrator) 2007-12-05, 10:19 #3

User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members

Show profile ·

Link to this post

Tags sind Schlagwörter. Es besteht auch die Möglichkeit, dieser Zuordnung einen zusätzlichen Freitext zuzuordnen, sodass man das Tag eher als Attribut, Eigenschaft bezeichnen kann. (Biespiele: Datum des Ereignisses (für einen Kalender z.B.), Ort, betreffende Abteilung (falls nur eine möglich), ...)

Ob die Anwendung wie ein Wiki, Blog oder sonstwas aussieht, liegt an ihrer Programmierung und kann nicht vom Anwender beeinflusst werden. Das ist ja gerade der Punkt, dass das alles auf die selbe Datenstruktur zurückzuführen ist.

♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬

Reply · Quote

jense 2007-12-05, 21:05 #4

Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members

Show profile ·

Link to this post

Was hältst Du davon, alles - zumindest soweit es sinnvoll ist - zu versionieren, also die Versionsverwaltung zum Grundprinzip (oder Mutter aller Objekte) zu erklären?

Ich könnte mir das so vorstellen (zumindest ein Versuch einer Abstraktion):
Ein Beitrag ist grundsätzlich nur durch eine ID gekennzeichnet, ansonsten verweist er nur auf die Versionsverwaltungen von einzelnen Eigenschaften, die man einigermaßen sinnvoll zusammenfaßt. Denkbar wären z.B. die Bereiche Inhalt, Status, Zugriffskontrolle, Schlagwörter bzw 'Tags', Verknüpfungen mit anderen Beiträgen, usw. Vielleicht auch gröber oder feiner unterteilt.

Somit können die einzelnen Eigenschaftsfelder unabhängig voneinander geändert werden, um redundante Daten soweit wie möglich zu vermeiden. 'Versionierte' Zugriffskontrolle fände ich interessant, so daß z.B. Benutzer einen Beitrag sperren können, gegebenenfalls unter Aufsicht eines Moderators, indem einfach nur eine neue Revision der Zugriffskontrolle bereitgestellt wird.

Alala, Alala, Gimme three wishes - CSS

Reply · Quote

Yves

(Administrator) 2007-12-05, 23:13 #5

User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members

Show profile ·

Link to this post

Okay, ich glaub ich verstehe, was du meinst. Teile eines Beitrags sollen unabhängig voneinander versioniert werden. Aber erhöht das nicht doch auch die Code-Komplexität um ein ganzes Stück? Man müsste diese Informationen unterteilen, in mehrere Tabellen, um sie unabhängig zusammenfassen zu können. Dann entstehen viele Tabellen mit sehr wenigen Spalten. Und wie läuft dann die Suche ab? Dann müsste man für jeden zu betrachtenden Beitrag zwei oder drei Tabellen verknüpfen. Bei Suchen ausschließlich über Tags oder andere Metadaten (also keine indizierten Inhalte) wäre das jeder Beitrag.

♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬

Reply · Quote

jense 2007-12-06, 10:39 #6

Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members

Show profile ·

Link to this post

Quote by Yves:
Aber erhöht das nicht doch auch die Code-Komplexität um ein ganzes Stück?

Ich weiß nicht, wie gut PHP mit Objekten umgehen kann, aber grundsätzlich sind die Methoden für alle Datenstrukturen die Gleichen, wenn man das Ganze vernünftig abstrahiert.

Man müsste diese Informationen unterteilen, in mehrere Tabellen, um sie unabhängig zusammenfassen zu können. Dann entstehen viele Tabellen mit sehr wenigen Spalten.

Ok, unsere Herangehensweise ist wahrscheinlich völlig verschieden: Du hast immer gleich die Implementierung im Hinterkopf, während ich mich nur auf ein (sinnvolles?) Design konzentriere... Der Praktiker gewinnt dabei wahrscheinlich.

Vielleicht kannst Du mal darlegen, wo die technischen Probleme bei vielen Tabellen oder wenigen Spalten liegen.

Und wie läuft dann die Suche ab? Dann müsste man für jeden zu betrachtenden Beitrag zwei oder drei Tabellen verknüpfen. Bei Suchen ausschließlich über Tags oder andere Metadaten (also keine indizierten Inhalte) wäre das jeder Beitrag.

Hm, die Suchmöglichkeiten beschränkt sich doch auf wenige Felder und die blieben von einer erweiterten Versionsveraltungen unangetastet, weil sie sowieso schon versioniert waren - zumindest soweit ich das überblicke.

Nur um das klarzustellen: ich habe keine Ahnung von (My)SQL, bzw wie Daten dort abgelegt und verwaltet werden, deshalb sind meine Vorschläge vielleicht etwas naiv. Ich habe meine Stärke leider nur im Erkennen von Strukturen sowie deren Systematisierung und meine Unterstützung kann sich nur darauf beschränken. Aus diesem Grund habe ich überlegt, ob man eine Versionsverwaltung nicht als Basis für jede Datenstruktur verwenden kann. Da Du mit UNB2 viel vorhast, lohnt es sich vielleicht eine Traumspezifikation zu schreiben und dann, wenn man ein Gesamtbild hat (die Pflicht), zu überlegen, was man gegebenenfalls modifizieren muß, damit es 'optimal' läuft (die Kür, vor allem in Bezug auf die Performance).

Alala, Alala, Gimme three wishes - CSS

Reply · Quote

Yves

(Administrator) 2007-12-06, 10:57 #7

User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members

Show profile ·

Link to this post

Quote by jense:
Quote by Yves:
Aber erhöht das nicht doch auch die Code-Komplexität um ein ganzes Stück?

Ich weiß nicht, wie gut PHP mit Objekten umgehen kann, aber grundsätzlich sind die Methoden für alle Datenstrukturen die Gleichen, wenn man das Ganze vernünftig abstrahiert.

Momentan sind die einzelnen Klassen so implementiert, dass es eine Laden-Methode gibt, die eine Zeile aus der Datenbank liest und die Werte in Variablen des Objekts schreibt. Dann gibt es diverse Lesen- und Setzen-Methoden, die die Daten aus diesen Variablen lesen bzw. sie ändern und gleich in die Datenbank zurückschreiben. Die meisten Lesezugriffe beschränken sich dabei auf das Zurückgeben einer lokalen Variable. Wenn jetzt erst für jedes Teil eine Datenbankabfrage gemacht werden muss, in der die aktuelle Version gefunden wird, dauert es halt deutlich länger.

Vielleicht kannst Du mal darlegen, wo die technischen Probleme bei vielen Tabellen oder wenigen Spalten liegen.

Ich finde es primär erstmal nur seltsam.

Kann mir aber vorstellen, dass Datenbankabfragen langsamer werden, je mehr Tabellen miteinander verknüpft werden. Wie viele Spalten die Tabellen haben, ist dabei wahrscheinlich weniger relevant, da ja nicht alle für die Verknüpfung gelesen werden müssen. Außerdem werden so mehr Fremdschlüssel benötigt, um die einzelnen Datensätze miteinander zu verbinden, die Datenbank wird somit größer. (Das würde auch für hierarchische Datenbanken gelten, da auch hier Zeiger gespeichert werden. Ist also kein spezifisches Problem relationaler Datenbanken, hier wird die Abbildung nur komplexer.)

Hm, die Suchmöglichkeiten beschränkt sich doch auf wenige Felder und die blieben von einer erweiterten Versionsveraltungen unangetastet, weil sie sowieso schon versioniert waren - zumindest soweit ich das überblicke.

Ich wollte die Suche so umfassend wie möglich gestalten. Es soll nicht nur eine Suche nach dem Inhalt und Autor der Beiträge geben, sondern auch nach so ziemlich allen sichtbaren Metadaten, wie Datum, letzte Änderung, alle Tags (ggf. mit Textwerten), Betreff und ein paar der Flags. Außerdem muss man bei einer Suche berücksichtigen, dass nicht einzelne Versionen, sondern nur ganze Beiträge gefunden werden sollen. Während der Suche muss also jeder Beitrag aus seinen separat versionierten Bestandteilen zusammengesetzt werden, um die Kriterien zu prüfen. (Eine Suche über vergangene Inhalte könnte man später vorsehen, aber das wird gleich aufwändiger.)

Außerdem gibt es ja noch das Konzept der Moderation: Änderungen an Beiträgen müssen ggf. erst genehmigt werden, bevor sie öffentlich sichtbar werden. Dieser Vorgang sollte alle vom Benutzer eingegebenen Textinhalte abdecken, also jedes Feld, in dem der Benutzer potentiell eigene Inhalte veröffentlichen kann. Das sind der eigentliche Inhalt, der Betreff und die Tags mit Textwerten. Alles andere braucht IMO nicht unbedingt genehmigt zu werden. Die Zugriffsrechte soll sowieso nur der Autor und ein Administrator ändern können.

♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬

Reply · Quote

jense 2007-12-06, 11:17 #8

Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members

Show profile ·

Link to this post

Quote by Yves:
Wenn jetzt erst für jedes Teil eine Datenbankabfrage gemacht werden muss, in der die aktuelle Version gefunden wird, dauert es halt deutlich länger.

Da Du 'tags' versionieren wolltest, benötigt man sowieso zwei Datenbankabfragen, oder? - Abgesehen von dem eigentlichen Inhalt, ist die Datenmenge doch relativ überschaubar. Ist es realisierbar, daß man alle Versionen auf einen Rutsch einliest? Vielleicht ist das sogar sinnvoll, damit man einen Überblick über die zur Verfügung stehenden Versionen im Frontend geben kann...

Alala, Alala, Gimme three wishes - CSS

Reply · Quote

Yves

(Administrator) 2007-12-06, 15:58 #9

User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members

Show profile ·

Link to this post

Momentan ist es so implementiert: Der Beitrag wird gelesen. Dann werden die Tags gelesen und auch die letzte verfügbare Version mit Inhalt. Der Beitrag selbst kommt aus einer Suchabfrage, z.B. der Auflistung aller Beiträge sortiert nach dem Datum. Je nachdem, ob man den jetzt anzeigen will, kann man die zusätzlichen Angaben abrufen. Alles auf einmal geht nicht, und bei Tags erst recht nicht, da dabei ja mehrere Zeilen rauskommen, wo der Beitrag in einer einzigen Zeile steht. So gesehen bedarf es allerdings keiner zusätzlichen Abfrage, versionierte Tags abzurufen, da hab ich mich verschätzt. Eine weitere Tabelle muss der Datenbankserver aber freilich anfassen.

So wie ich mir das vorgestellt hätte, würden die Tags mitsamt dem Rest des Beitrags (Autor, Betreff, Inhalt) in einem Stück abgespeichert. Wenn man die Tags ändert (und dafür eine neue Version anlegen will - dazu gleich mehr), werden auch der Inhalt und der Rest in eine neue Version kopiert.

Wozu könnte es nützlich sein, alle Versionen zu verarbeiten, wenn man nur die letzte anzeigen will? Wenn die Versionsnummer > 1 ist, wurde der Beitrag irgendwann mal verändert. Das bekommt man ohne weiteren Aufwand raus. Was könnte man noch wissen wollen?

Zur Verwendung neuer Versionen: Ich hab mir letztens eine Optimierung des ganzen überlegt. Eine neue Version eines längeren Beitrags anzulegen, nur weil ein Tag hinzugefügt wurde, kann u.U. unerwünscht sein. Ebenfalls kann es evtl. nicht erforderlich sein, alles exakt zu versionieren. Daher könnte man das Anlegen einer neuen Version im API explizit vorsehen, wohingegen sich alle anderen Änderungen immer auf die letzte verfügbare Version auswirken. So kann man für immer die erste Version bearbeiten und braucht keinen weiteren Speicherplatz, oder man kann vor jeder Gruppe von Änderungen zunächst eine neue Version anlegen und diese Bearbeiten. Das ermöglicht der Anwendung (und ggf. auch dem Administrator) selbst zu entscheiden, was passieren soll.

♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬

Reply · Quote

jense 2007-12-06, 16:25 #10

Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members

Show profile ·

Link to this post

Hm, im Prinzip lassen sich doch alle Performance-Probleme mit etwas Redundanz in den Daten lösen, oder? D.h. von allem, was schnell auffindbar sein soll, führt man zentral eine aktuelle Version mit. Damit kann alles mit Versionskontrollen versehen werden, wo es für sinnvoll erachtet werden kann, und man hat die Möglichkeit zur Revision ohne die Vorteile einer flachen Struktur zu verlieren. Gegebenenfalls kann man die ganzen Versionierungs erst mit einer Änderung einsetzen lassen, um unnötige Dopplungen zu vermeiden.

Wie auch immer. Ich halte das für Implementierungsdetails, die in der grundlegenden Konzeption noch nicht überhand gewinnen sollten...

Alala, Alala, Gimme three wishes - CSS

Reply · Quote

Yves

(Administrator) 2007-12-15, 17:05 #11

User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members

Show profile ·

Link to this post

Subject: Neues Problem, an das ich noch nicht gedacht habe

Ich hab mich die letzten Tage mal drangemacht, und eine Änderung des Codes in Richtung versionierter Tags begonnen. Dabei gab es keine großartigen Probleme - bis auf eins: Es besteht die Möglichkeit, durch die Zuordnung von Tags die Zugriffsrechte auf eine Mitteilung einzuschränken.

Mit bestimmten Tags versehene Mitteilungen dürfen z.B. nur von bestimmten Benutzern gelesen oder verändert werden. Diese Rechte wirken sich aber immer nur auf ganze Mitteilungen aus, nie auf einzelne Revisionen (was ja auch irgendwie unsinnig wäre). Lassen sich die Tags nun versionieren, weiß man aber nicht so recht, welche Version für die Zugriffsrechte hergenommen werden soll. Ist es die letzte gespeicherte? Die allererste? Oder die neueste öffentlich verfügbare (= genehmigte)? Manche Benutzer (z.B. der Autor/Eigentümer und Moderatoren) können aber auch noch nicht genehmigte Versionen sehen und würden sich vielleicht über Inkonsistenzen der Zugriffsrechte wundern.

Im Vergleich zu den zuvor bekannten Schwächen ist das jetzt ein ernsthaftes Problem, das nicht nur zu weniger Effizienz führt, sondern zu undefinierten Zuständen. Lösungsansätze sind gerne willkommen!

Vielleicht sollte man Tags doch nicht versionieren und Änderungen immer sofort anwenden. Ob eine unabhängige Versionierung der Tags hier Abhilfe schafft, darüber hab ich mir noch keine ausführlichen Gedanken gemacht.

♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬