Adressbuch: Was passt?

[everdream]

Hallo,
mein nächstes Projekt soll ein kleines Adressbuch werden. Über die Funktionen habe ich mir schon einige Gedanken gemacht, allerdings bin ich bei einer wichtigen Frage noch zu keinem Ergebnis gekommen:

Wie soll ich die Daten verwalten und speichern? :gruebel:

Eine Datenbank wäre natürlich eine Lösung, aber für meine Zwecke ist mir das fast schon zu viel. Darum hatte ich überlegt, ob ich zur Verwaltung eine Klasse (z.B. TEintrag) benutze, die dann in einer Liste gespeichert wird. Zum speichern hatte ich eine Idee, on der ich selbst noch nich so ganz überzeugt bin: Man könnte ja das Alphabet je Eingabefeld begrenzen: bei Namen nur Buchstaben (UPPERCASE), bei Telefonnummern nur Ziffern,...
Dann könnte man mit einer Art Kodierer das ganze Bitweise in eine Datei packen. Damit könnte man den Speicherbedarf pro Zeichen (bei Text) von 8bit auf 5-6bit verringern. Aber das (de)kodieren würde wohl bei größeren Datensammlungen ewig dauern...
Mir ist klar, dass Datenbanken z.T. auch mit Bäumen usw. arbeiten und generell effektiver sind als z.B. eine Liste, aber ich hab Spaß am selber bauen ^_^

Wie ihr vielleicht bemerkt habt, versuche ich das ganze möglichst klein zu halten. Nun meine Frage an euch:

Was würdet ihr mir zum Verwaltung und vor allem zum Speichern der Daten empfehlen?
Habt ihr Tipps eine kleine Datenbank betreffend? Glaubt ihr, dass sich eine Mehtode wie oben beschrieben vielleicht wenigstens in ASM "bewähren" könnte?

Vielen Dank schonmal für die Antworten ^.^

[busybyte]

Dein Ansatz ist mir nicht klar,Du willst keine Datenbanken aber eine kleine Datenbank.

Zitat:

Eine Datenbank wäre natürlich eine Lösung, aber für meine Zwecke ist mir das fast schon zu viel.

Zitat:

Habt ihr Tipps eine kleine Datenbank betreffend?

Du willst die Daten komprimieren mit einem Verfahren das wohl einmalig sein wird und Du willst den Benutzer zu gravierenden Beschränkungen bei der Eingabe zwingen um Speicherplatz zu sparen?

[everdream]

Ich weiß ja noch nicht, was ich nehme, darum frage ich ja. Ich möchte Argumente für und wider sowie Vorschläge haben.

Mein... "Verfahren" beschränkt den Nutzer zwar, aber ich finde es auch nicht grade Notwendig ihm die Eingabe von "²³}(%&%&" beim Namen zu ermöglichen. So gesehen komprimiere ich die Daten ja auch nicht.

[busybyte]

Ich habe mit den BDE-Datenbanktools angefangen und mich dann zu den SQL-fähigen DB's durchgewurschtelt.
Spätestens bei der Such- und Sortierfunktion wirst Du um SQL kaum herumkommen.
Am Besten gleich SQL,da BDE veraltet ist.

[everdream]

Von BDE habe ich vor allem gelesen, es sei groß.
SQL kenne ich nur von MySQL, Spielereien mit Homepages und so weiter.

Sortieren könnte ich das ganze ja über eine Liste (TList) und das Suchen sollte auch kein Problem sein. Da würde ich schon noch um eine Datenbank herum kommen...

[Hansa]

Zitat:

Zitat von everdream

...Da würde ich schon noch um eine Datenbank herum kommen...

Wie busybyte gesagt hat : dein Ansatz ist falsch. Zu dem zitierten Satz sage ich dazu noch : das ist alles Quatsch. :mrgreen: Warum ? Weil der Aufwand, den du im Hinterkopf hast (keine DB) mehr Arbeit ist, als sich das Wissen mal eben anzueignen. Geht nicht von heute auf morgen, ist aber besser, als da ziel- und planlos rumzufuchteln. Im Endeffekt wird sogar Zeit gespart.

[Sir Rufo]

Hallo EverDream,

es gibt da schon eine Möglichkeit, wenn es nur eine kleine Anwendung werden soll und der Zugriff nur von einer Station aus erfolgt.

Ein TADOTable mit den Feldern definieren und dann die Daten mit LoadFromFile bzw. SaveToFile laden/speichern.

Die Einschränkungen:
- Die Daten werden zur Laufzeit dann komplett im Speicher gehalten
- Es kann nur von einer Station drauf zugeriffen werden

Ansonsten hat man über den Filter von der Komponente auch die (beschränkte) Möglichkeit wie mit SQL darauf zuzugreifen.

cu

Oliver

[RSF]

Hallo,
Ich verwende als Datenbank „Advantage Database“ von Extended Systems.
Vorteile:
- Hohe Performance
- kein Admin aufwand (einfache Weitergabe der Programme)
- Einfache Implementierung (Delphi Package)
- Skalierbar (Local, Client/Server, Internet)
- Local Kostenlos
www.advantagedatabase.com

MfG

[Luckie]

Also für so eine kleine Adressdatenbank, finde ich, ist eine XML-Datei völlig ausreichend.

[s.h.a.r.k]

Wenn du vielleicht etwas mehr (liegt wohl im Auge des Betrachters ;) ) haben willst, dann kannst dir auch mal SQLite anschauen. Evtl. ist es etwas überdimensioniert, aber ich weiß nicht, was du evtl. morgen schon alles mit deinem Programm machen willst.

An dieser Stelle hast halt dann das Problem mit dem Speicherplatz, den du nicht wirklich "unter Kontrolle" hast, was du ja eigentlich willst.

@Luckie:
Eines der besten Methoden wird wahrlich XML sein, da du dieses Format eben auch leicht portieren und in Excel etc. bearbeiten kannst.

[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.

[everdream]

So, nun habe ich wieder etwas mehr Zeit.

Ich habe mich mittlerweile dazu entschlossen, eine Datenbank zu nutzen. Eine Funktion zum ver- und entschlüsseln der Daten kann ich ja später immernoch einbauen. Beim erweitern des Projektes werde ich es damit wohl wirklich einfacher haben.

Ich werde jetzt erstmal weiter die Details planen (Welche Felder, GUI, etc.).

Falls jemand noch Informationen zu Datenbanken hat (vor allem solche, die man als Anfänger gebrauchen kann): Ich bin dankbar für jeden Link und jedes Tutorial. Leider habe ich die Funktionsweise der Objekte (wie z.B. den TADOTables usw.) noch nicht ergründen können. Ich weiß einfach nicht, was womit anzufangen ist und wie ich es anfange. :wall:

Vielen Dank schonmal!