Dateien erstellen beste methode??? Oder vllt doch eine DB

[snow]

Zitat:

Ein DBS lohnt sich ab dem zeitpunkt wo eine Suchanfrage länger als ein paar sekunden dauern würde oder man zuviele Abhängigkeiten zwischen den daten hat. Beides hier lang nicht gegeben.

Du denkst wohl das man auf einer modellbahn zeit hat??? Hat man aber nicht. Mann muss ser schnell bestimmte daten wie ist ein Block gerade belegt JA, NEIN wenn ja von wehm blablabla rausfinden. Auch muss man herausfinden welche decoderadresse hat LOK mit dem namen
"Inter-City-Express" Wird sie in einem Zug verwendet und in welchem block ist der zug und wann wird er Block xyz erreichen und wieder verlassen. Der zustand jeder weiche jedes Signals muss immer parrat sein um zusammenstöße zu vermeiden. Auf einer ganz großen anlage (Miniatur Wunderland oder auch einer anderen Show-anlage) kommen da schon ganz schöne mengen an daten zusammen.

MfG snow

[christian_u]

Dann würd ich leiber ne Typisierte Datei nehmen beim Datenbanksystem hast du schon Zeit fürs bauen der Anfrage und co verschwendet.
Die Anfrage selbst dauert auch etwas zu bearbeiten. Deine kleine Datei zu durchsuchen dauert bloß n paar ms. Das mit den Sekunden waren für mich Abgrenzungskriterien. Du wirst bei deinen 16000 Datensätzen nie mehr als 100ms brauchen um den entsprechenden Datensatz gefunden zu haben.

[dominikkv]

http://www.delphipraxis.net/internal...=742661#742661

[scrat1979]

Zitat von christian_u:

Zitat:

Natürlich würde es auch mit einer datei funktionieren, der Aufwand wäre aber um einiges höher.

Einen Datenbankserver aufzusetzen, sich in SQL einzuarbeiten und dann für n paar tausend Datensätze das über nen DB Server laufen zu lassen ist weniger Aufwand als ein File of Record mit 15 Zeilen Quelltext zu bedienen ? Ich weiss ja nicht ...

Zuerst mal möchte ich sagen, daß ich kein Gegner von typisierten Dateien bin! Aber:

15 Zeilen Quelltext scheinen mir aber ehrlich gesagt etwas zu optimistisch veranschlagt. Eine Einarbeitung in SQL ist meiner Meinung bei einer einfachen Datenbank sogar z.T. gar nicht notwenig. Ein paar Einstellungen und Filter im OI reicht fürs ERSTE aus. Vorteil: Durch Einarbeitung in SQL lässen sich SPÄTER auch komplizierte Abfragen erzeugen - sollte es notwenig werden. Und mal Hand aufs Herz: Simple SQL-Abfragen sind wirklich kein Problem, wenn man mal ein paar Stunden SELECT-Abfragen geübt hat (bezieht sich auf einfache Queries).

Zitat von christian_u:

@Snow bei ein paar tausend Datensätzen lohnt sich weder für eine Kundendatenbank noch ne Lokverwaltung ne Datenbank, und das Argument mit alles in einer Datei ... Du hast bei nem Datenbanksystem nie nur eine Datei. Du brauchst auch mehrere Tabellen wenn du z.b. TDbf nimmst was sicherlich noch das ökonomischste wäre brauchst du trotsdem eine Tabelle für Loks eine für Schienen usw. das kommt alles aufs selbe raus und warum soll deine Version 2 das Dateiformat plötzlich nicht mehr lesen können ?!

Was das angeht widerspreche ich: Absolute Database benutzt definitiv nur EINE Datenbankdatei. Natürlich braucht man verschieden Tabellen, aber je nach DBMS z.T. nur EINE Datei. FireBird speichert seine Datenbank auch in einer Datei ab (wobei ich nicht weiß, ob noch anderswo zusätzliche Dateien erzeugt werden...)
Was ist, wenn ich plötzlich ein zusätzliches Feld benötige? Bei einer DAtenbank lässt sich eine Tabelle einfach erweitern und den Source entsprechend leicht anpassen. Bei einer typisierten Datei müsste man das ganze Dateiformat in ein neues konvertieren , da sich ja auch die Record-Größe geändert hat (oder liege ich da falsch?).

Liebe Grüße,
SCRaT

[snow]

lässt sich eine datenbank nicht übersichtlicher ansprechen oder?

Bei einer datenbank lassen sich einträge doch besser überschreiben oder? Da es bei einer Datenbank doch keine Doppelten einträger geben kann oder???



Ich glaub ich bleib aber bei ner datenbank will mal was neues können??

Zitat:

Bei einer typisierten Datei müsste man das ganze Dateiformat in ein neues konvertieren , da sich ja auch die Record-Größe geändert hat (oder liege ich da falsch?).

ganz so schlimm ist es nicht. man kann seine datei ja wie ein Buch schreiben also mit kapitlen die einen klaren Anfang und ein klares Ende haben. trotzdem ist so etwas nacher sehr unübersichtlich und man kann die datei nur mit seinem programm öffnen nicht mit einem anderen Datenbank prgramm, wie etwa Microsoft Access.

MfG snow

[mkinzler]

Zitat:

lässt sich eine datenbank nicht übersichtlicher ansprechen oder?

Imho ja.

Zitat:

Bei einer datenbank lassen sich einträge doch besser überschreiben oder?

Ja.

Zitat:

Da es bei einer Datenbank doch keine Doppelten einträger geben kann oder???

Ja kann man so Einstellen, das doppelte Werte abgelehnt werden.

Zitat:

Bei einer typisierten Datei müsste man das ganze Dateiformat in ein neues konvertieren , da sich ja auch die Record-Größe geändert hat (oder liege ich da falsch?).

Bei Änderungen in den Daten und dem Schema muss die Datei neu geschrieben werden.

[christian_u]

Zitat:

5 Zeilen Quelltext scheinen mir aber ehrlich gesagt etwas zu optimistisch veranschlagt.

1 test = record
2 meinevariable : integer;
3 end;

4 var
5 f: file of test;
6 daten : test;

7 assignfile('test.dat');
8 rewrite(test);
9 write(f,daten);
10 closefile(f);

Mhm, optimistisch ?

Zitat:

Absolute Database benutzt definitiv nur EINE Datenbankdatei

Ja ja es gibt Datenbanksysteme mit nur einer Datei aber das ist die absoulute Minderheit die meissten machen eine Datei pro Index ind eine pro tabelle. Absoulute Database hab ich z.b. noch nie gehört mit Firebird hättest du mehr trumpfen können aber das ist haarspalterei.

Zitat:

Ich glaub ich bleib aber bei ner datenbank will mal was neues können??

Und so ein Spruch bei deinem ersten Pascal Projekt ...
Ne schon ok TDbf ist ganz ok für die Anwendung.

[mkinzler]

Zitat:

Ja ja es gibt Datenbanksysteme mit nur einer Datei aber das ist die absoulute Minderheit

Nein, die richtigen DBMS haben sehr oft nur eine Datei.

Zitat:

Mhm, optimistisch ?

es geht hier nicht nur um das einmalige Schreiben toter Daten, sondern um lebende Daten die einer gewissen Änderung unterworfen sind. Dann muss man die Daten nämlich auch im speicher verwalten (Liste, Baum, o.ä.).

Zitat:

Ne schon ok TDbf ist ganz ok für die Anwendung.

1. Ist dBase nicht gerade uptodate und 2. kann diese Komponente kein SQL.

[s-off]

Nimm eine lokale Datenbank. Wenn Du irgendwann das Schienensystem der Deutschen Bahn verwaltest, kommst Du mit Textdateien nicht weit

Damit fährst Du aus meiner Sicht in jedem Fall gut, egal, wieviele Datensätze Du hast. Du bist viel fexibler als bspw. mit typisierten Dateien.
Man entwickelt eine Software vorausschauend. Da ist es falsch, etwas zu behaupten wie 'Och, ich habe max. 16000 Datensätze. Diese Zahl wird aber nur theoretisch erreicht.' Niemand weiss, was kommen wird - auch wenn das Beispiel mit der Deutschen Bahn sicherlich Utopie ist
Und wenn Du Dich in das Thema DBs erstmal eingearbeitet hast, dann lässt sich das Prinzip sehr gut auf Folgeprojekte übertragen.

Meine Meinung: Investiere ruhig die Zeit (wenn Du sie hast), Dich mit Datenbanken auseinander zu setzen; Du wirst es später sicherlich nicht bereuen.

Zur Auswahl stehen einige, die sich lokal nutzen lassen:
Firebird
SQLite
dBase

Solltest Du zu dBase greifen, so empfehle ich Dir die ADS-Komponenten von ExtendedSystems.

Diverse Tutorials zu Firebird bzw. Links zu diesen findest Du hier im Forum.

Edit: Ich habe glatt vergessen, dass Du Lazarus benutzt; damit hätten sich der Einsatz der ADS-Komponenten glaube ich erübrigt. Mit den Turbo-Editionen funktionieren sie allerdings. Btw: Hast Du vor, Deine Gleissystem-Anwendung irgendwann auch nach Linux zu portieren?

[Angel4585]

Wäre XML keine Möglichkeit? Bei Delphi gibts wenn ich mich nicht täusche ne Komponente dafür, vllt gibts die bei Lazarus auch?

Allerdings wenn es mal mehr werden sollte würde ich auch eher eine Datenbank empfehlen. so viel aufwand ist es nicht eine MySQL-Server-Anwendung zu installieren und darauf zuzugreifen.