Ab wann brauch' ich eine Datenbank? Und welche?

[mutetella]

Hallo,

ich habe zur Abbildung von Terminen eine Klasse 'Appointment()' mit den Attributen

• 'title' (str)
• 'begin' (datetime)
• 'duration' (int)
• 'categorie' (str)
• 'longtext' (str)
• 'recurrence' (class Recurrence).

Daneben habe ich eine Klasse 'DaySheet()', die wiederum alle zu einem Tag gehörenden Appointment-Exemplare bündelt.
Zuletzt schicke ich ein 'Content()'-Exemplar an die View(). Dieses Exemplar beinhaltet alle DaySheet's, die aktuell angezeigt werden sollen.
Und wenn das so weitergeht, ende ich im Wahnsinn...

Darum habe ich das Gefühl, dass jetzt die Zeit für eine Datenbank gekommen ist. Neben dem, was ich bisher schon mache, möchte ich:

• Daten verschieden 'bündeln', z. B. alle Termine der Kategorie 'Privat' vom Jahr 2010
• vom Nutzer eigens erstellte Felder, wie z. B. 'Wetter', 'Gewicht' oder 'gelaufene km' hinzufügen oder entfernen
• bestimmte Termine nur bestimmten Nutzern zugängig machen

Ist dafür eine Datenbank besser geeignet oder reicht es, wenn ich meine Appointment-Exemplare mit cPickle speichere?

Wie muss ich mir das an einem konkreten Beispiel vorstellen, wenn ich eine Datenbank benutze:
Mein datepicker zeigt mir die Tage eines Monats an. Die Tage, die auch Termine enthalten, sind markiert. Dazu habe ich für jeden Tag des Monats ein DaySheet-Exemplar angelegt, das wiederum eventuell vorhandene Termine beinhaltet. Somit kann ich zum einen die Tage mit Terminen markieren, zum anderen bei der Auswahl eines Tages mit Terminen diese auch gleich aufführen.
Befülle ich die DaySheet's aus der Datenbank und schicke diese dann an den datepicker oder schicke ich eine Klasse an den datepicker, über die ich direkt in die Datenbank greife?

Oder habe ich eine komplett falsche Vorstellung und Herangehensweise?

mutetella

[sparrow]

Hallo,

ich habe noch nicht so ganz verstanden was du machen willst, aber an sich hört sich das schon nach einer Applikation für eine Datenbank an.

Wenn du die ganzen Datensätze einzeln speicherst, und entsprechend jeder Datensatz ein Datumsfeld hat, helfen die GROUP (gruppieren) und SELECT (auswählen)-Anweisungen aus dem SQL-Standard um zu summieren oder zu selektieren.

Ich weiß nicht wie viel du von SQL-Datenbanken bisher weißt, aber es sollte dadurch eher einfacher und intuitiver funktionieren als mit Pickle.

Edit: also wenn du einen Tag bündelst kannst du das direkt aus den einzelnen Datensätzen heraus lesen.

Gruß
sparrow

[mutetella]

Lese gerade in der sqlite3-Doku und versuche, mir das mit meinen Termindaten vorzustellen... da kommen natürlich schon die ersten Fragen:
Wie schon beschrieben lege ich bisher jeden Termin in einem Exemplar der Klasse 'Appointment' ab, z. B.

Code: Alles auswählen

a = Appointment(title='Grillen', begin=datetime.datetime(2011, 5, 6, 20, 0), duration=18000)

Wenn ich nun zwei Abfragen

Code: Alles auswählen

a.is_match(datetime.date(2011, 5, 6))
a.is_match(datetime.date(2011, 5, 7))

ausführe, erhalte ich jeweils 'True' zurück, da der Termin am 06. Mai um 20.00 Uhr beginnt und am 07. Mai um 01.00 Uhr endet.
Wie kann etwas abgefragt werden, dessen Ergebnis nicht direkt sondern nur über eine Methode ermittelt werden kann?
Und was, wenn diese Methode nicht nur überprüfen muss, ob ein Datum innerhalb einer bestimmten Zeispanne (duration) liegt, sondern auch, ob sich ein Termin eventuell wiederholt und diese Wiederholung wiederum in einer eigenen Klasse (Recurrence) abgebildet ist?

Arbeite ich überhaupt noch mit Appointment-Exemplaren oder spielt sich das alles direkt über die Datenbank ab? Registriere ich also Methoden wie 'is_match()' in sqlite3 und benötige deshalb überhaupt keine Appointment()-Klasse mehr?
Oder arbeite ich weiterhin mit Appointment-Exemplaren, die ich aus den Daten der Datenbank erstelle? Aber dann muss ich ja das Selektieren der Daten doch wieder selbst machen? Kann ja auch nicht sein...

Wow... was hab' ich da nur wieder für ein Fass geöffnet?

mutetella

[Rebecca]

Deine Appointment-Exemplare behaelst du bei. Es klingt, als moechtest du ein ORM haben, schau dir mal SQLAlchemy und Elixir an.

[BlackJack]

@mutetella: Du behältst `Appointment`-Objekte. Die "höhere" Programmlogik und insbesondere die Anzeige sollte nichts davon mitbekommen, dass Deine Daten in einer relationalen Datenbank liegen.

Das `is_match()` muss sich ja gar nicht verändern. Dem sollte es doch egal sein ob das `Appointment`-Exemplar mal gepickelt war oder ob die Daten mit denen es erstellt wurde aus einer Datenbank kamen.

Interessanter ist eher die Stelle an der alle `Appointment`\s verwaltet werden und man dort eine Abfragemethode hat, die alle `Appointment`\s liefert, welche zum Beispiel in einem bestimmten Zeitraum liegen. Wenn die `Appointment`\s gepickelt waren, würde man in so einer Methode wahrscheinlich eine Liste mit allen `Appointment`\s filtern. Wenn die Daten in einer relationalen Datenbank liegen, könnte man dafür eine entsprechende SQL-Anfrage erstellen und `Appointment`\s aus dem Ergebnis erstellen. Wobei man bereits eingelesene und erstellte Objekte vielleicht cachen sollte. An der Stelle fängt man dann an so etwas wie SQLAlchemy selber zu implementieren.

Wenn so eine Methode mehr prüfen muss als mit den "einfachen" Attributen möglich ist, kommen wahrscheinlich komplexere SQL-Anfragen oder zusätzliche Anfragen hinzu, die noch andere Tabellen mit einbeziehen. Zum Beispiel eine wo die Daten von `Recurrence`-Objekten gespeichert sind.

Wenn Du eine relationale Datenbank verwenden willst, solltest Du von Grund auf mit dem Entwurf des Datenmodells beginnen. Also solltest Du schauen welche Daten Du hast, wie die zusammen hängen und wie die Zugriffsmuster darauf aussehen. Danach kannst Du dann die Tabellen erstellen und Klassen/Methoden darauf aufbauen.

Das Ganze ist komplizierter als einfach zu "(ent)picklen", weil es eben nicht mehr nur ein beliebiger Objektgraph ist, der einmal erstellt wird und dann einfach zur Verfügung steht. Man muss sich die Tabellenstruktur überlegen und wann man welche Daten von der Datenbank abfragt und ändert. Ausserdem ist nicht alles was man in einem beliebigen OOP-Entwurf macht, geeignet sinnvoll in Tabellenform "flach geklopft" zu werden. Darum würde ich beim Entwurf des Datenmodells immer vom relationalen Modell ausgehen.

[mutetella]

Soweit ich das bisher überblicke, würde ich mit SQLite folgendermaßen vorgehen:

Ich erstelle eine table 'appointment', eine table 'recurrence' und eine view 'app_view', in der ich Termin(e) und evtl. dazugehörige Wiederholung(en) miteinander verknüpfe.
Aus der 'app_view' selektiere ich mir dann die gerade gewünschten Termine und erstelle mit den Daten meine Appointment()- und Recurrence()-Exemplare, mit denen ich dann weiterarbeite.

Wobei ich mir die 'app_view' eigentlich sparen könnte und, falls ein appointment eine recurrence-ID hinterlegt hat, diese recurrence dann in einem weiteren Schritt hole. Oder doch eine view verwenden?

Macht das vom Grundsatz her Sinn?

Welchen Vorteil würde mir SQLAlchemy oder ähnliches bringen. Muss gestehen, dass ich mich nur kurz damit beschäftigt habe und deshalb noch nicht einschätzen kann, ob das für meinen Kalender nicht etwas übertrieben ist...

mutetella

[BlackJack]

@mutetella: Mit SQLAlchemy wärst Du unabhängiger von einer konkreten Datenbank und das erstellen der Objekte entfällt -- die kommen direkt fertig aus den Abfragen. Ausserdem muss man das zurück speichern von Änderungen nicht komplett von Hand machen.

[mutetella]

Sorry, aber ich hab' die Kurve noch nicht so ganz...

Wenn ich ohne ORM eine Abfrage starte, die nicht 'nur' einzelne Werte einer Tabelle vergleicht sondern diese Werte zuerst in Verbindung setzen muss... wie geht sowas?

Beispiel:
Um einen Termin auf ein bestimmtes Datum zu prüfen reicht es nicht aus, nur den Wert 'begin' mit dem zu prüfenden Datum zu vergleichen. Termine können ja entweder durch ihre Länge ('begin' + 'duration') oder eine eventuelle Wiederholung ('recurrence.is_match()') durchaus zu Tagen gehören, die nicht mit 'begin' übereinstimmen.

Wie würde eine solche Abfrage nur unter Verwendung von sqlite3 aussehen?
Alle Datensätze durchlaufen, jeweils ein Appointment()-Exemplar erstellen und darauf die Abfrage starten?

Ich sträube mich noch gegen SQLAlchemy, weil ich nicht so viele Abhängigkeiten schaffen möchte.

mutetella

[deets]

Du musst eine Design-Entscheidung treffen: entweder du multiplizierst deine recurring-events aus in die Datenbank. Dann kannst du auch SQL benutzen. Nachteil: du musst periodisch weiterschreiben, denn du legst zu Beginn ja nur fuer einen beschraenkten Zeitraum an (zB 2 Jahre), aber der Geburtstag deiner Oma ist ja auch noch in 5 Jahren (langes Leben vorrausgesetzt).

Oder du speicherst nur den Start-termin, und einen Recurrence-Descriptor. Dann musst du aber im Grunde immer mit allen Appointments im Speicher jonglieren, um eben so eine Abfrage zu machen. Das ist wahrscheinlich nicht soooo tragisch, weil - wer hat schon mehr als ein paar hundert oder tausend Termine? Das sind ja speicher-maessig Peanuts.

Aber es kann schon nerven, wenn du zB eine Webanwendung hast, und dann fuer jedes Request alle appointments laden musst. Ich hatte genau den Fall, und mich darum dann fuer die explizite Variante entschieden.

Und deinen Abhaengigkeits-Phantomschmerz solltest du ueberkommen. Wenn das ein Lern-Projekt ist, ist es egal. Wenn es distributiert werden soll, hast du eh das Problem zu loesen, wie genau. Und SA ist es wert, als Technologie.

[BlackJack]

@mutetella: Dein Beispiel verstehe ich nicht. Im ersten Absatz klingt es so als wenn Du *ein* `Appointment` bereits hast und im zweiten Absatz fragst Du dann ob Du *alle* `Appointment`\s durchlaufen musst? Das sind doch zwei verschiedene Sachen!?

Wenn Du *einen* Termin hast, kannst Du doch einfach Anfang und Länge prüfen, und wenn dass nicht zutrifft noch die eventuell zugehörigen `Recurrence`-Daten abfragen und prüfen.

Falls Du aber ein Datum hast und dazu alle `Appointment`\s haben willst und dazu *alle* `Appointment`\s und `Recurrence`\s aus der Datenbank laden musst, dann solltest Du vielleicht das Datenbankmodell überdenken.

[mutetella]

Oder du speicherst nur den Start-termin, und einen Recurrence-Descriptor. Dann musst du aber im Grunde immer mit allen Appointments im Speicher jonglieren, um eben so eine Abfrage zu machen. Das ist wahrscheinlich nicht soooo tragisch, weil - wer hat schon mehr als ein paar hundert oder tausend Termine? Das sind ja speicher-maessig Peanuts.

Ohne Wiederholungsregeln wäre das ja kaum sinnvoll. Genauso wie ein Termin, der über mehrere Tage läuft auch nicht jedes Datum dieser Tage fest hinterlegt. Andererseits ist das ja auch der Punkt: Nachdem ich eben nicht fixe Werte zum Abfragen habe, muss ich erst alle Werte einlesen, um eine Abfrage zu starten.
So jedenfalls verstehe ich Deine Antwort.

Falls Du aber ein Datum hast und dazu alle `Appointment`\s haben willst und dazu *alle* `Appointment`\s und `Recurrence`\s aus der Datenbank laden musst, dann solltest Du vielleicht das Datenbankmodell überdenken.

Verstehe ich jetzt nicht. Wie sollte es denn anderst funktionieren? Um Daten, die zuerst generiert werden müssen, abzufragen, muss ich diese doch zuerst *alle* laden um dann abfragefähige Werte zu erstellen.
Oder meinst Du mit 'Datenbankmodell überdenken', dass ich doch mehr als ein Auge auf SQLAlchemy werfen sollte?
Steh' ich auf dem Schlauch?

mutetella

[deets]

Ich denke BJ meint damit das, was ich auch schon sagte: wenn du sinnvoll mit SQL abfragen willst, dann muessen die recurrences in die Datenbank.

[mutetella]

... dann muessen die recurrences in die Datenbank.

Davon bin ich immer schon ausgegangen. Wo sollten die denn sonst sein?
Oder meinst Du, zu jeder auftretenden Wiederholung sollte das Datum in die Datenbank? Ich stelle mir da einen Wiederholungstyp 'alle 2 Tage ohne Endpunkt' vor... Das lässt sich doch so nicht abspeichern...

Hmm... entweder konnte ich meine Frage nicht richtig formulieren oder ich bin zu blöd, die Antwort zu verstehen...

mutetella

[deets]

Na, ich meinte schon die konkreten Termine. Wenn du also einen Termin hast, der sich zB alle 2 Wochen wiederholt, dann musst du - um mit SQL arbeiten zu koennen - schon fuer jeden Wiederholungstermin einen Eintrag erzeugen, der letztlich dann natuerlich auf den ursprungs-Termin zeigt.

Wenn du das nicht machst, dann kannst du eben kein SQL verwenden, um festzustellen, ob jemand in 3 Monaten einen Termin hat, der heute ist + sich alle 2 Wochen wiederholt.

Jetzt klar?

[mutetella]

Das hieße ja, für eine 2wöchige Wiederholung müssten mehr als unglaubliche 207000 Einträge vorhanden sein. Das kann ja nicht sein.

Was wäre also die Alternative?
Doch Datensatz für Datensatz einlesen, auswerten und aus den Daten, die meiner Auswahlbedingung entsprechen ein Appointment()-Objekt erstellen.
Aber dann kann ich auch gleich aus allen Daten eine Liste aller Termine anlegen und bei jeder Abfrage darauf zugreifen.
Was wiederum heißt, dass ich dann auch gleich mit Pickle arbeiten kann.

Oh Mann, ich dreh' mich im Kreis!

mutetella

[BlackJack]

@mutetella: Wenn Dein Kalender die Daten für ≈7.900 Jahre erfassen soll, dann bräuchtest Du 207.000 Einträge für einen Termin der sich alle zwei Wochen wiederholt. Das kann schon sein.

*Die* Alternative gibt es nicht. Du musst wissen wie viele Daten anfallen und welche Arten von Anfragen wie oft an diese Datenbasis gestellt werden, um eine halbwegs effiziente Datenhaltung entwerfen zu können. Dabei kann jede Lösung auch Nachteile haben. Da gilt es abzuwägen.

Der Knackpunkt an dieser Stelle ist vielleicht, dass Du keine Lösung zu einem Problem suchst, sondern zu einer Lösung ein Problem. Du hattest keinen Haufen Daten und bist zu dem Schluss gekommen eine relationale Datenbank ist eine geeignete Technik dafür, sondern gehst von einer relationalen Datenbank aus und willst Deine Daten da irgendwie hinein bekommen. Das kann gut funktionieren – muss es aber nicht.

Wenn Du von Pickle weg kommen willst, zum Beispiel weil man sich damit auf Python einschränkt, könntest Du die Daten in JSON oder XML abspeichern. Oder vielleicht auch im ICAL-Format, damit man sie in anderen Anwendungen laden kann. Du könntest sie auch in eine relationale Datenbank speichern ohne deren Möglichkeiten zu benutzen. Also wie bei Pickle — am Anfang komplett aus der DB laden und am Ende wieder zurück speichern. Eventuell wäre auch eine dokumentorienterte ”NoSQL”-Datenbank wie CouchDB oder MongoDB interessant. Da kannst Du Anfragen/Views zum Beispiel in JavaScript ausdrücken.

[mutetella]

Du musst wissen wie viele Daten anfallen und welche Arten von Anfragen wie oft an diese Datenbasis gestellt werden, um eine halbwegs effiziente Datenhaltung entwerfen zu können.
...
Du hattest keinen Haufen Daten und bist zu dem Schluss gekommen eine relationale Datenbank ist eine geeignete Technik dafür, sondern gehst von einer relationalen Datenbank aus und willst Deine Daten da irgendwie hinein bekommen.

Du hast mal wieder vollkommen Recht. Ich bin in meinem Programm an einen Punkt gekommen, an dem ich zum einen verschiedene Selektionen von Terminen und zum anderen die Möglichkeit zum Abspeichern der Daten brauche. Das Heil habe ich ohne länger nachzudenken in "der Datenbank" (und in diesem Thread ) gesucht.

Ok, seit 2 Tagen bin ich nicht mehr ansprechbar, denke ständig über Datenbankmodelle im Kontext meines Kalenders nach und will mich für oder gegen etwas entscheiden, von dem ich kaum eine Ahnung hab'...

Hier mein Zwischenergebnis :

• Dokumentorientierte Datenbanken scheiden wohl aus. Wenn ich das richtig verstehe, würde ich meine Termindaten in XML, JSON, iCal oder ähnlichem dort ablegen.
  Ich muss gestehen, so wirklich habe ich den Ansatz noch nicht verstanden, jedenfalls fehlt mir die Vorstellung davon, wie ich Daten, die einen Termin bilden, dort sinnig unterbringen könnte.
• iCal
  + Viele Kalender greifen darauf zurück. Der Austausch von Kalenderdaten wäre somit relativ problemlos.
  - Mir bekannte Kalender, die auf etwas größere iCal-Bestände zurückgreifen, sind unerträglich langsam.
  - Daten können nicht direkt aus der Anwendung heraus verschlüsselt abgelegt werden.
• Pickle
  + Supereinfach implementiert
  + Die Klasse(n) bestimmen die Datenstruktur
  - Die Klasse(n) bestimmen die Datenstruktur, ein späteres Ändern erscheint mir recht umständlich
  - Eher unsicher bei Programmabstürzen, außer man speichert Änderungen sofort ab, was bei größeren Datenmengen dann doch wieder unhandlich wird, da immer alles abgespeichert/geladen werden kann.
• SQLite
  + Bereits bei Python dabei
  - siehe Pluspunkte von SA
• SQLAlchemy mit ORM
  + Müsste mich nicht allzu tief in SQL reinhängen
  + SA sorgt dafür, dass aus den Daten wieder Objekte werden. Muss ich nicht selbst an einer mehr schlechten als rechten Lösung basteln.
  + Muss mich nicht um das 'ordentliche' Zurückschreiben von Änderungen kümmern.

Wie gesagt, ist jetzt erstmal ein Zwischenstand.

Enthält mein Halbwissen gänzlich falsches?
Weitere Punkte sind natürlich sehr willkommen!

mutetella

[deets]

Dokumentorientierte Datenbanken sind nicht viel anders als Pickle, nur dass du sozusagen nur den Zustand von Objekten, nicht aber deren Klasse mit abspeicherst. Das sieht auf den ersten Blick erstmal schlechter aus, ist es aber nicht. Denn

- gepickelte Daten sind "undurchsichtig". Du kannst sie ohne deinen Code zu haben nicht so ohne weiteres einsehen.
- Migration der Daten ist dadurch aufwaendiger, wenn du zB Klassen aenderst, aber alte Datenbestaende noch einlesen koennen musst. Das scheinst du ja aber selbst schon zu ahnen.

Deine Ueberlegungen zur (un)Sicherheit von Pickle bei Programmabstuerzen sind aber unbegruendet - dasselbe gilt fuer alle anderen Speichermethoden auch. Die einzige Vorsichsmassnahme, die man ergreifen sollte ist, niemals Daten in dieselbe Datei zu speichern - sondern immer via neue Datei/renaming zu arbeiten. Dadurch wird die Operation sicher, und man verliert nix. Wenn es wirklich mal "groessere Datenbestaende" sind, dann ist es vielleicht von Nachteil - aber da koennte man zB ZODB benutzen, das ist sozusagen Pickle auf ACID

Aber wie gesagt, besonders geeignet ist Pickle IMHO eh nicht, die Migration von Daten ist einfach zu laestig. Ich habe damals sowas teilweise mit XML als Zwischenformat gemacht (da war JSON noch nicht bekannt, mir zumindest nicht), und das war einfach alles nur doof.

Ob du SQL (und dann sinnvollerweise SA) benutzt, haengt nach wie vor von deinem Datenmodell ab. Wenn du im Grunde nur simple Persistenz suchst, ist es etwas ueberkanditelt. SQL ist nicht so dolle beim Abbilden von beliebigen Objektgraphen, da sind pickle bzw. Dokument-basierte Ansaetze besser (letztere koennen eigenlich nur Baeume, aber da muss man dann halt etwas rumtricksen - wenn man's ueberhaupt braucht, sehe ich bei deinen Daten gar nicht)

Den entscheidenden Vorteil liefert SQL, wenn du deine Termine bei recurrences wirklich auch "ausmultiplizierst", wie ich das schon erwaehnte. Denn dann kannst du die mit indizes und anderen Schmankerln versehene Datenbank auch fuer komplexere Queries benutzen.

Das musst du halt entscheiden.

[BlackJack]

@mutetella: Wie kann man sich denn *nicht* vorstellen wie ein Termin in einer dokumentorientierten DB aussieht!? Stell Dir Objekte ohne Methoden vor, also nur die Datenattribute. Ein Termin ohne Wiederholung in JSON:

Code: Alles auswählen

{
    "title": "Test-Termin",
    "begin": "2011-05-12T2300",
    "duration": 60,
    "category": "Spam",
    "longtext": "Blah blah blub…",
    "recurrence": null
}

Mit Wiederholung würde anstelle des ``null``-Literals dort ein weiteres JSON-Objekt stehen, welches die Daten der Wiederholung enthält. Wobei man `begin` vielleicht besser als Zahl ablegt, damit man damit einfacher rechnen kann. Also Abfragen über den Zeitraum zum Beispiel einfacher formulieren kann.

[noisefloor]

Hallo,

ich nutzte für bestimmte Sachen auch eine dokumenten-orientierte DB (CouchDB). Wobei ich die Entscheidung "(My)SQL oder CouchDB" auch davon abhängig machen, welche Daten ich wie Abfragen möchte (muss).

Es gibt halt Abfrage, die sind mit SQL-Queries einfacher als mit JavaScript MapReduce-Funlktionen in CouchDB - und umgekehrt.

BTW: So einen Kalender könnte man auch ganz nett in einem KV-Store abbilden. Aber ich will jetzt nicht noch mehr Verwirrung stiften

@mutella: Eine IMHO ganz gute Übersicht über verschiedene DB-Typen findest du z.B. hier: Link.

Gruß, noisefloor