Das deutsche Python-Forum

Hab' heute schon so einiges über dokumentorierntierte DB gelesen, auch über KV-Stores, lese gerade einen Artikel über redis, finde das alles sehr sehr interessant, wirklich...

Immer wieder stoße ich auf die Aussage (und ihr sagt das ja auch), dass für eine Entscheidung auch wichtig ist, welche Anfragen an die DB gerichtet werden müssen. Und mir scheint, da beißt sich die Katze in den Schwanz: Wenn der Datenbestand in seinem Rohzustand keine Anfrage zulässt, spielt es doch in meinem Fall, in dem keine wirklich großen Datenmengen anfallen, keine Rolle, mit welchem Modell ich die Daten verwalte.
Will heißen:
Wenn ich alle Termine für den 15.05.2011 suche, stelle ich eine Anfrage nach allen

• Terminen, die am 15.05.2011 beginnen

und

• Terminen, die vor dem 15.05.2011 beginnen und sich wiederholen oder deren Länge über den 15.05. hinausgeht

Letztere Termine werden dann außerhalb des DBMS danach selektiert, ob ihre Länge oder eine Wiederholung den 15.05.2011 berührt.
Demnach brauche ich letztlich 'nur' Anfragen nach bestimmten Datumswerten. Mal abgesehen nach einer Suche im 'longtext', 'title' oder 'category'. Aber solche Anfragen scheinen mir eher nebensächlich.
Inwieweit spielt es also eine Rolle, welche DB ich anspreche. Solche Anfragen bei meinem geringen Datenaufkommen meistern doch alle.

Wobei: Bei couchDB kann ich ja eigene Anfragen definieren, mit denen ich eine Suche nach einem Termin, der erstmal nicht als Treffer erkennbar ist, durchführen kann.
Aber macht das einen Unterschied, ob ich das Suchprozedere von einer couchDB-view oder außerhalb von einer Klassenmethode durchführen lasse?

Sagt mal: Mach' ich mir immer noch die ganz falschen Gedanken? Stimmt die Richtung?

mutetella

@mutetella: Ich denke das Grundproblem ist, dass Du erst einmal klären musst *warum* Du eine Datenbank einsetzen willst. Falls Du nur von Pickle weg kommen möchtest, weil Dir das zu intransparent und zu sehr an Python gebunden ist, könntest Du Deine Objekte auch einfach als JSON oder XML serialisieren und gut ist.

Falls Du nicht immer den gesamten Bestand laden und sichern möchtest, könntest Du entweder eine relationale Datenbank oder eine dokumentorientierte Datenbank verwenden, ohne dabei weitergehende Fähigkeiten der DB verwenden zu müssen. Bei einer relationalen DB ist das IMHO aufwändiger, weil Du die Objekte auf Tabellen aufteilen musst. Bei der dokumentorientierten DB könntest Du einfach die Objekte einzeln als JSON serialisieren und speichern. An der Stelle könnte man auch, wie noisefloor eingeworfen hat, einen KV-Store verwenden, der die serialisierten Dokumente als Werte aufnehmen kann. Eine dokumentorientierte DB würde man in dieser "Ausbaustufe" ja auch erst einmal nur als KV-Store verwenden. Einen KV-Store gibt es schon in der Standardbibliothek: das `anydbm`-Modul oder eine der konkreteren Implementierungen.

Falls Du weitere Funktionalität der Datenbank in Anspruch nehmen möchtest, kann man bei der jetzigen Strukturierung der Daten bei relationalen Datenbanken nicht so viel in SQL ausdrücken. Bei den dokumentorientierten kann man dagegen noch etwas vom Programm in die Datenbank verschieben.

BlackJack hat geschrieben:... dass Du erst einmal klären musst *warum* Du eine Datenbank einsetzen willst.

Je mehr ich mich mit dem Thema auseinandersetze, desto mehr wird klar, dass "die Datenbank" nicht dieses "magische Ding" ist, in das ich alles reinwerfen kann und das mir dann "irgendwie" das Zeugs so ausspuckt, wie ich es gerade haben möchte...
Jetzt heißt es, erstmal von meiner anfänglichen DB-Eupohrie wieder runterzukommen und mich damit abzufinden, dass eine "einfache" Lösung wahrscheinlich vorerst ausreicht.

Ich denke jetzt einfach mal laut weiter, Einwände oder Ergänzungen sind natürlich unbedingt gewünscht:

• Pickle scheidet aus bekannten Gründen aus.
• Je mehr ich darüber erfahre, in welcher Form Daten in dokument- oder objektorientieren Datenbanken untergebracht sein können, verstehe ich auch, weshalb meine Datenstruktur in dieser Form keine relationale DB braucht bzw. dort eher "hineingeklopft" werden müsste als dass sie in eine Tabellenform "gleiten" könnte.
• couchDB gefällt mir immer besser, ist aber eben keine "einfache" Lösung und wird von meinem Kalender nicht wirklich ausgereizt. Aber die Sache mit den views, die gefällt mir schon extrem gut. Obwohl ich mich dafür erst noch mit Javascript auseinandersetzen müsste.
  Auch wenn es für Python mit dem 'couchdb.view'-Modul die Möglichkeit gibt, view-Funktionen statt in Javascript in Python zu schreiben, tendiere ich eher dazu, dafür die "couchDB Muttersprache" zu verwenden, auch wenn ich das jetzt nicht begründen könnte.
• anydbm habe ich bisher überhaupt nicht beachtet. Finde das irgendwie so weichei-mäßig... Aber ok, wenn's reicht...

Vielleicht hat ja noch jemand eine gute Begründung, weshalb eine "Datenbank für Erwachsene" doch was für meinen Kalender wäre...

mutetella

Hallo,
[quote=mutella]ist aber eben keine "einfache" Lösung und wird von meinem Kalender nicht wirklich ausgereizt[/quote]
Zu deiner Beruhigung: das wirst du auch andere DBs nicht. Letztendlich ist das aber egal, weil ja in erster Linie wichtig ist, dass du schnell, sicher und effektiv zum gewünschten Ergebnis kommst.

[quote=mutella]Obwohl ich mich dafür erst noch mit Javascript auseinandersetzen müsste.[/quote]
Für einfach Abfragen reicht ja wirklich dünnes JS Wissen - das bekommt man in der Regel schon, wenn man Tutorials oder Blockeinträge zu CouchDB liest.

[quote=mutella]anydbm habe ich bisher überhaupt nicht beachtet. Finde das irgendwie so weichei-mäßig... Aber ok, wenn's reicht...[/quote]
anydbm ist die einfachste Form eines KV-Stores. Hätte z.B. den Vorteil, dass es Cross-Plattform in Python enthalten ist.

Gruß, noisefloor

Nachdem ich die letzten Tage mein DB Unwissen durch Halbwissen ersetzt habe, entstehen immer noch mehr Fragen rund um das Thema...

Meine ursprüngliche (Thread-)Frage ist aber beantwortet: Zum jetzigen Stand brauche ich keine Datenbank. 'json.dump' und '-.load' sollten vorerst ausreichen.
Ich bin davon ausgegangen, dass mir ein DBMS das selektieren meiner Termindaten vereinfachen würde. In gewisser Weise stimmt das auch, allerdings steht der Aufwand dafür in keiner Relation.

Irgendwie ja auch schade... trotzdem danke, dass ihr mich mal wieder auf den Teppich gebracht habt...

mutetella

Hallo,

von JSON nach CouchDB ist es nur ein seeehr kleiner Schritt

Gruß, noisefloor

noisefloor hat geschrieben: von JSON nach CouchDB ist es nur ein seeehr kleiner Schritt

Oder MongoDB

noisefloor hat geschrieben:von JSON nach CouchDB ist es nur ein seeehr kleiner Schritt

Nachdem ich mich während diesem Thread auch mit CouchDB befasst hatte, stand das auch hoch im Kurs. Müsste dazu nicht ein Server laufen, hätte ich mich wahrscheinlich hinreißen lassen...

Geblieben ist das JSON-Format zum Serialisieren. Und wenn ich dann in ferner Zukunft meinen popeligen Kalender auf eine Datenbank portiere, weil die Massen der weltweiten Community danach schreien, dann werden die CouchDB- und die MongoDB-Entwickler um meine Gunst buhlen und mit Spannung meiner Entscheidung entgegenzittern..., oder so.

Bis dahin.. Gute Nacht!

mutetella