geeignete Datenspeicherungsart gesucht

schlangenbeschwörer · Dienstag 12. Juni 2007, 20:05

Hallo!
Ich plane grad ein TODO-List/Timer Programm. In etwa hab ich schon ein Grundkonzept. Die TODO-Liste ist ja auch im Wiki unter [wiki]Projektideen[/wiki] erwähnt, und ich will das dann noch mit nem Timer kombinieren.
Ich suche jetzt noch das passende Speicherformat. Ich denke, pickle ginge zwar, aber wäre umständlich, ebenso andere Speicherformate, auf die man wie ein Dict zugreift. Bei einer Datenbank sehe ich die von Gerold im Datenspeicherung in Python Thread genannten Vorteile. Vor allem die Suchfunktionen und so. Allerdings hab ich auch Einträge hier gefunden, die andeuten, dass eine DB viel zu aufwändig für ein solches, eher kleines Projekt sind. Aber ich möchte es schon so machen, das es auch mit mehr einträgen läuft, und außerdem nicht alles selber programmieren, denn mit Python nach Werten in Tupeln die Dict-Values darstellen zu suchen, find ich blöd...
Und: Wenn DB, welche?
Hab mich schon ein klein bisschen eingelesen, konnt aber zu keinem Schluss kommen. Ist wohl tw. auch Geschmackssache, oder?
Jedenfalls sehe ich jetzt die dbs MySQL, wo ich schon etwas erfahrung mit hab (aber nicht in Zusammenhang mit Python), SQLite, wo die Doku auch gut sein soll und was einfach sein soll, und die anderen, die sonst noch so erwähnt werden...
Ich hoffe, ihr könnt mir zu etwas mehr Klarheit verhelfen.

Gruß, jj

gerold · Dienstag 12. Juni 2007, 20:31

schlangenbeschwörer hat geschrieben:Ich plane grad ein TODO-List/Timer Programm.
[...]
Ich suche jetzt noch das passende Speicherformat.
[...]
Jedenfalls sehe ich jetzt die dbs MySQL, wo ich schon etwas erfahrung mit hab (aber nicht in Zusammenhang mit Python), SQLite, wo die Doku auch gut sein soll und was einfach sein soll

Hallo schlangenbeschwörer!

Task Coach http://www.taskcoach.org/ verwendet z.B. XML als Speicherformat.

# The Task Coach file format (.tsk) is XML.
# Tasks can be exported to HTML. Effort can be exported to XML and iCalendar/ICS format.

Man kann gerne sein eigenes Speicherformat verwenden, aber man soll auf jeden Fall einen Import und einen Export in einem Standardformat wie z.B. iCalendar einplanen.

Textformate haben den Vorteil, dass andere Programme ohne große Probleme die Daten lesen und, wenn nötig, auch verändern können. Das geht natürlich auch mit Daten in Datenbanken, aber komplizierter. Dafür aber auch schneller...

Wie auch immer. Task Coach verwendet XML das in etwa so aussieht:

Code: Alles auswählen

<?xml version="1.0" ?>
<?taskcoach release="0.64.1" tskversion="16"?>
<tasks>
  <task id="34728848:1181676088.34" 
        lastModificationTime="2007-06-12 21:21:47" 
        startdate="2007-06-12" subject="asödflka"
  >
    <description>alskdföalsd</description>
  </task>
</tasks>

Die gleiche Tabelle in SQLite würde z.B. so aussehen:

Code: Alles auswählen

CREATE TABLE tasks (
    id INT PRIMARY KEY,
    last_modification_time TIMESTAMP,
    startdate DATE,
    subject TEXT,
    description TEXT,
    ...
)

Ich denke mal, dass du mit einer Datenbank besser dran bist.

Mal so in dem Raum gestellt:

Code: Alles auswählen

SELECT * 
FROM tasks
WHERE (subject LIKE '%Geburtstag%')

mfg
Gerold

schlangenbeschwörer · Dienstag 12. Juni 2007, 20:35

[quote="Gerold"]Ich denke mal, dass du mit einer Datenbank besser dran bist.

Mal so in dem Raum gestellt:

Code: Alles auswählen

1
2
3	SELECT * 
FROM tasks
WHERE (subject LIKE '%Geburtstag%')[code][/quote]

An sowas hatte ich auch gedacht. Nur, welche db soll ich verwenden?

tiax · Dienstag 12. Juni 2007, 20:48

sqlite, sonst musst du ja dauernd nen SQL-Server mitinstallieren. Abgesehen davon gibts ja auch gar keinen Anforderungen an die "großen" Datenbanken

gerold · Dienstag 12. Juni 2007, 21:06

schlangenbeschwörer hat geschrieben:Nur, welche db soll ich verwenden?

Hallo schlangenbeschwörer!

Das ist leider keine einfache Frage!

SQLite ist in Python mit dabei. Es ist klein und sauschnell. Es ist als Desktop-Datenbank mehr als ideal.

SQLite ist aber nur eine Datendatei die lokal auf dem Computer liegt. Wenn jemand auf die SQLite-Datenbank zugreifen möchte, dann braucht er direkten Dateizugriff auf die Datenbankdatei. Gleichzeitiges Lesen und Schreiben von mehreren Computern aus kannst du vergessen. Es gibt auch keine Rechteverwaltung. Wer die Datenbankdatei lesen kann, hat vollen Zugriff.

Das schließt ein Verwenden von SQLite aus, wenn du vor hast, Termine und ToDo-Einträge zentral zu verwalten.

Datenbanksysteme, die genau darauf ausgelegt sind, sind MySQL oder PostgreSQL. Der Nachteil: Diese Datenbanksysteme sind nicht mehr nur eine einzelne Datei, sondern müssen installiert werden und bestehen aus vielen hunderten von Dateien. MySQL oder PostgreSQL laufen als eigenständige Programme im Hintergrund (z.B. als Dienst). Sie können viel, sind aber komplizierter zu verteilen.

Mein Tipp:
Schreibe dir deinen ToDo-Planer für dich. Schreibe ihn so, dass er mit SQLite-Dateien arbeitet. Schreibe ihn so, dass du die SQLite-Dateien austauschen kannst oder sogar mehrere Datenbankdateien kombinieren kannst. So wie z.B. in Google-Calendar. Dort kann man mehrere Kalender (Ferientage in Tirol, Geburtstage, Urlaub, usw.) kombinieren. Sunbird verfolgt diese Strategie ebenfalls.
Die Entwicklung ist einfacher. Du kannst die Datenhaltung schrittweise verbessern.
Und wenn du die ToDo-Listen mit mehreren Personen teilen möchtest, dann lässt sich das auch nachher noch einbauen.

Es ist nämlich so, dass viele Projekte nie fertig gemacht werden. Der Grund ist sehr oft der, dass die Projekte **zu groß** geplant wurden. Irgendwann hat man nicht mehr so viel Zeit für das Projekt übrig und dann liegt ein halb fertiges Programm irgendwo in Sourceforge.Net rum.

Besser wäre es, wenn man eine Roadmap aufstellt und sehr klein beginnt. Z.B. so:
- Verwendung nur **einer** SQLite-Datenbank. Keine Auswahlmöglichkeit.
- Kommandozeilenprogramm als Hauptprogramm. Keine Kommandozeilenoberfläche. Nur eine Ausgabe von Einträgen über die Kommandozeile.
- Kommandozeilenparameter zum Hinzufügen von ToDo-Einträgen
- Kommandozeilenparameter zum Löschen von Einträgen
- Einfache GUI mit wxPython als zusätzliches Python-Modul
- GUI verbessern
- Auswahl von Datenbankdateien (Datei->Öffnen) einbauen.
- Zuletzt ausgewählte Datenbankdatei in INI-Datei speichern und als Standard-Datei für Kommandozeilenanweisungen verwenden.
- Zuletzt ausgewählte Datenbankdatei als Standard für die GUI verwenden.
- Einstellung: Immer zuletzt ausgewählte Datenbankdatei verwenden? --> in INI-Datei
- Einstellungsfenster für GUI.
- ...

Mit so einer Roadmap hast du schon nach kürzester Zeit ein funktionierendes Programm. Es ist egal, wenn du später keine Zeit mehr dafür hast. Du hast damit immer ein funktionierendes Programm. Auch wenn noch nicht alles so läuft, wie du es gerne hättest. Du kannst dieses Programm veröffentlichen und andere Programmierer können ihren Senf dazu abgeben. Vielleicht entwickelt es sich zu einem bekannten Programm. Mit deiner Vorarbeit.

Das alles ist **NICHT** möglich, wenn du dein Programm von Anfang an zu perfekt planst. Es macht keinen Spaß, an einem Programm ein Jahr lang zu programmieren, ohne dass man sieht wie es funktioniert. Das kann dir aber passieren, wenn du gleich von Anfang an alle Möglicheiten der Anwendung einschließen möchtest.

So, das war's für's erste.

mfg
Gerold

veers · Dienstag 12. Juni 2007, 23:31

Hm ich bin in vielen fällen Fan von einfachen Textfiles. Einfach, transparent. Integrieren sich Toll in meinen Desktop

Das Problem ist halt das sie nicht gut Skalieren, aber das dürfte bei einer Todo-Liste kein Problem sein.

Eine alternative wäre Pickle, das erlaubt dir deine Python Datenstrukturen in eine Datei zu Speichern und wieder auszulesen. Ist in vielen Fällen die einfachste Lösung.

XML mag ich persönlich nicht wirklich. Dass ich Beruflich mit XML schon meine Erfahrungen machen durfte

Und Datenbank hm... Overkill?

gerold · Mittwoch 13. Juni 2007, 06:54

Hallo schlangenbeschwörer!

Eine Sache habe ich noch vergessen. Eigentlich kommt es nur darauf an, was du lernen möchtest. Du brauchst als Programmierer das Wissen über Datenbanken genau so wie das Wissen über XML.

mfg
Gerold

BlackJack · Mittwoch 13. Juni 2007, 08:07

@veers: Skalierbarkeit ist kein Problem? Also meine ToDo-Liste wächst eigentlich nur, kleiner ist die noch nie geworden.

veers · Mittwoch 13. Juni 2007, 08:26

BlackJack hat geschrieben:@veers: Skalierbarkeit ist kein Problem? Also meine ToDo-Liste wächst eigentlich nur, kleiner ist die noch nie geworden.

Bis 1'000'000 Einträge dürfte das Problemlos sein, wenn deine Todo-Liste grösser ist hast du vermutlich andere Probleme

gerold · Mittwoch 13. Juni 2007, 08:40

veers hat geschrieben:Bis 1'000'000 Einträge dürfte das Problemlos sein, wenn deine Todo-Liste grösser ist hast du vermutlich andere Probleme

Hallo veers!

Ich zweifle jetzt mal deine praktische Erfahrung mit XML und diesen Datenmengen an.

Bis 2000/3000 Einträgen rechne ich mit wenig merkbarer Verzögerung beim Verwenden von XML. Da bleibt die Dateigröße noch im akzeptablen "ein paar Megabyte"-Bereich. Auch das Durchsuchen der eingelesenen Daten im Speicher dürfte da auch schnell genug sein. Ich spreche hier von Einträgen, wie sie für eine gute ToDo-Planung nötig sind. Das sind schon mal 300 oder mehr Bytes pro Datensatz.

Aber schon bei 50000/100000 Einträgen wird das, meiner ERFAHRUNG nach, unerträglich langsam. Das ist kein Problem, bei der Verwendung von XML als Datenaustauschformat, aber es ist ein Problem, wenn man während dem Arbeiten immer wieder ein paar Sekunden warten muss.

Du musst ja auch einplanen, dass bei jeder kleinen Änderung die gesamte Datei neu gespeichert wird. Eine Datenbank verwaltet die Daten meist in indizierten Speicherseiten oder wie auch immer. Auf jeden Fall muss bei einer gesunden Datenbank nicht die ganze Datei neu gespeichert werden.

So etwas lässt sich auch mit XML erreichen. Aber diesen Aufwand möchte ich niemandem antun.

mfg
Gerold

PS: Hier ging es mir nur um die Anzahl an Datensätzen. Das schließt auf keinen Fall aus, dass XML nicht ein geeignetes Datenformat zum Speichern von ToDo-Listen und Terminen ist.

Ich bin immer noch der Meinung, dass beides OK ist. Und der OP sollte nach Gefühl entscheiden, was er zuerst lernen möchte. XML oder Datenbanken.

veers · Mittwoch 13. Juni 2007, 09:16

gerold hat geschrieben:Ich zweifle jetzt mal deine praktische Erfahrung mit XML und diesen Datenmengen an.

Ich rede von Plaintext Files. Und gehe mal von 128 Byte pro Eintrag aus, dann hast du ein 128MB Plaintext File. Falls man Kategorien verwendet könnte man verschiedene Files verwenden, bei 8 Kategorien sind es dann noch hübsche 16 MB pro File. Das kann man noch Handeln, Sortieren nach mehreren Keys wird aber Definitiv aufwendig, ja. Auch sind die 1'000'000 Einträge das derzeitige obere Maximum. Vermutlich ist eine DB bereits bei 100'000 Einträgen die klar bessere Lösung. Nur wer hat überhaupt so viele Einträge?

gerold hat geschrieben: Bis 2000/3000 Einträgen rechne ich mit wenig merkbarer Verzögerung beim Verwenden von XML. Da bleibt die Dateigröße noch im akzeptablen "ein paar Megabyte"-Bereich. Auch das Durchsuchen der eingelesenen Daten im Speicher dürfte da auch schnell genug sein. Ich spreche hier von Einträgen, wie sie für eine gute ToDo-Planung nötig sind. Das sind schon mal 300 oder mehr Bytes pro Datensatz.

gerold hat geschrieben: Aber schon bei 50000/100000 Einträgen wird das, meiner ERFAHRUNG nach, unerträglich langsam. Das ist kein Problem, bei der Verwendung von XML als Datenaustauschformat, aber es ist ein Problem, wenn man während dem Arbeiten immer wieder ein paar Sekunden warten muss.

Mit XML Ja. Eventuell lässt sich das ganze per SAX noch relativ schnell Parsen und dann In Memory selbst verwalten.

gerold hat geschrieben: Du musst ja auch einplanen, dass bei jeder kleinen Änderung die gesamte Datei neu gespeichert wird. Eine Datenbank verwaltet die Daten meist in indizierten Speicherseiten oder wie auch immer. Auf jeden Fall muss bei einer gesunden Datenbank nicht die ganze Datei neu gespeichert werden.

Ist ein Problem, ja. Neue Einträge kann man jedoch auch hinten Anhängen oder in ein Journal schreiben und diese erst beim beenden der Anwendung speichern.

pyStyler · Mittwoch 13. Juni 2007, 10:43

Hallo,

also ich bin ein richtiger shelve Fan geworden. Eventuell ist es auch was für dich.
Gruss
pyStyler

schlangenbeschwörer · Mittwoch 13. Juni 2007, 13:40

Hallo!
Erstmal Danke an Gerold und die anderen für die vielen Antworten.
Ich denke, ich gucke mir mal SQLite an, denn es soll nur ein Programm für mich, bzw. für einen einzelnen Nutzer werden. Wenn man die gespeicherten Daten dann noch übertragen/exportieren kann, wär das natürlich super.
Zu mehreren Datenbankdateien: Reicht es nicht, eine Db zu haben, und darin alles in Tabellen zu organisieren? Ich weiß nicht, was besser ist, da ich wohl pro "Topic" mehrere Tabellen brauche. Jeweils ne neue Db anlengen, oder die entsprechenden Tabellen mit ner Vorsilbe. Aber das wird sich noch zeigen, ich muss mich eh erstmal mehr einlesen...

gerold hat geschrieben:Einfache GUI mit wxPython als zusätzliches Python-Modul

Aber ich darfs auch mit Tkinter machen, oder?

Ich schau erstmal und verschaff mir einen Überbilck, dann melde ich mich bestimmt noch mal.

Gruß, jj

Y0Gi · Mittwoch 13. Juni 2007, 14:15

Einen wesentlichen Vorteil von Lösungen mit ``shelve`` sehe ich darin, dass man sich nicht extra SQL bedienen muss und gar keinen Grund hat, das möglicherweise noch per ORM zu mappen. Wenn man direkt Python-Objekte hat, bedarf es keiner Konvertierung und man kann dann direkt in Python - möglicherweise weit flexiblere, schnellere, angepasstere - Suchalgorithmen schreiben. Wie sich der Lookup in einem Hash (dict) gegenüber einer indizierten Datenbank-Tabelle verhält, kann ich so nicht sagen - ersteres hat aber massiv weniger Overhead und ist vermutlich auch sonst so gut optimiert, dass man da keine Verluste macht.

Mich interessiert da, ob es überhaupt Sinn macht, zur Zwischenspeicherung Plaintext-Formate wie XML, YAML, JSON heranzuziehen. Da kann man wahrscheinlich besser direkt sowas wie ``shelve`` oder ZODB verwenden und erstgenannte Formate nur als Export anbieten, da letztere für den schnellen Zugriff weitaus besser optimiert sein sollten.

BlackJack · Mittwoch 13. Juni 2007, 14:15

Wenn die Kategorien flexibel sein sollen, würde ich alles in eine Tabelle mit einer Spalte "Kategorie" speichern. Solche dynamischen Informationen gehören IMHO nicht in den Tabellennamen. Einzelne Kategorien abfragen, oder nach Kategorien gruppieren, geht dann mit SQL ja relativ einfach.