Brauche kleine aber feine Lösung ;)

[EnTeQuAk]

So... ich bastel gerade an einem Portal-System (im Internet).

Dieses bekommt nun eine Schnittstelle, um Daten lokal verwalten zu können und bei gefallen einfach hochladen zu können.

Dieses Lokale "Verwaltungssystem" soll jedoch möglichst portabel sein und sämtliche Daten speichern können.

Ich dachte dort erst an einen DatenbankWrapper wie SQLAlchemy... aber selbst da wird mind. ein Datenbanksystem vorausgesetzt.

Dann dachte ich weiter, an Pickle... hier mit kann ich, wenn ich richtig informiert bin Objekte abspeichern und wieder auslesen.
hört sich schonmal interessant an, da auch direkt integriert und keine weiteren Vorraussetzungen.

Dann habe ich die Dokumentation weiter gelesen... **shelve** habe ich nun gefunden.
Das bietet mir ja eine Dictionary-Artige Schnittstelle zu der "miniDB"...

Habt ihr dort erfahrungen, könnt ihr Tipps geben? --

Es sollten jedenfalls Lösungen sein, die möglichst keine Systemvorraussetzungen (außer python) haben und eben mitlieferbar sind bzw. direkt in Python integriert sind.


MfG EnTeQuAk

[gerold]

Dieses bekommt nun eine Schnittstelle, um Daten lokal verwalten zu können und bei gefallen einfach hochladen zu können.

Hi EnTeQuAk!

- Welche Arten von Daten?
- Wie groß und wie viel?
- Sprichst du von "Dateien" oder von Daten, die nicht im Dateisystem als Datei liegen?
- Wird öfter etwas hochgeladen oder öfter nach etwas gesucht oder hält sich das die Waage?
- Wie findest du die Daten wieder? Eindeutiger Dateiname/ID oder soll auch der Inhalt durchsucht werden können, um die Daten zu finden?

mfg
Gerold

[EnTeQuAk]

- Welche Arten von Daten?

im Moment sind es nur Daten über Newseinträge.
Author, Content, Datum, Überschrift.

- Wie groß und wie viel?

Da pro Newseintrag später eine neue Datei (news1.txt) angelegt wird... recht klein. jedoch bei vielen News können schon einige hinzukommen.
Ich rechne so mit... max. 50 Dateien.

- Sprichst du von "Dateien" oder von Daten, die nicht im Dateisystem als Datei liegen?

Die Daten werden von **Dateien** geholt. Hier überlege ich noch... immo wird es so gemacht, das es eine "Index.txt" gibt... in dieser sind zu jeder News Autor, Headline, Datum und angelegte newsX.txt enthalten.
Dank dieser Informationen können die einzelnen Newsdateien ausgelesen werden und somit angezeigt werden

- Wird öfter etwas hochgeladen oder öfter nach etwas gesucht oder hält sich das die Waage?

Es läuft so ab:
- Programm (lokal) wird gestartet
- Programm ruft aktuelle Newsliste herunter
- Programm lädt eventuell fehlende News herunter
- Programm beendet die Verbindung

Nun können News bearbeitet werden, neue News geschrieben werden und bei gefallen wird alles einfach wieder hochgeladen.

- Wie findest du die Daten wieder? Eindeutiger Dateiname/ID oder soll auch der Inhalt durchsucht werden können, um die Daten zu finden?

Eindeutiger Dateiname.

z.B.
news(ID).txt

also news1.txt, news2.txt, news3.txt usw...



Das Ist das momentane System. Das wollte ich gerne mit einer Art Datenbank vereinfachen... sodass entweder nur noch die Datenbankdatei (wie bei SQLite oder bei ge*Pickle*ten Dateien) herunterladen brauche und dort alles drinne steht.

Und da überlege ich, ob es da etwas gibt, was nicht MySQL, SQLite, PostgreSQL usw. heißt und nicht installiert werden muss.


MfG EnTeQuAk

[gerold]

im Moment sind es nur Daten über Newseinträge. Author, Content, Datum, Überschrift.
[...]
Ich rechne so mit... max. 50 Dateien.
[...]
Es läuft so ab:
- Programm (lokal) wird gestartet
- Programm ruft aktuelle Newsliste herunter
- Programm lädt eventuell fehlende News herunter
- Programm beendet die Verbindung
Nun können News bearbeitet werden, neue News geschrieben werden und bei gefallen wird alles einfach wieder hochgeladen.

Hi EnTeQuAk!

Bei so wenig Dateien/Daten brauchst du sicher keine Datenbank. -- Auch wenn es mal 100 Seiten werden sollten.
Das Durchsuchen aller Dateien wird kaum mehr Zeit beanspruchen, als eine Datenbankabfrage, denn eine Datenbankabfrage hat immer einen gewissen Overhead, der sich erst dann rentiert, wenn man mit vielen Daten und verschiedensten Suchanfragen arbeitet.

Ich empfehle dir eine durchdachte Ordner-/Dateistruktur zu verwenden. Dann empfehle ich dir auch noch, reine Textdateien zu verwenden. Damit können andere Programmierer auf dein System aufbauen und z.B. WYSIWYG-Editoren direkt auf die HTML-Dateien zugreifen lassen. Genau aus diesem Grund, empfehle ich auch, die Metadaten von den HTML-Seiten (=Content) zu trennen.

Ich würde sogar so weit gehen, dass die HTML-Seiten gültiges HTML mit HEAD und BODY sein müssen. Damit eröffnest du dir die Möglichkeit, die Dateien auch ohne dein Programm zu bearbeiten. Dein Programm überträgt dann die Änderungen wieder zum Server.

Hier ein Vorschlag von mir:

Code: Alles auswählen

data/
  |- local_settings.ini (oder .xml)
  |
  |- website_gerolds_blog/
  |    |- site_settings.xml (z.B. für die Generierung eines Menüs)
  |    |- pages/
  |         |- index.xml
  |         |- index.html
  |         |- firmenprofil.xml
  |         |- firmenprofil.html
  |         |- kontakt.xml
  |         |- kontakt.html
  |
  |- website_bernhards_firmenhomepage/
  |    |- site_settings.xml (z.B. für die Generierung eines Menüs)
  |    |- pages/
  |         |- index.xml
  |         |- index.html
  |         |- hallo_welt.xml
  |         |- hallo_welt.html
  |         |- kontakt.xml
  |         |- kontakt.html

In den XML-Dateien sind die Metadaten (Autor, Titel, Stichworte, Erstellzeitpunkt, Letzer Änderungszeitpunkt, History, usw.). Da diese Metadaten vom Content getrennt sind, kann jeder beliebige HTML-Editor mit dem Content arbeiten. Beim Übertragen wird dann nur der Body übertragen.

Zur Übertragung bietet sich z.B. XMLRPC an.

mfg
Gerold

[EnTeQuAk]

Das wäre so in etwa eine Struktur, die ich auch mit dauCMS anstrebe...


Aber darum geht es weniger.

Ich habe ansich wirklich nur ein reines Newssystem. Und mir geht es um die Verwaltung der News.


Also du bist der Meinung, die Newsdateien komplett als TXT zu speichern? -- Was spricht gegen die Verwaltung mit 'shelve'? -- Oder gibt es dort auch schon einen Overhead?


Ich werde das ganze dann wohl nochmal überdenken und ein wenig umstrukturieren.


Danke schonmal im Vorraus!

MFG EnTEQuAk

[gerold]

Also du bist der Meinung, die Newsdateien komplett als TXT zu speichern? -- Was spricht gegen die Verwaltung mit 'shelve'? -- Oder gibt es dort auch schon einen Overhead?

Hi EnTEQuAk!

Gegen Shelve spricht nur, dass es ein binäres Datenformat ist, auf das du normalerweise nur mit Python zugreifen kannst. Du versperrst dir dadurch evt. die Erweiterbarkeit deines Programmes.

Der Overhead ist bei so wenig Daten nicht beachtenswert. Aber vielleicht siehst du auch noch eine Möglichkeit vor, ein oder zwei Bilder oder sogar unendlich viele Bilder je Newseintrag zu ermöglichen. Das könntest du z.B. dann so Lösen, indem du jede Seite zusätzlich in einen Ordner stellst. Dann kann dein Tool alle zugehörigen Dateien hochladen.

Mit Dateien bist du nicht auf XMLRPC oder so etwas fixiert. Du könntest die Ordnerstruktur so wie sie ist z.B. per FTP hochladen lassen. Dann soll sich doch das Serverprogramm darum kümmern, dass nur der Body der HTML-Dateien verwendet wird.

Hier wieder ein Beispiel, wie ich mir das gedacht habe:

Code: Alles auswählen

data/
  |- local_settings.xml
  |
  |- website_gerolds_blog/
       |- site_settings.xml
       |
       |- pages/
            |- index/
            |    |- index.xml
            |    |- index.html
            |    |- banner.jpg
            |
            |- firmenprofil/
            |    |- firmenprofil.xml
            |    |- firmenprofil.html
            |    |- bild_der_firma.jpg
            |
            |- kontakt/
                 |- kontakt.xml
                 |- kontakt.html
                 |- kontakt_icon.gif

mfg
Gerold


Edit: Ordnerstruktur hinzugefügt.

[EnTeQuAk]

Hmm -- Oke... dann werde ich ma ein paar nächte drüber programmieren und mal schauen, was dabei herauskommt.


Herzlichen Dank, für deine Ideen, die du eingebracht hast.


Die Begründung, gegen 'shelve' ist natürlich angebracht. Verstehe ich schon.

Und wo wir gerade bei den Dateien sind. Wie perfomant ist es eigentlich jede Datei, die ich alslesen möchte einzeln mit

Code: Alles auswählen

def get_data(data_file):
    data_f = open(data_file, 'r')
    data = data_f.read()
    data_f.close()
    return data

"auszulesen". Gibt es dort bei riesigen Mengen (man weiß ja nie, was alles anfällt) an Daten -- oder wird das erst so ab zig-hunderten von Dateien spürbar?

MfG EnTeQuAk

[gerold]

Wie perfomant ist es eigentlich jede Datei, die ich alslesen möchte einzeln [...] "auszulesen".

Hi EnTeQuAk!

Probier es doch selber aus:

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: iso-8859-1 -*-

import os
from glob import glob
import random

DATADIR = "./datadir"


DUMMYTEXT = """
Ich bin der Dummytext.
Ich bin der Dummytext.
Ich bin der Dummytext.
Ich bin der Dummytext.
Ich bin der Dummytext."""


def create_files(count):
    
    for i in xrange(count):
        filename = os.path.join(DATADIR, "datafile_%i.txt" % i)
        f = file(filename, "w")
        f.write(DUMMYTEXT)
        f.close()
    
    # Datei markieren
    i = random.choice(range(count))
    f = file(os.path.join(DATADIR, "datafile_%i.txt" % i), "a")
    f.write("HALLO")
    f.close()


def search_in_files(word):
    
    filenames = glob(os.path.join(DATADIR, "*.txt"))
    
    for filename in filenames:
        f = file(filename, "r")
        try:
            for line in f:
                if word in line:
                    # gefunden
                    return filename
        finally:
            f.close()
    
    return None


def main():
    """Testen"""
    
    import timeit
    
    # Erstellen
    t = timeit.Timer("__main__.create_files(1000)", "import __main__")
    print t.timeit(1)
    
    # Nach dem Wort "HALLO" suchen und den zugehörigen Dateinamen ausgeben
    t = timeit.Timer(
        "print 'Datei gefunden:', __main__.search_in_files('HALLO')", "import __main__"
    )
    print t.timeit(1)
    
    print "Fertig!"


if __name__ == "__main__":
    
    main()

Ergebnis auf meinem Computer:

Code: Alles auswählen

0.516381338562
Datei gefunden: ./datadir\datafile_871.txt
0.220573242541
Fertig!

mfg
Gerold

[EnTeQuAk]

überzeugt... ich nehme es


Dann muss ich mir nun nur noch eine entsprechende Datenstruktur zusammenbasteln...


Was mir gerade so auffällt... eigentlich brauche ich doch an der Struktur meiner momentan laufenden Webanwendung kaum bis gar nichts ändern oder? :=)

Dort läuft ja immo alles auf Dateibasis...


Ich habe nur ein Problem, was mir gerade eben erst wieder einfällt.
Ich wollte eine simple Benutzerverwaltung machen.

Benutzergruppen, Benutzername, Password. Weiteres sollte eigentlich erstmal nicht gemacht werden.

Hier zweifle ich, das sich das recht einfach und sicher nur mit einfachen Text-Dateien umsetzen lässt.

Nun gut -- was heißt sicher.

Es könnte doch ansich möglich sein, mithilfe einer ganz simplen XML-Datei das ganze zu realisieren oder?

Code: Alles auswählen

<Benutzerverwaltung>
    <user id="1">
        <username>EnTeQuAk</username>
        <password>abfgaphbfgpafgbafgbaüb</password>
        <group>admin</group>
    </user>
</Benutzerverwaltung>

Das Password wird via md5-hash erstellt und fertig ist. DENN! Password-recovery brauch ich ja nicht

Ginge das?

Dann überlege ich. XML-Parsen. ist für so etwas extrem simples ElementTree das richtige? -- Ich habe damit schonmal versucht meine Anwendung zu schreiben... aber ich bin bei ElementTree nicht unbedingt weit gekommen.

Nun ja -- ich werde einfach mal ein paar Testanwendungen schreiben und schauen, was funktioniert und was nicht


MfG EnTeQuAk
<user

[Leonidas]

Dann überlege ich. XML-Parsen. ist für so etwas extrem simples ElementTree das richtige? -- Ich habe damit schonmal versucht meine Anwendung zu schreiben... aber ich bin bei ElementTree nicht unbedingt weit gekommen.

Ach, mit ElementTree ist das ein Klacks. Damit wird XML sogar halbwegs bequem, aber:

Some people, when confronted with a problem, think "I know, I'll use XML." Now they have two problems.

[EnTeQuAk]

kommen da noch die Probleme?


Ne ich werds mir ma alles nach und nach zu gemüte ziehen

[Leonidas]

kommen da noch die Probleme?

Es geht darum, dass man XML nicht nutzen sollte, weil es alle nutzen (Hypeware). Viele der Argumente für XML sind gar keine, bzw sind solche, die andere Dateiformate besser lösen. Es steht dir frei XML zu nutzen, jedoch solltest du bedenken, ob bei dir ein wirklicher Vorteil von XML zu tragen kommt oder ob du es nutzt, weil es cool ist XML zu nutzen.

[EnTeQuAk]

Es geht darum, dass man XML nicht nutzen sollte, weil es alle nutzen (Hypeware). Viele der Argumente für XML sind gar keine, bzw sind solche, die andere Dateiformate besser lösen. Es steht dir frei XML zu nutzen, jedoch solltest du bedenken, ob bei dir ein wirklicher Vorteil von XML zu tragen kommt oder ob du es nutzt, weil es cool ist XML zu nutzen.

Mir geht es 100%ig nicht darum, ob es cool ist oder nicht. sonst würd ich nicht so uncool das alte C++ lernen -- nun gut... es kommt auf dem Arbeitsmarkt wieder in Mode -- aber es wird wieder cool

Für mich ist XML eine reine Deklaration, von einer Strukturierten TXT-Datei. Mehr nicht. Sollte im Enddefekt extrem mehr drinne stecken lass ich mich belehren.
Aber für mich ist XML wirklich nur eine Art "Standard, zum strukturieren" ... nun gut --- das ist im Enddefekt jedes Dokmentformat. Aber egal
Ich hoffe, ihr wisst, was ich meine

Ich persönlich wende es nur an, weil ich nicht anders weiß, weil es für den menschen Lesbar ist und bestimmte Datenstrukturen auch von ihm geschrieben werden können.


Mitlerweile gebe ich mich aber mit einfachen strukturierten TXT-Dateien auch zufrieden :::---:::

[Leonidas]

Mir geht es 100%ig nicht darum, ob es cool ist oder nicht. sonst würd ich nicht so uncool das alte C++ lernen -- nun gut... es kommt auf dem Arbeitsmarkt wieder in Mode -- aber es wird wieder cool

Ach was, C++ ist durchaus "cool". Wenn Programmieranfänger (entweder Quereinsteiger aus "simpleren" Sprachen wie VB oder komplette Einsteiger) in der Buchhandlung vor dem Bücherregal stehen und überlegen was sie lernen wollen ist C++ immer noch eine häufige Wahl - trotz C# und Java. Die haben zwar beide versucht C/C++ von Thron zu werfen, allerdings ist der Anteil der Java und C#-Programme die sehr populär sind eher gering. Java hat in der XML-Nische einiges an Land gewonnen, aber selbst die Apache Foundation hat ihre Programme oftmals in einer Java und in einer C-Version (ich setze C nicht mit C++ gleich, möchte aber aufzeigen, dass beide Sprachen eine enorme Popularität besitzen). Daher erdreiste ich mich zu sagen, dass C++ "cool" ist - wer will schon Scheme, Haskell, Io, oder Python lernen? Die Sache ist die, dass das Argument "cool" rationale Entscheidungen uberschattet. Um ehrlich zu sein, habe ich selbst Python auch weniger Aufgrund der tollen Features ausgesucht - vielmehr hat mir Python gezeigt, dass die Dinge die Python bietet coole Features sind.

Somit ist eine Entscheidung vor dem Bücherregal aus Gründen der coolness eher zu vermeiden, denn die optimale Lösung kann ganz anders aussehen.

Für mich ist XML eine reine Deklaration, von einer Strukturierten TXT-Datei. Mehr nicht. Sollte im Enddefekt extrem mehr drinne stecken lass ich mich belehren.

Nein, eine XML-Datei ist eigentlich wesentlich mehr. Neben einer nicht gar so simplen Struktur wie man denken könnte, gibt es Ausnahmen aus dieser Struktur (CDATA) sowie viele Arten diese Struktur durchzusetzen (DTD, XSD, RELAX NG).

Aber für mich ist XML wirklich nur eine Art "Standard, zum strukturieren" ... nun gut --- das ist im Enddefekt jedes Dokmentformat. Aber egal
Ich hoffe, ihr wisst, was ich meine

Nein, XML ist weit mehr als das. Es ist zugegebenermaßen ein ziemlich geniales Austauschformat, welches mit DSSSL, XSLT, XML-FO auf eine vergleichsweise universelle und elegante weise in andere Formate überführt werden kann. Vergleichsweise darum, weil ich persönlisch das schreiben von XSLT-Dateien als vergleichsweise unangenehm empfinde.

Ein Beispiel: Die Möglichkeit mittels XSLT aus einem standardkonformen RSS-Feed eine XHTML-Seite direkt im Browser zu rendern ist eine tolle Sache.

Ich persönlich wende es nur an, weil ich nicht anders weiß, weil es für den menschen Lesbar ist und bestimmte Datenstrukturen auch von ihm geschrieben werden können.

Das sind YAML oder INI-Dateien auch. Sie sind zwar nicht ganz so flexibel wie XML (darin ist XML in der Tat aufgrund der vielen dutzenden Standards für fast jeden Anwendungszweck ungeschlagen), aber für den Menschen wesentlich leichter zu editieren, wesentlich kürzer und erfordern von ihm viel weniger Verständniss ihres eigenen Formates.

[jens]

Es sollten jedenfalls Lösungen sein, die möglichst keine Systemvorraussetzungen (außer python) haben und eben mitlieferbar sind bzw. direkt in Python integriert sind.

Sag mal, warum nutzt du nicht einfach SQlite? Ist bei Python ab 2.5 dabei.
IMHO bist du auf den Weg eine eigene DB mit XML zu programmieren...

[gerold]

Sag mal, warum nutzt du nicht einfach SQlite? Ist bei Python ab 2.5 dabei. IMHO bist du auf den Weg eine eigene DB mit XML zu programmieren...

Hi Jens!

Ich sehe das anders. Es macht keinen Sinn, Daten in eine Datenbank zu kapseln, wenn nicht nach strukturierten Daten gesucht werden soll. Der Vorteil bei einer Datenbank ist, dass wenig Daten aus vielen Daten schnell gefunden werden können. Es handelt sich weder um viele Daten, noch müssen diese einzeln schnell gefunden werden. Dann kommen evt. noch Bilder dazu. Das sind alles Dinge, die in einer Datenbank nichts zu suchen haben. Dann müssen alle Daten aus der Datenbank wieder raus, wenn die Änderungen zum Server hochgeladen werden sollen. Warum nicht gleich alles in einzelnen Dateien verwalten und dann per FTP hochladen.

Wenn alles in einer Datenbank ist, dann müssen die einzelnen Daten wieder raus genommen werden, wenn diese von einem Fremdprogramm bearbeitet werden sollen. Wenn die HTML-Strings als Dateien vorliegen, dann kann jedes Programm direkt darauf zugreifen. So lässt sich das Programm sehr leicht erweitern.

XML ist ein anerkannter Standard für den Datenaustausch. Es gibt keine erfolgreiche Programmiersprache auf dieser Welt, mit der man nicht XML parsen, erstellen, umwandeln oder validieren könnte. XML wurde nun mal dazu ausgewählt, das Universal-Datenaustauschformat zu sein. Es gibt natürlich auch einfachere Formate. Aber du suchst vergeblich z.B. nach einen YAML- oder JSON-Parser für Visual Basic 6. INI ist grade mal so drinn, wenn du die Windows-API (z.B. ``GetPrivateProfileString``) heran ziehst.

Außerdem lässt sich mit ElementTree XML wirklich einfach erstellen und auch wieder auslesen. Ich weiß noch, wie schwer es mit Visual Basic 6 war. ElementTree ist ab Python 2.5 mit dabei. Es lässt sich auch ohne Probleme mit cx_freeze oder py2exe in das zu verteilende Programmpaket einpacken. OK, das ist bei SQLite auch so einfach.

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: iso-8859-1 -*-

import elementtree.ElementTree as et


#----------------------------------------
# Schreiben
#----------------------------------------
# Root-Tag
root_tag = et.Element("ROOT")

# Files-Tag
files_tag = et.SubElement(root_tag, "FILES")

# Mehrere Files
file_tag = et.SubElement(files_tag, "FILE")
file_tag.set("name", "dateiname1.txt")
file_tag = et.SubElement(files_tag, "FILE")
file_tag.set("name", "dateiname2.txt")
file_tag = et.SubElement(files_tag, "FILE")
file_tag.set("name", "dateiname3.txt")
file_tag.text = "Hallo Welt"

# Speichern
f = file("test.xml", "w")
etree = et.ElementTree(root_tag)
etree.write(f, "iso-8859-1")
f.close()


#----------------------------------------
# Lesen
#----------------------------------------
f = file("test.xml", "r")
etree = et.parse(f)
f.close()
root_tag = etree.getroot()
files_tag = root_tag.find("FILES")
if files_tag:
    for file_tag in files_tag.findall("FILE"):
        print file_tag.get("name")
        print "  " + (file_tag.text or "")

lg
Gerold

[EnTeQuAk]

Wie gesagt. Ich benötige etwas, was möglichst NICHT an irgentwelche Installationen gebunden ist.

Es soll möglichst portabel sein. Das ist mein Hauptgrund, weswegen ich gerne auf die "normalen" Datenbanken verzichten würde.


Und so lange ich in meine "Datenbankinterpretation" (was ich noch lang nicht so bezeichnen würde) nicht auch noch SQL als Verbindungssprache benutze find ich das schon i.o

Des weiteren zieht bei mir das Argument, das es in Python 2.5 drinne ist nicht so ganz -- erst, wenn du mir den ersten Hoster zeigst, der das anbietet :'(


Also um möglichst Portabel zu sein ist eine kleine sehr abgespeckte selbst "entwickelte" Lösung schon nicht schlecht.


Ich werde mal schaun, was ich so hinbekomme.


MfG EnTeQuAk


EDIT: da war Gerold schneller -- schaut übrigens gut aus, dein Script'chen' Danke!

[jens]

Des weiteren zieht bei mir das Argument, das es in Python 2.5 drinne ist nicht so ganz -- erst, wenn du mir den ersten Hoster zeigst, der das anbietet :'(

Dann müsstest du allerdings auch auf ElementTree verzichten...

[EnTeQuAk]

Wobei ElementTree einfach ein Modul ist, das ich meinem Programm beipacken kann. Ich rede nicht von den python-SQLite Modulen 'pqsqlite' usw. ich muss doch (wenn ich nicht komplett falsch liege) auch SQLite ansich installieren (genau wie bei MySQL und PostgreSQL)...


MfG EnTeQuAk

[gerold]

...fast hätte ich es vergessen.

ElementTree ist eine reine Python-Lösung. Es ist also einfach nur der Ordner "elementtree" mit in das Programm aufzunehmen. Keine Installation nötig.

lg
Gerold


Edit: OK, das wusstest du schon.