qtforum.de

Hallo!

Ich möchte in einem Programm Telefonrechnungen (eine pro Monat) erfassen. Sie liegen als CSV-Dateien vor und sollen "irgendwie" eingelesen werden.

Dann sollen die Rechnungen (Datenfelder: Nummer, Dauer, Betrag) vom Benutzer gespeichert werden können, der Benutzer soll aber nichts davon mitbekommen. Das Programm soll das Speichern/Öffnen übernehmen.

Kann man sowas realisieren, ohne eine Datenbank zu verwenden? Beispielsweise fällt mir da XML (DOM) ein, aber wie lege ich dann das richtige Verzeichnis fest?

Ich könnte mir vorstellen, im Home-Verzeichnis in dem QSettings-Ordner einen Ordner "rechnungen" erstellen zu lassen, in dem dann die Rechnungen entweder pro Jahr in einem eigenen Ordner oder einfach alle da drin sind.

Gibt es eine Möglichkeit, so etwas zu realisieren?

Danke schonmal,
QMaddin

Mit QString QDir::homePath ermittelst du das Heim-Verzeichnis. Von hier aus kannst du dann tun und lassen was du willst, z.B. Verzeichnisse und Dateien anlegen (QDir::mkdir( const QString& )).
Der Übersichtlichkeit halber ist es sicher besser, pro Jahr ein Verzeichnis.
Wenn du dir noch ein passendes Verzeichnis (z.B. homePath()/teleProggie/data/2007 etc) überlegst, is scho a "G'mahde Wies'n".

Grüße
Franz

franzf hat geschrieben:Mit QString QDir::homePath ermittelst du das Heim-Verzeichnis. Von hier aus kannst du dann tun und lassen was du willst, z.B. Verzeichnisse und Dateien anlegen (QDir::mkdir( const QString& )).
Der Übersichtlichkeit halber ist es sicher besser, pro Jahr ein Verzeichnis.
Wenn du dir noch ein passendes Verzeichnis (z.B. homePath()/teleProggie/data/2007 etc) überlegst, is scho a "G'mahde Wies'n".

Damit dürfte ich das machen können, was ich mir vorgestellt habe. Danke!

Wie sieht es denn mit dem Dateiformat aus? Ich lese die CSV-Dateien ein und verarbeite sie. Danach möchte ich sie in eine Datei schreiben.

Es muss nicht mehr das CSV-Format sein. Ist eine XML-Datei eine bessere Wahl als eine binäre Datei? Im Moment tendiere ich zwecks des besseren Debuggens zu einer XML-Datei.
Der Sicherheitsaspekt spielt keine Rolle, denn der Benutzer, der das Programm starten darf, darf ja auch in sein Heim-Verzeichnis schreiben. Außerdem geht es nicht um Passwörter oder ähnliches.

Gibt es da sonst gravierende Unterschiede oder noch andere (dateibasierte) Möglichkeiten?

qmaddin hat geschrieben:Hallo!

Ich möchte in einem Programm Telefonrechnungen (eine pro Monat) erfassen. Sie liegen als CSV-Dateien vor und sollen "irgendwie" eingelesen werden.
Gibt es eine Möglichkeit, so etwas zu realisieren?
Danke schonmal,
QMaddin

Du kannst dass programm http://sourceforge.net/projects/qtexcel-xslt/ source anpassend ... einfach ein import dazuschreiben in deinen format....
der vorteil .... kanst dann als pdf formatiert ausgeben mit datum... und auch zu excel oder openoffice berechnen...

Danke!

Dieses Projekt schaue ich mir bei Gelgenheit mal an.

QMaddin

Ich würde kein Binärformat mehr verwenden. Speicherplatzprobleme gibt es heutzutage nicht mehr so und so kann die Daten vielleicht auch noch in 10 Jahren auswerten...

upsala hat geschrieben:Ich würde kein Binärformat mehr verwenden. (...)

Genau das habe ich mir auch gedacht.
Danke,
QMaddin

Ich würde kein Binärformat mehr verwenden. Speicherplatzprobleme gibt es heutzutage nicht mehr so und so kann die Daten vielleicht auch noch in 10 Jahren auswerten...

Also wenn der XML parser stundenlang zum parsen braucht ^^

Also es gibt durchaus noch anwendungsfaelle fuer mal binaer auf die pladde streamen, alles nur ne frage des umfangs.

Aber bei telefonlisten, wo man die daten zudem noch aus csv dateien bekommt, kann man da ganz schnell in den grenzbereich kommen. Telefonbuecher von der CD bekommt man ja sicherlich irgendwie ins excel format.

Ne alternative zum eigenen binaeren undefinierten Format waer ne speicherdatenbank, ala berkley db oder SqlLite. Die formate sind definiert und das zeugs ist meist ausreichends schnell ....

Ciao ...

RHBaum hat geschrieben:

Ich würde kein Binärformat mehr verwenden. Speicherplatzprobleme gibt es heutzutage nicht mehr so und so kann die Daten vielleicht auch noch in 10 Jahren auswerten...

Also wenn der XML parser stundenlang zum parsen braucht ^^
[...]
Aber bei telefonlisten, wo man die daten zudem noch aus csv dateien bekommt, kann man da ganz schnell in den grenzbereich kommen. Telefonbuecher von der CD bekommt man ja sicherlich irgendwie ins excel format.

Hier ein "kleines" SVG-Bildchen (~4,5 MB...). Wie lange rödelt bei dir Inkscape, um das zu öffnen? Bei mir nicht mal 2 Sekunden. Und mit simplen Verbindungsnachweisen wird er diese Grenze sicher nicht sprengen. (Eher weit darunter bleiben)

Auch der Qt-Designer verwendet für die *.ui XML. Und selbst bei richtig großen User-Interfaces merkt man beim Compilieren NULL Verzögerung.

Ich weiß nicht wie bei dir soooo viele Daten zusammenkommen können, dass XML diese nicht schnell genug laden kann.
Aber mit Sicherheit gibt es für XML diese Grenzen, wo du mit einer richtigen DB schneller dran bist. Diese wird er mit seinen Telefonlisten aber nicht so schnell erreichen.

Grüße
Franz

RHBaum hat geschrieben:Aber bei telefonlisten, wo man die daten zudem noch aus csv dateien bekommt, kann man da ganz schnell in den grenzbereich kommen. Telefonbuecher von der CD bekommt man ja sicherlich irgendwie ins excel format.

Pro Monat kommen ca. 30-40 Zeilen (=Einträge) zusammen. Die erste Spalte ist die Telefonummer, die zweite die Minuten des Gesprächs, die dritte ist der Geldbetrag. Die so zusammen kommenden Daten sollten pro Monat in einer XML-Datei durchaus handhabbar sein.

Vermutlich wird die erste Spalte ein String sein (Handynummern sind zeimlich lang und enthalten für die Lesbarkeit ein Leerzeichen), Betrag und Minuten werden wohl floats werden. Passt das?

RHBaum hat geschrieben:Ne alternative zum eigenen binaeren undefinierten Format waer ne speicherdatenbank, ala berkley db oder SqlLite. Die formate sind definiert und das zeugs ist meist ausreichends schnell

Ein wichtiges Kriterium für die Gestaltung ist für mich, dass es unter Windows wie Linux (und evtl. Mac) laufen können soll, ohne dass mit Extraarbeit ein Datenbankserver aufgesetzt werden muss. Wäre das Programm nur für mich, dann wäre es kein Problem, aber ich möchte nicht auf anderen Rechnern noch eine DB warten, absichern und ähnliches.

Danke,
QMaddin

SQLite wäre da ähnlich leicht zu handhaben wie XML. Du brauchst keine Benutzer zu verwalten, nur als Datenbank-Namen die Datei angeben, in der die SQLite die Daten speichern soll.
Hinzufügen und lesen von Daten ist ziemlich simpel. (Sicher einfacher als durch deinen XML-Tree zu wandern )
Wenn sich das Schema deiner XML-Dateien ändert, musst du die bereits Vorhandenen auch umschreiben, was mit SQL sicher leichter geht.

Als großen Vorteil von XML seh ich allerdings, dass man die Dateien "einfach mal so" anschauen und verstehen kann, notfalls auch selbst ändern, ohne Datenbankzugriffe, nur per Texteditor. Für SQLite musst du dir da immer extra ein Programm schreiben... (Oder einen DBManager öffnen).

Für so wenige Daten denke ich reicht aber XML zum Speichern der Daten allemal, also meine Empfehlung.

Naja, den Umfang der Daten sollt/muss er selber abschaetzen koennen.

XML ist fuer mich ne aehnliche modeerscheinung wie Java. Es ist in gewissen Problemen durchaus nuetzlich, es hat einen Overhaed, wird aber in der Praxis viel zu sehr "gehypt".

schaut euch mal das XML richtig an, ist das wirklich noch "gut lesbar" ?

In 99% der Felle wird das Zeug nur mit speziellen Programmen geschrieben und nur durch spezielle programme ausgewertet. Mit der Hand oder mit nem reinen XML editor wird maximal nur beim debuggen gearbeitet.

XML ist nicht selbsterklaerend. wenn man unterschiedliche Programme hat die daten per XML austauschen sollen, bringt xml nur Vorteile bei der definition der Zeichen und Wertetypen, die spezifikation fuer den rest faellt mindestens genau so umfangreich aus wie wenn man nen anderes format nimmt.

XML ist alles andere als performant.

Wir haben z.b. bei uns Datenbanken, auf die wir direkt mit unseren tools nicht zugreifen koennen.
Dafuer exportiert uns die Datenbankanwendung (von nem anderen SW hersteller) XML files. Diese XML files sind aber unspezifiziert, und aendern sich bei jeder Datenbank-version mit. Fazit, der Hersteller liefert wiederum ne eigene API mit, die auf nem XML parser aufsetzt. Wir wiederum muessen sicherstellen , das wir fuer das file die entsprechende API anziehen.
So nen XML extract ist um die 50 MB gross und dauert ca 3-5min beim parsen. Meine datenstrukturen die ich selber wegserialisiere sind ca. 0.5 MB (2 sek lesen udn schreiben).

Das mal als Beispiel wo man XML an der falschen stelle einsetzen kann ^^

Nicht falsch verstehen, XML macht schon sinn ... besonders im Umfeld von Web-Applikationen und wo man die Zeichencodierung braucht. Aber als config format, und Daten die man nie mit nem generischen browser anschauen will, halt ichs fuer ungeeignet.

zu SQLLite, zum Beispiel

- gibt es fuer Linux und windows definitiv, Mac sicher auch ... ob die dateien plattformkompatibel sind muesst ich schauen.
- Es gibt generische Browser, wo man sich die daten in Tabellenform anschauen kann, und auch bearbeiten
- es faellt fuer dich kein overhaed fuers einrichten der "DB" an, es ist filebasierend. Du bindest die Libs ein, nutzt die Api und als "Quelle" brauchst nur den dateinamen angeben.
- gut dokumentiert
- um faktor X schneller und kompakter wie XML

Sowas bietet sich immer dann wirklich an, wenn man groessere Datenmengen strukturiert anlegen will
Man mit nem Framework arbeitet, was SQL datenablage unterstuetz
Man nen austausch gegen nen richtiges RDBMS fuer spezielle kunden in der Hinterhand haben will ....

Am ende isses aber soweiso Deine Entscheidung. und bei kleineren mengen und wenn man öfters die Datenbestaende per hand fixxen will, und man vor allem schnellen haendiche uebernahme der Daten in andere Dokumente, besonders HTML / XML basierende, braucht, iss XML sicher ned die schlechteste Wahl.

Ciao ... [/quote]

RHBaum hat geschrieben:Wir haben z.b. bei uns Datenbanken, auf die wir direkt mit unseren tools nicht zugreifen koennen.
Dafuer exportiert uns die Datenbankanwendung (von nem anderen SW hersteller) XML files. Diese XML files sind aber unspezifiziert, und aendern sich bei jeder Datenbank-version mit. Fazit, der Hersteller liefert wiederum ne eigene API mit, die auf nem XML parser aufsetzt. Wir wiederum muessen sicherstellen , das wir fuer das file die entsprechende API anziehen.
So nen XML extract ist um die 50 MB gross und dauert ca 3-5min beim parsen. Meine datenstrukturen die ich selber wegserialisiere sind ca. 0.5 MB (2 sek lesen udn schreiben).

Das mal als Beispiel wo man XML an der falschen stelle einsetzen kann ^^

Dafür kann aber XML nix, das ist ein absolut übler Fehler! Wenn für eine simple Datenbank-Abfrage immer ein kompletter DB-Dump als XML zurückgeliefert wird, meine Fresse... Da kanns dir ja echt passieren, dass die eben erhaltenen Daten nicht mehr aktuell sind Und wie schreibt ihr dann auf diese Datenbank? XML-Datei manipulieren und wieder zurückschicken? ...

Aber im großen und ganzen geb ich dir Recht, bis auf das SQLLite was man nur mit einem L schreibt

Allerdings ist es in seinem Fall (wie du auch schon schreibst) sinnvoller, auf XML zurückzugreifen.

Wobei er sich auch eine abstrakte Klasse für die allgemeinen Befehle zum Einfügen und lesen seiner Daten anlegen kann, und davon abgeleitet Klassen für den Zugriff auf SQLite und XML. Dann per Config-Dialog aussuchen, welches der beiden Backends er jetzt verwenden will...

Grüße
Franz

Dafür kann aber XML nix, das ist ein absolut übler Fehler!

Das mein ich Ja, XML ist durchaus ne tolle sache, nur wird es oft "ueberbewertet", es "verkauft" sich gut, weil es eine Kompatiblitaet vorgaukelt, die es systembedingt gar ned hat. Es ist halt modern und nen Schlagwort bei allen Projektmanagern im IT bereich, die nich gern hinter die Kulissen schaun.

Ich sag nur ODF und OASIS, klingt alles toll. Einige dinge machen auch sinn, aber am Ende kommt fuer die User und entwickler ned viel bei rum.

Da kanns dir ja echt passieren, dass die eben erhaltenen Daten nicht mehr aktuell sind

Der ganze Prozess ist bisserl Komplizierter.
Die Datenbank selber wird von entwicklern gepflegt, dafuer gibts nen externes tool. DIe datenbank selber iss nen moloch, also ziemlich fett

Unsere tools brauchen die daten nur lesend. Direkt zugreifen duerfen wir ned, weil unsere tools 1. nicht nur im firmenumfeld, also mit möglicher anbindung an die DB benutzt werden. es zig hundert installationen unserer tools gibt, wuerden die drauf zugreifen, wuerd es zum kollaps kommen, auf der DB

Prozesstechnisch gibt es Entwicklungsstufen. und somit Freezes und Auslieferungen. Unsere Anwender bekommen auch nie wirklich aktuelle, sondern expliziet freigegebene Daten. Die aenderen sich nicht, und wenn dann soweiso nur lokal ^^

Ciao ...