Adressbuch: Was passt?

[guidok]

Hier gibt es auch ein Tutorial zu einer einfachen DB mit einer XML Datei.

[franktron]

Wenn du wirklich Delphi 2005 Personal hast wie in deinem Profil angegeben dann kannst du sowieso nur Text Datein nehmen,
oder XML oder MySQL mit der MySQL.Pas die es hier irgendwo im Forum gibt.

Weil du kein TDataset hats und somit alle Datenbank-Kombos Flachfallen

[everdream]

Okay, vielen Dank für die Antworten und Hinweise. Ich werde mir das jetzt erstmal alles angucken.

[3_of_8]

Zur Bitreduktion kannst du eine Huffman-Kodierung verwenden. Das ganze kombiniert mit Ersetzung von mehrmals vorkommenden Zeichenfolgen, und du hast eine Deflate-Kodierung. Nicht das effizienteste, aber noch vernünftig schnell.

[haentschman]

Hallo alle...

Meine Meinung:

1. wenn du ein neues Projekt anfängst...ohne BDE :thumb:
2. Deinen Eifer in allen Ehren, alles selbst speichern zu wollen.

Zitat:

was du evtl. morgen schon alles mit deinem Programm machen willst.

- Dein Programm wird mit deinen Ideen wachsen... :wink:
- schnell wirst du vieleicht Grenzen erreichen.
- die Daten zu speichern ist die eine Sache. Was du mit den Daten dann anstellst die andere. In diesem Zusammenhang kann ich dir nur SQL ans Herz legen.
3. mein Vorschlag für den Anfang: eine Embedded Datenbank wie zum Beispiel Firebird Embedded. Es gibt in dieser Richtung noch viel mehr.Schon viel diskutiert.
ein Beispiel
- ausschlaggebend ist, womit du am besten zurecht kommst... :P

[everdream]

Zitat:

Zitat von 3_of_8

Huffman-Kodierung/Deflate-Kodierung

Huffman habe ich schonmal in der Schule gemacht, da mussten wir einen Morsebaum erstellen... Daran hatte ich mich in dem Zusammenhang auch schon erinnert. Häufige Zeichenfolgen als "einen Buchstaben im Alphabet" zu sehen (z.B. bei "en") hatte ich auch schon überlegt.

WENN ich das ganze so angehe, dass ich die Dateien Bit für Bit selbst erstelle, dann würde ich die Daten allerdings während der gesammten Laufzeit in Form von Objekten (eben z.B TEintrag) im Speicher haben, denn was anderes ist mir da noch nicht eingefallen.

WENN ich mich für eine Datenbank entscheide, hätte ich natürlich viel weniger zu machen, dafür aber mehr zu lernen. Für mein Studium (Wirtschaftsinformatik, ab Oktober) wäre eine Datenbank wohl die bessere Entscheidung...

(Ich merke grade, dass mein Verstand gegen mich arbeitet. )

An der DIY-Methode finde ich ja am schönsten, dass man mit den Dateien absolut nichts anfangen kann, wenn man das zugehörige Programm nicht hat. Zumindest gehe ich davon aus, dass man das nicht kann... Ich könnte 2 Versionen schreiben, eine mit DB und eine mit dem Bitgepuzzle, aber dafür habe ich definitiv zu wenig Motivation.

Zitat:

Dein Programm wird mit deinen Ideen wachsen...

Ja, die Ideen sind schon ganz schön groß :roll:

Zitat:

die Daten zu speichern ist die eine Sache. Was du mit den Daten dann anstellst die andere. In diesem Zusammenhang kann ich dir nur SQL ans Herz legen.

Du meinst die Daten in meinem Bitpuzzle speichern, beim Programmstart umwandeln und dann nur zur Laufzeit in der (SQL)Datenbank verarbeiten?

[haentschman]

Hallo...

Zitat:

Du meinst die Daten in meinem Bitpuzzle speichern, beim Programmstart umwandeln und dann nur zur Laufzeit in der (SQL)Datenbank verarbeiten?

meinte ich eigentlich nicht...sondern die Daten gleich in einer Datenbank speichern welche mit SQL umgehen kann.
...macht es wesentlich einfacher. Stichwort Mehrbenutzer / Netzwerkzugriff :-D

Respekt vor Deinem Lernwillen aber ein Beispiel:

nimm eine SPS. Du gibst Informationen rein und entsprechend des Programmes kommen Informationen raus. Wie die SPS die Informationen / das Programm intern ablegt und verarbeitet ist für den Anwender uninterressant. Genauso ist es mit einer Datenbank. Du speicherst Informationen und rufst Informationen ab. Wie die Datenbank intern die Daten ablegt / speichert ist für den Anwender genauso uninterressant.

Ich finde du ersparst dir in Zukunft eine Menge Probleme beim Datenzugriff wenn Du gleich ein DBMS verwendest.
Muß ja nicht gleich ein Riese sein... :-D

Zitat:

WENN ich mich für eine Datenbank entscheide, hätte ich natürlich viel weniger zu machen, dafür aber mehr zu lernen.

Meiner Meinung nach hättest du wesentlich mehr zu lernen wenn du deine Daten selbst speicherst (mit Kompression etc.) als dich in ein DBMS einzuarbeiten. SQL ist nun wirklich nicht schwer. Tips und Tricks findest du hier reichlich.

bis bald...

[everdream]

Zitat:

Zitat von haentschman

Zitat:

WENN ich mich für eine Datenbank entscheide, hätte ich natürlich viel weniger zu machen, dafür aber mehr zu lernen.

Meiner Meinung nach hättest du wesentlich mehr zu lernen wenn du deine Daten selbst speicherst (mit Kompression etc.) als dich in ein DBMS einzuarbeiten. SQL ist nun wirklich nicht schwer. Tips und Tricks findest du hier reichlich.

Zur Kompression hab ich mir aber schon genug Gedanken gemacht, sodass ich damit wohl anfangen könnte. Außerdem lerne ich lieber Kompressionsmethoden als Datenbankbenutzung, ist einfach interessanter. :wink:

Aber du hast schon recht. Mit einer Datenbank hätte ich wohl besser Ausgangsmöglichkeiten als mit einem selbstgeschriebenen (vermutlich verbuggten) Dateisystem. Ich habe mir mittlerweile mal die AbsoluteDB gezogen und SQL hab' ich mich auch schon angeguckt (aber noch nix hier local gemacht oder installiert).

[haentschman]

für SQL kann ich dir folgende Seite empfehlen...übersichtlich erklärt.

SQL Syntax

:hi:

[grenzgaenger]

wenn ich mir deinen beitrag so durchlese, so dachte ich zu erst an

serialisieren

damit verwaltest du deine objekte in einer liste (z. b. tlist) und beim laden/speichern serialisierst du deine objekte von/zur festplatte.

vorteil, keine datenbank nötig, bist rein im objektmodel, leicht zu implementieren und anzuwenden. nachteil, nur für singleuser.

eine andere möglichkeit wäre über

textfile

lesen schreiben, über readln/writeln oder .loadfrom/savetofile oder über spezielle komponenten wie z.b. XML

vorteil, einfache weiterbearbeitung, daten können auch mit anderen programmen geschrieben und ausgelesen werden. Nachteil, nur für singleuser, nicht im objektmodel.

die nächste möglichkeit wäre über eine

datenbank

. hier gibts prinzipjell zwei möglichkeiten (a) das objektmodell oder das relationale model. für beide varianten brauchst du datenbanken. wobei (a) dein objektmodel unterstützt und du bei (b) deine daten zerhacken musst.

vorteile: die datenbank kümmert sich um die daten (je nach art ist multi-/singleuser zugriff möglich). die verwaltung und die sicherstellung der daten kümmert sich die datenbank.

nachteil: teilweise sehr hohe lizenzkosten, und installationsaufwände.