Not logged in. · Lost password · Register
Forum: UNB Components (a.k.a. UNB2) RSS
Datenstrukturen
Page:  1  2  next ›
Reply · Quote jense 2007-12-06, 16:36 #1
Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members
Show profile · Link to this post
Subject: Datenstrukturen
Ich habe mal die Seite Zugangssteuerung und Moderation quer gelesen.  Ist die Struktur, die unten angeben ist, der derzeitige Stand?

Hier ein paar schnelle Punkte, die mir bisher beim ersten Punkt 'Mitteilungen' aufgefallen sind
  • ist der Initiator wirklich wichtig?  Das hat eigentlich nur historischen Belang, denn schließlich können sich Inhaltsautoren oder auch -verantwortliche im Laufe der Zeit ändern.
  • was unterscheidet den Seitenname vom Titel (Mitteilungs-Revision)?
  • die einzelnen Berechtigungsschlüssel lassen Verallgemeinerungen schwierig erscheinen.  Was ist, wenn man neue Bearbeitungsmethoden hinzufügt?
  • Zeitpunkt, zu dem [...]: sollte so etwas nicht über Mitteilungs-Revisionen verwaltet werden?
Alala, Alala, Gimme three wishes - CSS
Avatar
Reply · Quote Yves (Administrator) 2007-12-06, 17:09 #2
User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Ja, das müsste soweit aktuell sein.

Der ursprüngliche Autor einer Mitteilung soll meinen Gedanken nach auch geändert werden können. Eigentlich ist es mehr ein "Eigentümer" der Mitteilung. Dieser hat, neben Administratoren, die Berechtigung, die Zugriffslisten für die Mitteilung zu verändern. Wer eine bestimmte Revision geschrieben hat, steht dort dabei, und das soll auch nicht nachträglich änderbar sein.

Der Seitenname ist eine Kurzbezeichnung, die in Wikis verwendet wird. Das sollten nur ein bis wenige Wörter sein, die in der URL verwendet werden können. Diese Angabe wird nicht versioniert, da die Versionen ja dieser Seite untergeordnet sein sollen. (Änderungen des Seitennamens sind so natürlich nicht nachvollziehbar.) Der Betreff ist eher für klassische Foren-Beiträge gedacht, und nicht für Informationsseiten. Der Betreff kann z.B. für eine Liste von Beiträgen verwendet werden, wie sie in Listen in Baumstruktur angezeigt werden (z.B. Heise-Forum).

An welche neuen Bearbeitungsmethoden denkst du so?

Der Zeitpunkt des letzten Bearbeitungsbeginns soll dann gesetzt werden, wenn irgendjemand anfängt, die Mitteilung zu bearbeiten. Ich denke, es sollte ausreichen, immer die letzte Version bearbeiten zu können oder frühere Versionen unverändert wiederherzustellen. Der Bearbeiter hat dann z.B. 10 Minuten Zeit, ein "Lebenszeichen" zu senden, z.B. ein Draft-Postback während der Bearbeitung oder eine Vorschau des Textes. Während dieser Zeit (spätestens bis das Bearbeiten explizit beendet wurde) sollen andere Benutzer, die das gleiche vorhaben, eine Warnung angezeigt bekommen, dass sie möglicherweise einen Änderungskonflikt auslösen werden. Ich sehe da keinen Bezug zu einer bestimmten Revision.
♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬
Reply · Quote jense 2007-12-06, 17:45 #3
Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members
Show profile · Link to this post
Quote by Yves:
An welche neuen Bearbeitungsmethoden denkst du so?
Ich habe nicht weiter darüber nachgedacht.  Mir ist nur aufgefallen, daß diese Rechteverteilung schon extrem dediziert ist: man kann den Inhalt nur lesen, bearbeiten und beantworten.  Ich hätte erwartet, daß man bei einem Neudesign sich noch Optionen offenläßt...
Alala, Alala, Gimme three wishes - CSS
Avatar
Reply · Quote Yves (Administrator) 2007-12-06, 21:13 #4
User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Ja, die Rechteverwaltung ist in dieser Form deutlich einfacher gestrickt als die ACLs im UNB 1. Aber es besteht ja immer noch die Möglichkeit, eine zusätzliche ACL-Tabelle anzulegen und weitere Zugriffsregelungen darin abzulegen. Die haben dann aber zunächst keinen Einfluss darauf, wie die Basisklassen in ihrer Grundfunktionalität arbeiten. Wenn man zusätzliche Regeln abspeichern will, dann werden die sie wohl eher auf Code auswirken, der außerhalb der Basisklassen, also in der Anwendung liegt. Die ist vom bisherigen Entwurf aber noch gar nicht erfasst. Und sollte man tatsächlich die Funktion der Basisklassen beeinflussen wollen, dann lässt sich das ja auch ändern.

Wie du schon merkst, im bisherigen Konzept werden nur die innersten Innereien ("the very core") berücksichtigt. Demnach richten sich diese Klassen auch mehr an Entwickler als an Anwender. Die Klassen stellen dann die Basis für weitere Anwendungen bereit. Dabei kann natürlich zusätzliche Funktionalität hinzukommen. Ich habe z.B. vor, diese Basisklassen zunächst in meinem Web-Labor einzusetzen, um dort einfache Forenfunktionen und ein kleines Weblog einzubauen. Außerdem will ich sie für mein geplantes Fotoalbum verwenden, um die Bilder und Kommentare darauf zu verwalten, sowie auch die Suchfunktion. (Hier sind insbesondere die Metadaten, z.B. EXIF, gefragt.) Das sind also gleich recht breit gefächerte Einsatzgebiete, in denen ich Erfahrungen im Umgang damit sammeln und ggf. Änderungen vornehmen kann, um später ein "fertiges", eigenständiges Webforum daraus zu machen.
♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬
Reply · Quote jense 2007-12-07, 13:36 #5
Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members
Show profile · Link to this post
Quote by Yves:
Ja, die Rechteverwaltung ist in dieser Form deutlich einfacher gestrickt als die ACLs im UNB 1. Aber es besteht ja immer noch die Möglichkeit, eine zusätzliche ACL-Tabelle anzulegen und weitere Zugriffsregelungen darin abzulegen. [...]
Ich meine, daß man zumindest derartige Erweiterung in den Datenstrukturen schon verankern soll, auch wenn sie derzeit nicht genutzt werden.  So ersparst Du Dir vielleicht auch ein UNB3 mit wieder einer komplett neuen Struktur... :-)
Alala, Alala, Gimme three wishes - CSS
Reply · Quote jense 2007-12-07, 13:47 #6
Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members
Show profile · Link to this post
In reply to post #2
Quote by Yves:
Der ursprüngliche Autor einer Mitteilung soll meinen Gedanken nach auch geändert werden können. Eigentlich ist es mehr ein "Eigentümer" der Mitteilung. Dieser hat, neben Administratoren, die Berechtigung, die Zugriffslisten für die Mitteilung zu verändern.
Sieht eher nach einer Zugriffsberechtigung aus und sollte entsprechend verwaltet werden.

Der Seitenname ist eine Kurzbezeichnung, die in Wikis verwendet wird. Das sollten nur ein bis wenige Wörter sein, die in der URL verwendet werden können.
Ließe sich so etwas nicht (einfacher/besser?) über 'Tags' verwalten.  So können z.B. mehrere Mitteilungen auf einer Seite stehen oder Seiten einer Mitteilung zugeordnet werden.

Der Zeitpunkt des letzten Bearbeitungsbeginns soll dann gesetzt werden, wenn irgendjemand anfängt, die Mitteilung zu bearbeiten. Ich denke, es sollte ausreichen, immer die letzte Version bearbeiten zu können oder frühere Versionen unverändert wiederherzustellen.
Mir ist aufgefallen, daß die Beschränkung auf eine neue Revision in manchen Fällen nicht notwendig ist.  Bei versionierten Tags z..B.  spricht nichts dagegen, daß mehrere Vorschläge für neue Tags angenommen werden.  Genauso könnte man mehrere Bearbeitungen einer Mitteilung zulassen: wenn sich die Änderungen auf verschiedene Teile beschränken, könnten sie nacheinander eingegliedert werden...
Alala, Alala, Gimme three wishes - CSS
Avatar
Reply · Quote Yves (Administrator) 2007-12-07, 14:22 #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:
Der ursprüngliche Autor einer Mitteilung soll meinen Gedanken nach auch geändert werden können. Eigentlich ist es mehr ein "Eigentümer" der Mitteilung. Dieser hat, neben Administratoren, die Berechtigung, die Zugriffslisten für die Mitteilung zu verändern.
Sieht eher nach einer Zugriffsberechtigung aus und sollte entsprechend verwaltet werden.

Das Feld sollte wohl besser "Owner" heißen. Das spiegelt die beabsichtigte Verwendung besser wider.

Der Seitenname ist eine Kurzbezeichnung, die in Wikis verwendet wird. Das sollten nur ein bis wenige Wörter sein, die in der URL verwendet werden können.
Ließe sich so etwas nicht (einfacher/besser?) über 'Tags' verwalten.  So können z.B. mehrere Mitteilungen auf einer Seite stehen oder Seiten einer Mitteilung zugeordnet werden.

Für jede Seite, die per URL erreichbar sein soll, ein eigenes Tag? Stell dir das mal für die Wikipedia vor... Tags kann man freilich auch nutzen, um mehrere Mitteilungen anzuzeigen, genauso wie Kategorien in Weblogs. Aber es soll auch Anlässe geben, zu denen einzelne Seiten einzeln angezeigt werden sollen. Tutorials oder Hintergrundartikel, zusätzlich zu einem regulären Forenbetrieb, kann ich mir gut dafür vorstellen.

Mir ist aufgefallen, daß die Beschränkung auf eine neue Revision in manchen Fällen nicht notwendig ist.  Bei versionierten Tags z..B.  spricht nichts dagegen, daß mehrere Vorschläge für neue Tags angenommen werden.  Genauso könnte man mehrere Bearbeitungen einer Mitteilung zulassen: wenn sich die Änderungen auf verschiedene Teile beschränken, könnten sie nacheinander eingegliedert werden...

Oh, ja, dann wird's aber haarig. Ich weiß nicht, ob ich das vorsehen soll. Und letztlich soll diese Zeitangabe nur eine Warnung sein. Das Bearbeiten und Abschicken von Inhalten wird deshalb nicht gesperrt. Eine Kollision ist immer noch möglich und kann ggf. mit weiteren Techniken behandelt werden.

Dieser Zeitstempel soll gesetzt werden, wenn jemand anfängt, eine Mitteilung zu bearbeiten. Der Zweck ist, Kollisionen beim eigentlichen Inhalt (allgemein: allen nicht automatisch synchronisierbaren Daten, z.B. auch der Betreff) zu vermeiden. Wenn es die Benutzerführung der Programmoberfläche zulässt, zwischen dem Bearbeiten von Tags und Text zu unterscheiden, braucht man in manchem Fall diesen Zeitstempel ja nicht zu setzen, was auch nicht zu einer Warnmeldung führt.
♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬
Reply · Quote jense 2007-12-07, 14:40 #8
Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members
Show profile · Link to this post
Quote by Yves:
Quote by jense:
Quote by Yves:
Der ursprüngliche Autor einer Mitteilung soll meinen Gedanken nach auch geändert werden können. Eigentlich ist es mehr ein "Eigentümer" der Mitteilung. Dieser hat, neben Administratoren, die Berechtigung, die Zugriffslisten für die Mitteilung zu verändern.
Sieht eher nach einer Zugriffsberechtigung aus und sollte entsprechend verwaltet werden.
Das Feld sollte wohl besser "Owner" heißen. Das spiegelt die beabsichtigte Verwendung besser wider.
Hm, meine Fremdsprachenkenntnisse reichen nicht aus, um den subtilen Unterschied zwischen 'Eigentümer' und 'Owner' zu erkennen... ;-)

Für jede Seite, die per URL erreichbar sein soll, ein eigenes Tag? Stell dir das mal für die Wikipedia vor...
Ach ja, Du wolltest viele Attribute bei wenigen Tabellen und ich denke noch zu sehr hierarchisch... - Es gibt für alles 'worst-case'-Szenarios.  Genauso gut könnte ich argumentieren, daß viele Mitteilungen hinter einem URI, zuviel Redundanz erzeugt (beschreibende URIs sind generell eine Überlegung Wert).
Alala, Alala, Gimme three wishes - CSS
Reply · Quote jense 2007-12-07, 14:47 #9
Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members
Show profile · Link to this post
Deine Benutzer-VCard ist doch nur eine bestimmte Form einer Mitteilung mit Zugriffsrechten, Verknüpfungen ('Freunde', ...) und vielleicht auch 'tags'.  Somit eine unnötige Relation?

Off Topic:
[Aber nur ein wenig] Wie gut funktioniert das Speichern von Listen mit variabler Länge und das Suchen von deren Elementen in MySQL? Muß man zwingend immer eine maximale Länge angeben?
Alala, Alala, Gimme three wishes - CSS
Avatar
Reply · Quote Yves (Administrator) 2007-12-07, 18:18 #10
User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members
Show profile · Link to this post
In reply to post #8
Quote by jense:
Hm, meine Fremdsprachenkenntnisse reichen nicht aus, um den subtilen Unterschied zwischen 'Eigentümer' und 'Owner' zu erkennen... ;-)

Momentan heißt das Feld doch "Author" (dt. Autor). Und ich würde es jetzt in "Owner" (dt. Eigentümer) umbenennen.

Quote by jense:
Deine Benutzer-VCard ist doch nur eine bestimmte Form einer Mitteilung mit Zugriffsrechten, Verknüpfungen ('Freunde', ...) und vielleicht auch 'tags'.  Somit eine unnötige Relation?

Ähm, eine VCard ist eine Art Schlüssel-Werte-Paar-Liste, die eben noch eine bestimmte, ganz einfach gehaltene Sichtbarkeit definiert. Mehr nicht. Keine Verknüpfungen und keine Klassifizierung. Das kann jeder Benutzer problemlos ausfüllen. Ein Beitrag besteht aus mehreren Textinhalten, der Möglichkeit, Referenzen und Tags sowie umfangreiche Zugriffsberechtigungen zu vergeben. (Die einfachen Sichtbarkeitswerte sind damit nur umständlich realisierbar.) Ich halte das schon für zwei ausreichend unterschiedliche Dinge.

Off Topic:
[Aber nur ein wenig] Wie gut funktioniert das Speichern von Listen mit variabler Länge und das Suchen von deren Elementen in MySQL? Muß man zwingend immer eine maximale Länge angeben?

Ich kenne mich damit nicht aus und bin mir nichtmal sicher, wie gut das überhaupt unterstützt wird. Mehrwertige Attribute werden im allerersten Schritt der Datenbank-Normalisierung (1. NF (Normalform), derer es glaub ich 3 bis 3,5 gibt) behandelt...
♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬
Reply · Quote jense 2007-12-07, 18:37 #11
Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members
Show profile · Link to this post
Quote by Yves:
Ähm, eine VCard ist eine Art Schlüssel-Werte-Paar-Liste, die eben noch eine bestimmte, ganz einfach gehaltene Sichtbarkeit definiert. Mehr nicht. Keine Verknüpfungen und keine Klassifizierung. Das kann jeder Benutzer problemlos ausfüllen. Ein Beitrag besteht aus mehreren Textinhalten, der Möglichkeit, Referenzen und Tags sowie umfangreiche Zugriffsberechtigungen zu vergeben. (Die einfachen Sichtbarkeitswerte sind damit nur umständlich realisierbar.) Ich halte das schon für zwei ausreichend unterschiedliche Dinge.
In Zeiten von StudiVZ, myspace, xine, etc. sind Benutzerinformationen schon sehr variantenreich geworden.  Ein Feld dessen Abdeckung eine Erwägung wert sein könnte.  Ein weiterer Vorteil ist, daß die darin gespeicherten Informationen auf den gleichen Niveau durchsucht werden können wie alles andere.
Alala, Alala, Gimme three wishes - CSS
Avatar
Reply · Quote Yves (Administrator) 2007-12-07, 20:42 #12
User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Mein Problem ist vermutlich, dass ich mich diesen Datenschleudern sozialen Netzwerken bislang noch nicht angeschlossen habe und sie daher nicht von innen kenne. Obwohl... beim nächsten "Tag der offenen Tür" vielleicht... mal ein Blick durch die halboffene Tür... ;)
♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬
Reply · Quote jense 2007-12-09, 15:24 #13
Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members
Show profile · Link to this post
Quote by Yves on 2007-12-07, 20:42:
Mein Problem ist vermutlich, dass ich mich diesen Datenschleudern sozialen Netzwerken bislang noch nicht angeschlossen habe [...]
Dito. - Streng genommen ist alles, was Du mit UNB2 abdecken willst, eine Datenschleuder, also warum nicht die Dose der Pandora vollständig öffnen?! :->
Alala, Alala, Gimme three wishes - CSS
Reply · Quote jense 2007-12-14, 15:12 #14
Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members
Show profile · Link to this post
Wahrscheinlich hast Du darauf eine schnelle Antwort: wie einfach ist es in MySQL 'strings' mit variabler Länge als Attribut in einer Relation abzulegen.  Der Grund für diese Frage ist, daß die Relationen für zugewiesene Tags und weitere Referenzen vermutlich einer MitteilungsID nur TagIDs und weitere MitteilungIDs zuordnen, oder?  Damit könnte man sie doch auch in Textform in der Mitteilungsdatenstruktur speichern und sich die zusätzlichen Relationen sparen?  Der Zeitverlust durch die Textumwandlung sollte vernachlässigbar sein und das Suchen sogar einfacher werden...
Alala, Alala, Gimme three wishes - CSS
Avatar
Reply · Quote Yves (Administrator) 2007-12-14, 18:30 #15
User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Ich verstehe nicht, was du meinst. Willst du alle Referenzen in einer Zeichenkette ablegen und sie durch Anwendungscode verarbeiten lassen, anstatt durch das Datenbanksystem? Halte ich für unsauber und anfragetechnisch grausam weil endlos umständlich.

Übrigens, Datenschleuder = Nutzerdaten leaken oder verkaufen. (Heute hat StudiVZ ja wieder mal Schlagzeilen gemacht...) Sowas will und werde ich nicht unterstützen oder selbst verfolgen. Was der Betreiber einer UNB(2)-basierten Plattform tut, liegt außer meiner Macht.
♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please note the verification code from the picture into the text field next to it.
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Page:  1  2  next ›

Go to forum
This board is powered by the Unclassified NewsBoard software, 20100516-dev, © 2003-10 by Yves Goergen
Page created in 456 ms (412 ms) · 131 database queries in 264 ms
Current time: 2010-07-30, 10:52:08 (UTC +02:00)