Geeignete Datenbank für hierarchive Metadaten [war: Frage bei SQLite-Check-Statement]

  • Hi,


    ich habe folgende Tabelle:


    SQL
    CREATE TABLE object
            (
              objectID   TEXT    PRIMARY KEY,
              parentID   TEXT    NOT NULL CHECK (),
              title      TEXT    NOT NULL,
              class      TEXT    NOT NULL,
              restricted INTEGER
            )


    Wie ihr sehen könnt, fehlt mir noch das Check-Statement. Dort soll geprüft werden, ob die ParentID in der Tabelle als ObjectID schon existiert. Ich bin mir nicht sicher, ob ich gleiches auch über ForeignKey-Constraints erreiche. Die ParentID darf in einem einzigen Fall nicht existieren, dann muss aber ObjectID = "0" und die ParentID "-1" sein. Das würde ich gerne irgendwie in der Tabelle mit Constraints abbilden. Kann mir jemand erklären, wie ich das hinbekomme?


    Medion Digitainer; AsRock B75 Pro3-M, Celeron G540; Kingston Value 4GB
    Samsung SpinPoint 250GB 2,5"; Samsung WriteMaster DVD-Brenner;
    TT-S2-6400, 2x TT-S2-1600, Ubuntu 12.04 mit YaVDR-Paketen. VDR 1.7.27, UPnP/DLNA-Plugin

    Einmal editiert, zuletzt von methodus ()

  • Und wieder Bäume in "flachen" Tabellen -- also wenn du es "richtig" (semantisch) machen willst, suche dir ein freies DBMS, das entweder objektorientiert oder hierarchisch arbeitet -- NICHT relational. Sowas soll es geben ;) Weiß aber gerade keines, gerade bei objektorientierten DBMS hängt es ja auch sehr von der verwendeten Programmiersprache ab.


    Andererseits ist SQLite ganz sicher der "pragmatische" Ansatz, man kann einfach und effizient Daten speichern. Keine Ahnung, ob das, was du hier vorhast, mit SQLite /überhaupt/ machbar ist, aber ich sag mal folgendes: Du machst in deinem CREATE TABLE allerdings eh schon Zugeständnisse an SQLite, indem du auf Datentypen verzichtest. Wieso dann Constraints? Ich denke dafür ist SQLite nicht gebaut worden. Ich würde zu "Dokumentationszwecken" einen foreign key setzen, für parentID NULL erlauben und in der Software sicherstellen, dass es nur einen einzigen Eintrag mit NULL in parentID gibt.

    Asrock A75 Pro4-M
    Debian wheezy (testing, stock) (aktuell 2012-08-24: Linux 3.2, VDR 1.7.28)
    vdr-sxfe (xineliboutput)
    Pioneer VSX-520-K

  • Tja letztlich kann ich keine fetten DBMS einsetzen, das wäre ein absoluter overkill. Die Wahl auf SQLite ist deswegen gefallen, weil es leichtgewichtig und ausreichend performant um eine gewisse Anzahl an Datensätzen zu verarbeiten. Auf die Datentypen kann ich getrost verzichten, da meine gespeicherten Meta-Informationen in der Regel Text sind.


    Da SQLite die Möglichkeit der Constraints mitbringt, würde ich sie auch gerne dort abbilden, weil die Abbildung im Code zwar grundsätzlich nicht doof ist, aber wenn ich schon die Integrität der Daten wahren kann, dann sollte ich es auch in einem gewissen Maß tun. Und da dieses Feld eines der wenigen Pflichtfelder ist, sollte es auch möglich sein. Den Rest kann ich über Validatoren beim Auslesen abfangen.


    Medion Digitainer; AsRock B75 Pro3-M, Celeron G540; Kingston Value 4GB
    Samsung SpinPoint 250GB 2,5"; Samsung WriteMaster DVD-Brenner;
    TT-S2-6400, 2x TT-S2-1600, Ubuntu 12.04 mit YaVDR-Paketen. VDR 1.7.27, UPnP/DLNA-Plugin

  • Zitat

    Tja letztlich kann ich keine fetten DBMS einsetzen

    "will" wäre an dieser Stelle sicher adäquater/ehrlicher gewesen ;)


    Zitat

    ... aber wenn ich schon die Integrität der Daten wahren kann,

    Hm, es ist ein Mistglaube, zu denken, dass konsistente Daten nur mit Constraints möglich wären. Dem ist beileibe nicht so.
    Constraints sind - überspitzt formuliert - nur für faule Programmierer erfunden worden.
    Insbesondere in großen Firmen, wo ein Datenbank-Administrator für alle Schema-Fragen zuständig ist, wird so die Verantwortung verlagert.
    Der Administrator ist dort für die Qualität der Daten zuständig, während der Programmierer nur noch mit dem Fehler klar kommen muss, wenn ein Constraint ihm auf die Finger klopft.


    Mit etwas Nachdenken lassen sich auch konsistente Daten pflegen ohne den Einsatz von Constraints :)


    Zitat

    Den Rest kann ich über Validatoren beim Auslesen abfangen.

    Das solltest Du Dir nochmal überlegen.
    Insbesondere bei DLNA - mit dem Du Dich ja zu beschäftigen scheinst - gibt es einen enormen Protokoll-Overkill, d.h. das ist eh schon langsam.
    Üblicherweise validiert man beim Schreiben - das ist von Haus aus eine teure Operation, also kommt es auf ein paar Millisekunden mehr oder weniger nicht an. Fast jeder Anwender weiß, dass schreiben langsamer ist, als lesen. Deshalb kann dort auch eher Geduld erwartet werden.


    Beim Lesen sollte man dagegen davon ausgehen, dass die Daten in Ordnung sind und so wenig wie möglich an den Daten rumpfuschen. Nur dann kann man auch größere Listen in akzeptabler Zeit verarbeiten.


    Gruß Gero

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

  • Wenn du dir das hier anschaust verstehst du vielleicht, warum ich vorgeschlagen habe, es lieber zu lassen:


    http://www.sqlite.org/foreignkeys.html


    Selbst in einem großen DBMS würde ich nicht versuchen, eine Baumstruktur durch Constraints zu erzwingen, einfach weil es in meinen Augen eh ein Kompromiss ist, einen Baum in Tabellen zu speichern. Bei SQLite sind Constraints -- zumindest so wie ich die Dokumentation lese -- ein etwas stiefmütterliches "der-Vollständigkeit-halber-Feature"; ausgelegt ist SQLite darauf, schnell, einfach und effizient Daten zu speichern und dabei "irgendwie" zu SQL kompatibel zu sein.


    That said, was du willst MÜSSTE (ohne es jetzt zu testen) ungefähr so funktionieren:


    CHECK ((objectID=0 AND parentID=-1) OR EXISTS(SELECT 1 FROM object o WHERE o.objectID = parentID))


    Ob SQLite das korrekt auswerten kann weiß ich aber nun wirklich nicht...

    Asrock A75 Pro4-M
    Debian wheezy (testing, stock) (aktuell 2012-08-24: Linux 3.2, VDR 1.7.28)
    vdr-sxfe (xineliboutput)
    Pioneer VSX-520-K

  • Zitat
    Den Rest kann ich über Validatoren beim Auslesen abfangen.


    Das solltest Du Dir nochmal überlegen.
    Insbesondere bei DLNA - mit dem Du Dich ja zu beschäftigen scheinst - gibt es einen enormen Protokoll-Overkill, d.h. das ist eh schon langsam.
    Üblicherweise validiert man beim Schreiben - das ist von Haus aus eine teure Operation, also kommt es auf ein paar Millisekunden mehr oder weniger nicht an. Fast jeder Anwender weiß, dass schreiben langsamer ist, als lesen. Deshalb kann dort auch eher Geduld erwartet werden.


    Beim Lesen sollte man dagegen davon ausgehen, dass die Daten in Ordnung sind und so wenig wie möglich an den Daten rumpfuschen. Nur dann kann man auch größere Listen in akzeptabler Zeit verarbeiten.


    Prinzipiell ja, die Validierung der Daten erfolgt grundsätzlich beim Schreiben, aber in reduzierter Form auch beim Lesen. Dort aber nur auf Grundlage der Datentypen. Was nicht "passt" wird ignoriert.


    Zu der Baum-Struktur: Auch richtig, das nicht in die DB zu pressen. Wenn jemand eine einfachere aber trotzdem leichtgewichtige Lösung kennt, wie ich über Query-Statements alá SQL Metadaten speichern und lesen kann, dann immer her damit. Das Dateisystem ist als Speicherort leider nicht geeignet, da ich die Metadaten dort wieder in Dateien speichern müsste, was auch nicht performant ist.


    Aber das Check-Constraint dürfte passen. Ich prüf das mal.


    Medion Digitainer; AsRock B75 Pro3-M, Celeron G540; Kingston Value 4GB
    Samsung SpinPoint 250GB 2,5"; Samsung WriteMaster DVD-Brenner;
    TT-S2-6400, 2x TT-S2-1600, Ubuntu 12.04 mit YaVDR-Paketen. VDR 1.7.27, UPnP/DLNA-Plugin

  • Um das vielleicht nochmal zu forcieren:


    Ich suche WIRKLICH eine einfache Alternative zu SQLite. Sie muss aber auf jedenfall Abfragen zulassen, mit der man über die gesamte Hierarchie Einträge suchen kann. XML-Basierte DBs sind auch denkbar, wobei ich mich hier erst überzeugen lassen muss, dass die Lesevorgänge effizient genug sind, um mehrere Hunderte von Einträgen zu durchsuchen.


    Medion Digitainer; AsRock B75 Pro3-M, Celeron G540; Kingston Value 4GB
    Samsung SpinPoint 250GB 2,5"; Samsung WriteMaster DVD-Brenner;
    TT-S2-6400, 2x TT-S2-1600, Ubuntu 12.04 mit YaVDR-Paketen. VDR 1.7.27, UPnP/DLNA-Plugin

  • Zu der Baum-Struktur: Auch richtig, das nicht in die DB zu pressen. Wenn jemand eine einfachere aber trotzdem leichtgewichtige Lösung kennt, wie ich über Query-Statements alá SQL Metadaten speichern und lesen kann, dann immer her damit. Das Dateisystem ist als Speicherort leider nicht geeignet, da ich die Metadaten dort wieder in Dateien speichern müsste, was auch nicht performant ist.


    Deshalb hatte ich ja gemeint -- in SQLite speichern wäre schon auch mein Ansatz, eben weil es leichtgewichtig und effizient ist. Ich würde nur hier auf Constraints verzichten und lieber eine Schicht dazwischen einziehen, die zwischen Objekten im Speicher und SQLite "mappt" und dafür sorgt, dass der Baum intakt ist. Das ist zwar nicht unbedingt performanter (verschiedene Quellen schlagen vor, Logik IN die Datenbank zu bringen für mehr Performance, das hängt aber davon ab, wie du SQLite ansprichst -- "native" mit C/C++ sollte das irrelevant sein) -- aber sicherer! Ansonsten könnte deine Software einmal versehentlich mit einer SQLite lib laufen, die MIT foreign keys, aber OHNE trigger compiliert ist -- Effekt: Die Constraints werden akzeptiert, aber nie wirklich überprüft.


    Es gibt wahrscheinlich auch diverse NoSQL Möglichkeiten, die z.B. direkt einen Objektgraphen speichern können. Ob man da aber was leichtgewichtiges findet, was sich einfach dazulinken lässt -- fängt ja schon mit der verwendeten Programmiersprache an, zu der es passen muss.

    Asrock A75 Pro4-M
    Debian wheezy (testing, stock) (aktuell 2012-08-24: Linux 3.2, VDR 1.7.28)
    vdr-sxfe (xineliboutput)
    Pioneer VSX-520-K

  • Ich habe mir mal das Prinzip einer XML-basierten DB angesehen. Sinnvoll hier wäre auf jeden fall, dass man mittels XSLT die Daten einfach transformieren kann. Ggf. werden die Items schon im Vorfeld in der Struktur gespeichert, wie sie später verwendet werden soll, dann muss gar nicht mehr transformiert werden.


    Aber wie sieht es dort mit CRUD aus? Wie bekommt man das performant hin und welche Bibliotheken sind hier notwendig?


    Medion Digitainer; AsRock B75 Pro3-M, Celeron G540; Kingston Value 4GB
    Samsung SpinPoint 250GB 2,5"; Samsung WriteMaster DVD-Brenner;
    TT-S2-6400, 2x TT-S2-1600, Ubuntu 12.04 mit YaVDR-Paketen. VDR 1.7.27, UPnP/DLNA-Plugin

  • Aber wie sieht es dort mit CRUD aus? Wie bekommt man das performant hin und welche Bibliotheken sind hier notwendig?


    Also ich habe selbst keine Erfahrung im Einsatz von XML-basierten Datenbanken -- aber viele bieten z.B. ein REST API, das deckt ja CRUD (etwas anders, als man es gewohnt ist) ab:
    GET -> read
    POST -> beliebige Operation
    PUT -> create / update
    DELETE -> delete


    Ansonsten gibt es Standards wie XPath / XQuery ... Oder auch DOM-basierte APIs (document.createElement() et al).


    Wenn das Backend ein DOM direkt speichern kann (was ja hierarchisch wäre) würde ich mal vermuten, dass das für den Anwendungsfall, hierarchische Daten zu speichern, performant ist :)


    ---
    edit: Trotzdem würde ich glaube ich aus rein pragmatischen Gründen bei dem "einfachen Tool" SQLite bleiben und eben einfach die nötigen Constraints selbst implementieren -- ODER sicherstellen, dass die verwendete SQLite-Version foreign keys UND trigger unterstützt, z.B. statisch linken.

    Asrock A75 Pro4-M
    Debian wheezy (testing, stock) (aktuell 2012-08-24: Linux 3.2, VDR 1.7.28)
    vdr-sxfe (xineliboutput)
    Pioneer VSX-520-K

  • Zitat

    Ich habe mir mal das Prinzip einer XML-basierten DB angesehen...


    Hm, bevor Du Dich jetzt vollends verläufst, installier Dir doch mal was funktionierendes und schau Dir die Protokolle an.
    Die Hierarchien, wie sie jetzt im Raum schweben, sind im Protokoll doch garnicht vorgesehen.


    Wenn Du im ganzen Protokoll-Wust noch berücksichtigst, wo überall der Anwender eingreift, dann löst sich alles in Wohlgefallen auf.


    ... und was die Datenbanken anbelangt: such Dir eine aus, mit der Du gut klar kommst. Der Rest ist Nebensache.
    Jede der bekannten Datenbanken ist gut genug.
    Kannst ja auch mal schauen, was die üblichen Verdächtigen so verwenden ...


    Postgres kann beide Welten bedienen, ist aber - meiner bescheidenen Meinung nach - nicht ganz so fehlertolerant und solide wie mySQL.


    Wenn ich mich nicht irre, dann willst Du doch ein Plugin erstellen. Also solltest Du zuerst mal schauen, was der VDR so bietet.
    ... und mache einfach ein paar Messungen
    , bevor Du Dich in unbekannten Wassern verschiffst.
    Ein guter Anhaltspunkt ist beispielsweise die EPG-Daten einzulesen und dann nach einem Eintrag suchen zu lassen, den es garnicht gibt.
    Dabei werden alle Datenstrukturen durchlaufen - es ist also der schlechtest aller anzunehmenden Fälle.
    Wenn Du Dir die Zeiten mit den VDR-Hausmitteln auf der Zunge zergehen lässt, wird die Frage nach einer Datenbank plötzlich unwichtiger, als ein Sandkorn in der Wüste ;)


    KISS rocks :mua


    Gruß Gero

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

  • Hi,


    vielleicht solltest du mal deine Applikation ein bisschen genauer beschreiben, also was du mit den Daten denn genau vorhast und wie du auf die Daten zugreifen willst.


    Baumstrukturen performant in einer relationalen DB abzuspeichern ist in einem gewissen Rahmen durchaus möglich, wenn man sich bewusst auf redundante Daten einlässt. Beispielsweise ist das Problem beim auslesen der Baumstruktur ja, dass man eigentlich rekursiv Queries absetzen muss, um den ganzen Baum von der Wurzel oder von einem Blatt ab auszulesen. Legt man aber z.B. ein zusätzliches Feld an, das in einer kommaseparierten Liste alle Elternknoten cacht, kann man das ganze mit einem Query erledigen...dann wird natürlich der CUD Teil des CRUD ein bisschen komplexer zu programmieren :)


    Ciao Louis

  • ich hab in Ubuntu die lib XQilla gefunden. Sie bietet neben XQuery auch das XQuery update facility an. Wenn die Beschreibung stimmt, sollte es damit möglich sein, Dokumente entsprechend zu bearbeiten.


    Ich verstehe nur nicht, wie der Spaß angewendet wird und ob das Dokument, worin die Daten stehen, zunächst vollständig in den RAM geladen werden muss. Ich schätze, dass so ca. 10.000 Einträge mit jeweils 10 - 20 Metadaten im Schnitt durchaus möglich sind. Allein die TV-Kanäle belaufen sich bei SAT auf 1500 mind.


    Medion Digitainer; AsRock B75 Pro3-M, Celeron G540; Kingston Value 4GB
    Samsung SpinPoint 250GB 2,5"; Samsung WriteMaster DVD-Brenner;
    TT-S2-6400, 2x TT-S2-1600, Ubuntu 12.04 mit YaVDR-Paketen. VDR 1.7.27, UPnP/DLNA-Plugin

  • Okay, dann zum Szenario. Es geht um das UPnP/DLNA-Plugin.


    ich habe eine hierarchisch aufgebaute Struktur ähnlich einem File-System. Bei Live-TV und Aufnahmen ist die Sache relativ einfach, da ich hier die Struktur vom VDR einfach übernehmen kann. Da ändert sich relativ selten etwas.


    Bei Aufnahmen also: <Serie>/<Folge>/<XXX.rec>/<zeugs> bzw. <Aufnahme>/<XXX.rec>/<zeugs>. Einfach!
    Bei Live-TV <Gruppe>/<Sender> bzw. <Sender>. Super einfach!


    Jetzt sollen aber auch noch andere Dateien, wie MP3s oder weitere Videos abgespielt werden können. Hier habe ich Plugins eingeführt, die regelmäßig zum Scannen aufgerufen werden um die Metadaten der unterstützten Dateien zu liefern.
    Diese Daten sollen irgendwo zentral gecacht werden, um nicht bei jedem Zugriff, erneut die ganzen Daten abzufragen. Die Felder ObjectID und ParentID sollen dabei die Baumstruktur abbilden.


    Wenn ich jetzt alle Objekte des Ordners mit ID XY haben möchte, dann mach ich ein SELECT * FROM objects WHERE parentID = XY. Ich kann immer nur einen Container abfragen und ich traversiere auch niemals über die einzelnen Container hinweg. Das heißt, wenn ich einen Container abgefragt habe, erhalte ich eine Liste mit ggf. weiteren Verzeichnissen und in einer neuen Anfrage kann ich in das folgende Verzeichnis wechseln. Also quasi in Linux-Shell: "cd XY/" geht, aber "cd X/Y/Z/" geht nicht, sondern wenn dann "cd X && cd Y && cd Z", wo durch jeder Aufruf erst einmal durchgeführt werden muss, bevor ich im Subsubsubverzeichnis bin.


    Beim Suchen wird über alle Elemente gesucht, ungeachtet der hierarchischen Struktur.


    Medion Digitainer; AsRock B75 Pro3-M, Celeron G540; Kingston Value 4GB
    Samsung SpinPoint 250GB 2,5"; Samsung WriteMaster DVD-Brenner;
    TT-S2-6400, 2x TT-S2-1600, Ubuntu 12.04 mit YaVDR-Paketen. VDR 1.7.27, UPnP/DLNA-Plugin

  • Diese Daten sollen irgendwo zentral gecacht werden, um nicht bei jedem Zugriff, erneut die ganzen Daten abzufragen. Die Felder ObjectID und ParentID sollen dabei die Baumstruktur abbilden.


    Wenn ich jetzt alle Objekte des Ordners mit ID XY haben möchte, dann mach ich ein SELECT * FROM objects WHERE parentID = XY. Ich kann immer nur einen Container abfragen und ich traversiere auch niemals über die einzelnen Container hinweg.


    Ok, also auch wenn ich es schade finde, für solche Dinge immer wieder die konzeptionell eigentlich unpassenden relationalen Datenbanken heranzuziehen -- denke mit DEN Anforderungen kommst du mit SQLite WIRKLICH am schnellsten hin. Ich fand es nur keine so besonders gute Idee, mich ausgerechnet bei SQLite auf constraints checking verlassen zu wollen :)


    Was aber Performance angeht, die wird für den hier geschilderten Anwendungsfall sicher sehr gut -- besonders mit einem Index auf "parentID".


    Habe auch einen kurzen Blick auf XQilla geworfen und mir scheint, dass es sich hier AUSSCHLIESSLICH um eine XQuery/XPath Implementierung handelt -- ohne Persistenz-Komponente. Die wirst du aber wohl kaum selbst schreiben wollen, und "einfach" XML-Textfiles zu nehmen wäre vermutlich für deinen Anwendungsfall nicht performant genug.

    Asrock A75 Pro4-M
    Debian wheezy (testing, stock) (aktuell 2012-08-24: Linux 3.2, VDR 1.7.28)
    vdr-sxfe (xineliboutput)
    Pioneer VSX-520-K

  • Man kann es aber auch kompliziert machen.


    Der Pfad und Name ist der Key zu deinen gecachten Metadaten.
    Und schon ist die Sache einfach und linear.
    Und wenn die Datenbank irgendwann doch zugroß wird, dann kannst den Pfad in eine Zahl umwandeln
    und dann über diese deine Metadaten suchen.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Zitat

    Man kann es aber auch kompliziert machen.

    Genauso sehe ich es auch.


    Wenn Du einen DLNA-fähigen Medienserver schnitzen willst (und aus Deinen Kommentaren habe ich das raus gelesen), dann explodiert die Komplexität auch wenn Du nicht um 3 Ecken denkst. Das Thema ist umfangreich genug, da musst Du Dir nicht noch das Leben mit (unnötigen) Hierarchien schwer machen.


    Nicht alles, was auf den ersten Blick nach Hierarchie aussieht, muss auch so behandelt werden.
    Deshalb nomml mein Appell: schau Dir erstmal an, wie es andere machen.


    Gruß Gero


    P,S. Du könntest z.B. auch überlegen, ob Du nicht die info-Datei erweiterst, oder eine ähnliche Datei zufügst. Dann bleiben die Metadaten bei den Aufnahmen auch wenn diese umbenannt oder verschoben werden.

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

  • Okay, um das zusammen zu fassen: SQLite ist und bleibt die beste Wahl. Der Check auf die ParentID wird nur noch im Source-Code gemacht. Wenn ein Nutzer in der DB rumpfuscht und seine Integrität gefährdet, ist er selbst schuld.


    DLNA ist - wie ich schon häufig erwähnt habe - nicht so kompliziert, wenn man den Standard hat. Okay, es gibt jede Menge seltsame Sachen, aber in der Regel ist es kein Hexenwerk.


    Medion Digitainer; AsRock B75 Pro3-M, Celeron G540; Kingston Value 4GB
    Samsung SpinPoint 250GB 2,5"; Samsung WriteMaster DVD-Brenner;
    TT-S2-6400, 2x TT-S2-1600, Ubuntu 12.04 mit YaVDR-Paketen. VDR 1.7.27, UPnP/DLNA-Plugin

  • Okay, um das zusammen zu fassen: SQLite ist und bleibt die beste Wahl.


    Da bin ich mir zwar nicht sicher, vermute es aber stark -- einfach weil ich jetzt kein so leichtgewichtiges DBMS mit hierarchischem Datenmodell kenne. Eventuell wäre aber auch BDB was, wenn du den Vorschlag hier aufgreifst, auf die Hierarchie direkt zu verzichten (weiß nicht, ob das für dich praktikabel ist)


    Der Check auf die ParentID wird nur noch im Source-Code gemacht. Wenn ein Nutzer in der DB rumpfuscht und seine Integrität gefährdet, ist er selbst schuld.


    Bei DBMS-Servern kann man das so oder so sehen -- ich bevorzuge auch da den Ansatz, dass eine Komponente die "Datenhoheit" hat. Bei einem embeddable DBMS wie SQLite würde ich das aber auf JEDEN Fall so sehen :)


    Zitat

    DLNA ist - wie ich schon häufig erwähnt habe - nicht so kompliziert, wenn man den Standard hat. Okay, es gibt jede Menge seltsame Sachen, aber in der Regel ist es kein Hexenwerk.


    Viel Erfolg!

    Asrock A75 Pro4-M
    Debian wheezy (testing, stock) (aktuell 2012-08-24: Linux 3.2, VDR 1.7.28)
    vdr-sxfe (xineliboutput)
    Pioneer VSX-520-K

  • Zitat

    DLNA ist - wie ich schon häufig erwähnt habe - nicht so kompliziert, ...

    Hm, nichts ist kompliziert, wenn man weiß wie's geht.
    Trotzdem ist es noch ne Menge Holz. Ich würde die Komplexität nicht unterschätzen.


    Zitat

    ... wenn man den Standard hat.

    Whow - Du bist also einer der wenigen Priviligierten, die Zugang zum Standard haben.
    Solltest Du je über dezentrale Sicherungskopien nachdenken, ich biete Dir gerne etwas Platz auf meinem Server an :mua


    Gruß Gero

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!