Speichern in Tabellenform

[VkPenguin]

Hallo zusammen,

ich habe eine Frage zum Speichern von Dateien. Ich bin bisher mit dem Speichern in Textdateien, Streams und Excel vertraut. Bei einem größeren Programm verwende ich momentan Excel, um meine Daten zu speichern und zu laden, da ich auch direkten Zugriff auf die Rohdaten außerhalb des Proramms benötige. Ich kann als die Parameter des Programms verändern, indem ich vor dem Start die Excel-Datei öffne und einfach editiere.

Soweit funktioniert alles gut, wie ich es mir vorgestellt habe, die Excel-Variante hat jedoch zwei Nachteile: Erstens ist sie sehr langsam im Laden/Speichern und zweitens muss auf dem PC Excel vorinstalliert sein.

Ich überlege nun, wie ich das ändern könnte. Da ich viele Tabellen im Programm benötige ist eine Speicherung in Form einer Textdatei viel zu unübersichtlich, um noch Zugriff zu haben.

Meine Idee ist nun, ein seperates Programm zu schreiben, dass nur eine große editierbare Stringgrid anzeigt, also quasi ein Pseudo-Excel. Dann könnte ich die Dateien normal abspeichern und hätte über das Zweitprogramm zugriff auf die Daten. Ich wüsste nur gerne: Meint ihr, das kann ich so machen oder gibt es da eine sinnvollere Technik? Vielen Dank!

[Sir Rufo]

Das was du da vorhast sieht (stark übertrieben) so aus:

Zum Speichern der Daten druckst du die Daten auf einem Papier aus. Um diese wieder zu lesen hast du einen Scanner, der das Papier einscannt und ein riesiges Hardwaregedöns mit Roboterarmen, die das Papier zwischen Drucker, Ablage und Scanner tauscht.

Hast du schon mal etwas von Datenbanken gehört? Die wurden genau dafür entwickelt!

[Uwe Raabe]

Zitat:

Zitat von Sir Rufo (Beitrag 1283896)

Hast du schon mal etwas von Datenbanken gehört? Die wurden genau dafür entwickelt!

Gerade, wo doch bei seiner Architect-Version auch das ERStudio dabei ist...

[p80286]

Abgesehen von Datenbanken....
wie wäre es mit CSV oder XML?

Gruß
K-H

[Sir Rufo]

Abgesehen von allem. wie wäre es mit einer Abstraction, wo es dann der Anwendung wiederum egal ist, wo und wie gespeichert wird. Damit wird dann konkret erst dieses komische Speicher-(ich weiß nicht wie ich es nennen soll, die Worte sind noch nicht erfunden) gekapselt und wenn das funktioniert, dann setzt man sich hin und schreibt etwas konkretes mit etwas vernünftigem.

Und wenn es dann in Zukunft irgendwas werden soll, dann wird das einfach geschrieben, der Anwendung untergejubelt und alles ist schick.

[BUG]

Lies dir mal die Seite über Application File Formats mit SQLite durch, da findest du einige Argumente. Das sollte mit fast jeder embedded Datenbank gehen ... aber ich mag SQLite :wink:

[VkPenguin]

Danke erstmal für eure Antworten!

Datenbanken sind natürlich das offensichtliche, an das man zuerst denkt, aber die kann man im allgemeinen doch nicht außerhalb der Laufzeit des Programms einfach so öffnen wie eine Excel Datei und reinschreiben oder sehe ich das falsch?

Werde mich aber auf jeden Fall mal damit beschäftigen, dankesehr.

[p80286]

So wie Du Excel oder einen Viewer oder Open Office brauchst um eine Excel-Datei anzuzeigen, so benötigst Du ein entsprechendes Programm um Dir Daten in einer Datenbank anzusehen.
Aber vielleicht solltest Du uns verraten, warum das notwendig ist. U.U. wären dann die bekannten Datenaustauschformate für Dich sinnvoll.

Gruß
K-H

[Perlsau]

Zitat:

Zitat von VkPenguin (Beitrag 1284109)

Datenbanken sind natürlich das offensichtliche, an das man zuerst denkt, aber die kann man im allgemeinen doch nicht außerhalb der Laufzeit des Programms einfach so öffnen wie eine Excel Datei und reinschreiben oder sehe ich das falsch?

Also eine Einfachst-Anwendung, um eine mehrspaltige Tabelle in einer Datenbank zu bearbeiten, schreibe ich dir in 2 Minuten: Datenbank-Connection, Query, DBGrid und fertig.

[mm1256]

Zitat:

aber die kann man im allgemeinen doch nicht außerhalb der Laufzeit des Programms einfach so öffnen wie eine Excel Datei und reinschreiben oder sehe ich das falsch?

Dann speichere doch die Daten als CSV-Datei, zum Anzeigen/Bearbeiten nimmst du ein DBGrid und als "Datenbank" die TkbmMemTable. Dann hast du alle Bedingungen erfüllt, die du brauchst, und es ist zudem kompakt.

[Sir Rufo]

Zitat:

Zitat von VkPenguin (Beitrag 1284109)

Danke erstmal für eure Antworten!

Datenbanken sind natürlich das offensichtliche, an das man zuerst denkt, aber die kann man im allgemeinen doch nicht außerhalb der Laufzeit des Programms einfach so öffnen wie eine Excel Datei und reinschreiben oder sehe ich das falsch?

Werde mich aber auf jeden Fall mal damit beschäftigen, dankesehr.

Du denkst darüber nach eine zweite Anwendung zu schreiben, die die Daten verwalten soll und jetzt störst du dich an was?

Du musst eine Anwendung öffnen um die Daten zu bearbeiten ... ja und bei Excel ist das anders?
Selbst bei einer Textdatei musst du eine Anwendung starten.

Oder stört dich die fehlende Automatik (Doppelklick auf die Datei)? ... Das kann man Windows beibringen.

Es gibt auch Anwendungen, die eine SQlite-Datenbank öffnen können.

[BUG]

Zitat:

Zitat von Sir Rufo (Beitrag 1284149)

Es gibt auch Anwendungen, die eine SQlite-Datenbank öffnen können.

Das ist ein wichtiger Punkt: Für Datenbanken gibt es schon mächtige Tools, mit denen man arbeiten kann.
Neben dem Ansehen und Editieren von Tabellen kannst du natürlich auch adhoc-Anfragen auswerten. Import/Export in verschiedene Formate sollte auch kein Problem sein.

Für SQLite kann man z.B. einfach ein Firefox-Addon benutzen. Oder eben eines der vielen anderen fertigen Tools.

[humbuck]

Zitat:

Zitat von VkPenguin (Beitrag 1284109)

Meine Idee ist nun, ein seperates Programm zu schreiben, dass nur eine große editierbare Stringgrid anzeigt, also quasi ein Pseudo-Excel. Dann könnte ich die Dateien normal abspeichern und hätte über das Zweitprogramm zugriff auf die Daten.

Also, ich weiß ja nicht, wie viel dir deine Zeit wert ist, aber ein solches Programm kannst du bei mir als lizensierte Version käuflich für 99 EUR erwerben.

Features u.a.
1)Zugriff und direkte Bearbeitung auf viele SQL-Server, Access, Excel
2)SQL-Basierende Datenmengen mit der Möglichkeit, diese direkt zu bearbeiten / manipulieren
3)Filter-, Such- u. Sortierfunktionen
4)Benutzerverwaltung: Sicherheit und Rechtevergabe auf Benutzerebene
5)Speicherbare unterschiedliche Datenquellen mit zugehörigen Datenmengen und wiederum zugehörigen Reports
6)Export in div. Formate: Excel, Open Office, PDF, XML, HTML u.a.
7)Direkter Mailversand auch als Serienmail (optional)
8)Generieren von eigenen Datenquellen (optional)
9)Programmierbar mit Zugriff auf alle Programmmodule (optional)

Interessiert?

[humbuck]

Ach ja, noch was:

netzwerktauglich...

[pelzig]

CSV. Alle Werte als "Wert" in Gänsefüßchen und als Seperator "|" nehmen.

Abgesehen von Excel sollte jedes in der DP "empfohlene" Datenbankprogramm diese Gänsefüßchen erkennen!

Oder erkennt kein Datenfurzimportprogramm "|" den Seperator? Außer Excel?


MfG

[Sir Rufo]

Hört sich ein wenig nach Voodoo an. Muss man vorher irgendwie noch einen Hahn opfern und nackt (bis auf die Federn vom Hahn) durchs Feuer springen?

Oder reicht es, wenn man sich an die Vereinbarung mit dem Zielsystem hält, welche Strukturzeichen-Kombinationen dort berücksichtigt werden? Teilweise zugegeben nicht offensichtlich aber doch lösbar, allerdings mit Logik und ohne Voodoo.

[VkPenguin]

Vielen Dank nochmals für Eure Tipps. Ich habe mir die verschiedenen Möglichkeiten mal angesehen und glaube, dass sich TClientDataSet ganz gut eignet. Dazu habe ich mir dann einige Tutorials und Beispiele angesehen und ein kleines Testprogramm zusammengetippt.

Noch drei Fragen dazu:
1. Der Datentyp einer Spalte ist immer gleich, oder? Er kann also nicht z.b. ab der fünften Spalte geändert werden?
2. Speichert man dann Records, indem man den Record in seine Bestandteile aufteilt? Oder sollte man da mit Blob arbeiten?
3. Ist diese Vorgehensweise richtig, um ein bestimmtes Feld zu editieren, oder ginge es (etwa DB[5,2]:='test') auch einfacher?

Delphi-Quellcode:

DB.Locate('id',2,[]);
DB.Edit;
DB['person']:= 'person2';
DB.Post;

[humbuck]

Du solltest mein Angebot annehmen...

[Perlsau]

1. Ja, der Datentyp einer Spalte (=Feld) bleibt stets erhalten.

2. Wenn du in deiner Anwendung einen Recordtyp als Array festgelegt hast, dessen Inhalte du in eine Tabelle speichern möchtest, ist es erforderlich, daß die Record-Felder in der Tabelle sozusagen gespiegelt werden:

Delphi-Quellcode:

type
  MyRecord  = Record
    Name : String;
    Vorname : String;
    Strasse : String;
    PLZ : String;
    Ort : String;
    Geburtsdatum : TDate;
  End;

var
  Adressen : Array of Record;

Im Grunde benötigst du den Record aber gar nicht, wenn du direkt mit der Tabelle arbeitest.

Zitat:

Zitat von VkPenguin (Beitrag 1284312)

3. Ist diese Vorgehensweise richtig, um ein bestimmtes Feld zu editieren, oder ginge es (etwa DB[5,2]:='test') auch einfacher?

Delphi-Quellcode:

DB.Locate('id',2,[]);
DB.Edit;
DB['person']:= 'person2';
DB.Post;

Locate ist eine Funktion und liefert True zurück, wenn der gesuchte Eintrag gefunden und lokalisiert wurde. In deinem Beispiel wertest du den Rückgabewert der Funktion nicht aus und kannst daher nicht sicher sein, ob der Eintrag mit der Id=2 auch selektiert wurde, bevor du in diesem Record einen Feldwert änderst:

Delphi-Quellcode:

if DB.Locate('id',2,[]) Then
Begin
  DB.Edit;
  DB.FieldByName('person').AsString := 'person2';
  DB.Post;
End Else
Begin
  DB.Append;
  DB.FieldByName('person').AsString := 'person2';
  DB.FieldByName('id').AsInteger := 2;
  DB.Post;
End;

DB ist vermutlich dein CustomDataSet oder MemoryDataSet. Schau dir doch einmal die Hilfe zu Datasets an, das könnte sehr nützlich sein. Und laß dich nicht verwirren: In Datenbanken bezeichnet der Ausdruck Record einen Eintrag in einer Tabelle, tabellarisch gesehen wäre das dann eine Zeile. Eine Spalte in einer Tabelle ist ein Feld.

[VkPenguin]

@Humbock: vielen Dank für Dein Angebot, aber ich möchte selbst lernen, damit umzugehen.
@Perlsau: Danke Dir, 1. und 3. sind damit klar. Was ich jedoch nicht ganz verstanden habe ist 2.

Zitat:

Wenn du in deiner Anwendung einen Recordtyp als Array festgelegt hast, dessen Inhalte du in eine Tabelle speichern möchtest, ist es erforderlich, daß die Record-Felder in der Tabelle sozusagen gespiegelt werden

Ich habe in der Anwendung, für die ich die Datenbank später brauche bereits Records. Meine Frage ist nur, soll ich nun einen Record wie beispielsweise

Delphi-Quellcode:

type RPerson=Record
Name:String;
ID:Integer
End;

Personen:Array of RPerson

mithilfe zweier Spalten "Name" und "ID" speichern, oder gibt es da noch etwas geschickteres?

*Edit*: Gerade, wenn man bedenkt, dass es in meinem Programm etwa 10 Recordtypen gibt, die als Basis von Arrays unterschiedlichste Daten beinhalten, wird das doch recht unübersichtlich, oder nicht? Sollte man dann mit unterschiedlichen Datasets arbeiten? Aber die müssten dann doch auch zusammengeführt werden, um alles am Ende in einer Datei speichern zu können...? Oder habe ich da was falsch verstanden?

[Perlsau]

Wenn du deinen Record verwendest und das ganze dann in einer "Datenbank" via MemoryDataset (bzw. TClientDataSet) speicherst, verwaltest du deine Tabelle unnötigerweise doppelt. Natürlich kannst du eine Tabelle anlegen, die genau die Felder besitzt, die du in deinem Record bereits erstellt hast. Das ist aber erstens vollkommen umständlich und beansprucht zweitens unnötig Speicherplatz. Verwende doch stattdessen ausschließlich das Dataset als Datenpool. Du legst dann einfach deine Tabelle im Dataset an und arbeitest damit. Das bringt zudem weitere Vorteile wie Sortierung, leichteres Suchen via Locate oder Selektion z.B. aller Namen, die mit "M" anfangen.

Eine einfache Einführung in die Arbeit mit Memorydataset findest du im Delphi-Treff, das würde ich an deiner Stelle mal durcharbeiten:
Einfache Datenbanken mit MyBase

Besser wäre es natürlich, du würdest eine richtige Datenbank verwenden, z.B. Firebird. Das erfordert zwar etwas Einarbeitung, bringt dich aber auch weiter in deiner persönlichen Entwicklung zum Programmierer. Und du kannst damit noch viel mehr machen als mit Records oder einem MemoryDataset, kannst mehrere Tabellen zentral verwalten, hast es wesentlich einfacher beim Erstellen der Tabellen und vieles mehr ...

[humbuck]

Ich hab dir mal was gebastelt...

Das kannste dann ja deinen Bedürfnissen munter anpassen...

Damit sparst du dir extrem viel Arbeit bei den Datenzugriffen...

[Perlsau]

Versteh ich jetzt nicht: Was hat das mit der Problematik des TE zu tun, der ja weder eine Datenbank hat noch überhaupt Erfahrung im Umgang mit DBs? :shock:

Und inwiefern sollte dein Projekt hilfreich sein. Den Dialog, den du da präsentierst, kann ich auch direkt zur Designzeit aufrufen. Irgendwie ziemlich verwirrend das Ganze, findest du nicht? :?

Ach ja, bevor ich's vergesse: Weshalb machst du hier dauernd Werbung für dein Programm, das du gerne für 99,- Euro verkaufen würdest? Der TE will doch was lernen, oder siehst du das anders? :lol:

Irgendwie kann ich mich des Eindrucks nicht erwehren, du hast womöglich selber nicht besonders viel Erfahrung im Umgang mit Datenbanken :stupid:

[humbuck]

Zitat:

Zitat von Perlsau (Beitrag 1284322)

Versteh ich jetzt nicht: Was hat das mit der Problematik des TE zu tun, der ja weder eine Datenbank hat noch überhaupt Erfahrung im Umgang mit DBs? :shock:

Wollte er nicht eine Art 'Pseudo-Excel' einsetzen?

Aus seinen ersten Ausführungen geht hervor, dass er bei der Verwendung von Excel als 'Datenbank' hängen geblieben ist.
Und das kann er mit dem Programmbeispiel fix realisieren.

Bei seinem Verwendungszweck reicht das ja voll aus. Und es ist schneller, als Excel zu starten.

Zitat:

Und inwiefern sollte dein Projekt hilfreich sein. Den Dialog, den du da präsentierst, kann ich auch direkt zur Designzeit aufrufen.

Da hast du natürlich recht. Und nun? Meinste nicht, dass er damit viel mehr Flexibilität bekommt?

Zitat:

Zitat von Perlsau (Beitrag 1284322)

Ach ja, bevor ich's vergesse: Weshalb machst du hier dauernd Werbung für dein Programm, das du gerne für 99,- Euro verkaufen würdest? Der TE will doch was lernen, oder siehst du das anders? :lol:

Das er was lernen will, hat er erst danach geschrieben.
Ach ja, weshalb hast du denn die (Werbe-)Links in einem Account hier? Schon mal was vom Glashaus gehört?

Zitat:

Irgendwie kann ich mich des Eindrucks nicht erwehren, du hast womöglich selber nicht besonders viel Erfahrung im Umgang mit Datenbanken :stupid:

Danke, es reicht voll aus. Etwa 30 Jahre Erfahrung sollten genügen.
Und das : ":stupid:" ist schon frech gewesen.


Übrigens wusste ich nicht, dass du alleine hier die Anregungen und Hilfestellungen gibst. Oder sein Sprachrohr bist...:roll:

[Perlsau]

Zitat:

Da hast du natürlich recht. Und nun? Meinste nicht, dass er damit viel mehr Flexibilität bekommt?

Nein. Du hast offenbar das Anliegen des TE nicht verstanden. Das könntest du ändern, indem du seine letzten Forenbeiträge liest. Darauf wollte ich dich lediglich hinweisen, falls du mir folgen kannst.

Zitat:

Zitat von humbuck (Beitrag 1284324)

Ach ja, weshalb hast du denn die (Werbe-)Links in einem Account hier? Schon mal was vom Glashaus gehört?

Verweise auf Homepages sind erlaubt, direkte Werbung für Produkte dagegen nicht. Außerdem halte ich es nicht für hilfreich, einem Hilfesuchenden ein nicht näher definiertes Programm zum Kauf aufdrängen zu wollen und das gleich zweimal mit Nachdruck ("du solltest das kaufen"!). Wenn du auf deine Homepage verweisen möchtest, ist das mit Sicherheit kein Problem.

Zitat:

Zitat von humbuck (Beitrag 1284324)

Danke, es reicht voll aus. Etwa 30 Jahre Erfahrung sollten genügen.

Kann ich jetzt glauben oder weiter anzweifeln. Nach 30 Jahren Datenbankerfahrung sieht dein gepostetes Projekt jedenfalls nicht wirklich aus :stupid:

Übrigens schrieb der TE bereits: "@Humbock: vielen Dank für Dein Angebot, aber ich möchte selbst lernen, damit umzugehen." ... mal so apropo Erfahrung und so ...

Und damit meinte er sicher nicht, er möchte lernen, mit Excel umzugehen. Der Thread war an dieser Stelle schon etwas weiter, es geht inzwischen darum, wie man anstelle von Records ein ClientDataset oder besser gleich eine richtige Datenbank zur Datenverwaltung und -speicherung einsetzt.

Zitat:

Zitat von humbuck (Beitrag 1284324)

Und das : ":stupid:" ist schon frech gewesen.

Du darfst dich gerne bei den Admins über meine angebliche Frechheit beschweren. Ich finde auch so einiges frech ... Übrigens bedeutet dieses Smiley nicht, daß man das Gegenüber für dumm hält, sondern daß man mal ganz dumm fragt ... mal so apropo Erfahrung und so ...

Zitat:

Zitat von humbuck (Beitrag 1284324)

Übrigens wusste ich nicht, dass du alleine hier die Anregungen und Hilfestellungen gibst. Oder sein Sprachrohr bist...:roll:

Oh nein, nicht diese Leier! Wessen Sprachrohr soll ich sein? Ein wenig Zurückhaltung täte dir sicher gut.

[humbuck]

Ich denke, du solltest dich lieber auf dich konzentrieren, als in derartiger Weise dein Standpunkte zu vertreten.
Ich denke nämlich auch, diese Portal ist für Hilfe gedacht und nicht dazu, um andere zu diskreditieren. Ist leicht überflüssig.

Und noch was: Ich will dir nichts streitig machen. Deine Hilfe als Meinung zählt wie dir anderer auch. Brauchst also keine Angst zu haben.

So, und nun wieder zum Thema...

[Perlsau]

... no comment ...

[VkPenguin]

@Perlsau (#21): Danke!

den ersten Abschnitt mit MemoryDataset habe ich noch nicht so ganz verstanden, werde aber erstmal ein bisschen nach den Begriffen suchen und dann gegebenenfalls detailliertere Fragen stellen. Bisher habe ich es so gemacht, dass zum Programmstart alle Daten aus Excel lade und am Ende speichere. Mir ist zwar bewusst, dass ich so im Prinzip alles "doppelt" mache, aber für mich hatte es den Vorteil, dass ich z.B.

Code:

Kontostand:=Kontostand-Ausgabe

wesentlich besser lesen und verstehen kann als

Code:

DB.Value[...]:=DB.Value[...]-DB.Value[...]

Ich kann mir zwar gut vorstellen, dass dieses Problem nur auf meine mangelnden Fähigkeiten im Umgang mit der Datenbank zurückführe, aber bei meinem immerhin ca. 20.000 Zeilen Programm alle Variablen durch Datenbankeinträge zu ersetzen scheint mir wesentlich aufwendiger, als bei Programmstart und Ende einmal zu synchronisieren. Bei neuen Programmen werde ich natürlich versuchen, gleich von Beginn an die Datenbank zu integrieren, aber das muss man ja auch erstmal lernen. :-)

Das Tutorial habe ich bereits gelesen, sonst wäre ich soweit erst garnicht gekommen, aber trotzdem vielen Dank. Die weiterführenden Tutorials auf der Seite waren für mich leider nicht so hilfreich, was wahrscheinlich auch der Grund ist, warum ich nun hier festhänge.

Firebird kenne ich noch gar nicht, werde ich mir aber mal ansehen. Es wäre mir allerdings grundsätzlich lieber, nur mit Delphi-Standard-Komponenten auszukommen, weil ich mich mit anderen noch nicht auskenne, bin wie gesagt noch ein Anfänger. Das wird sicherlich auch mal wichtig werden, aber ich will nicht zuviele Baustellen auf einmal anfangen.

Danke jedenfalls nochmal, ich probiere mal noch ein bisschen und melde mich, falls ich eine genaue Frage habe.

[Perlsau]

Zitat:

Zitat von VkPenguin (Beitrag 1284382)

Firebird kenne ich noch gar nicht, werde ich mir aber mal ansehen. Es wäre mir allerdings grundsätzlich lieber, nur mit Delphi-Standard-Komponenten auszukommen, weil ich mich mit anderen noch nicht auskenne, bin wie gesagt noch ein Anfänger. Das wird sicherlich auch mal wichtig werden, aber ich will nicht zuviele Baustellen auf einmal anfangen.

Firebird ist keine Komponente, sondern quasi eine eigene "Anwendung", die als Dienst läuft: Ein Datenbank-Server. Da du XE7 einsetzt, verfügst du über die FireDac-Komponenten, mit denen du auch Verbindungen zu einer Firebird-Datenbank herstellen kannst. Du würdest also keine Fremdkomponenten benötigen. Firebird kann auch ohne Installation des Firebird-Datenbank-Servers eingesetzt werden, das nennt sich dann Embedded-Datenbank. Die DMBS-Funktionalität wird dann von einer DLL bereitgestellt. So läuft dein Programm dann auch auf Rechnern, die keinen Firebird-Server haben.

Davon abgesehen ist eher davon abzuraten, mit wenig bzw. lediglich rudimentärem Wissen gleich eine komplette Anwendung für den Produktiveinsatz zu entwickeln. Das bereut man spätestens dann, wenn die anfängliche "Kraut- und Rüben-Programmierung" an ihre Grenzen stößt und man inzwischen viel Neues dazugelernt hat, es aber nicht anwenden kann, weil der Aufwand dafür zu groß wäre. Ich spreche aus Erfahrung :cry: Inzwischen hab ich zig Anwendungen umgebaut bzw. neu entwickelt, weil der erste Ansatz zu Beginn meiner Entwickler-Laufbahn in eine Sackgasse führte. Das macht zugegebenermaßen nicht wirklich Spaß, aber mit den vermurksten Anwendungen weiterzuarbeiten, macht nicht nur keinen Spaß, sondern frustriert enorm. Wenn du also nur diese eine Anwendung hast, die modernisiert werden sollte, dann würde ich allen Ernstes dazu raten, das anzugehen. Je länger du das vor dir her schiebst, desto schwieriger wird es mit der Zeit.

[VkPenguin]

Wie gesagt, das mit Firebird werde ich mal ausprobieren und ich sehe auch ein, dass Du eigentlich mit dem zweiten Teil der Nachricht recht hast, allerdings bin ich mir immernoch nicht sicher, wie das dann laufen soll. Wenn die Variablen und Records alle lösche und dafür an deren Stelle direkte Datenbankbezüge setze wird das ganze doch furchtbar unübersichtlich... und wenn ich den Datenbankbezügen Namen gebe, sodass ich sie darüber ansprechen kann (falls das geht), dann habe ich ja letztlich doch wieder so etwas wie meine Variablen, oder ist das ein Denkfehler?

[Perlsau]

Grundsätzliches Wissen über den Einsatz von Datenbanken und die Entwicklung von Datenbank-Anwendungen kann ich dir hier nicht vermitteln, das kannst du dir letztlich nur selber aneignen, indem du dich in die Datenbank-Entwicklung einarbeitest. Wenn du dann soweit bist, werden auch deine obigen Fragen beantwortet sein. Das alles ist natürlich nicht für lau zu haben, sprich: du mußt selbstverständlich Zeit und Engagenemt investieren.

[p80286]

Zitat:

Zitat von VkPenguin (Beitrag 1284666)

... dann habe ich ja letztlich doch wieder so etwas wie meine Variablen, oder ist das ein Denkfehler?

Das ist durchaus möglich.
Letztlich ist eine DB eine Möglichkeit Daten zu speichern, und vor allem aus diesen Daten schnell bestimmte Daten zu extrahieren.
Welches Werkzeug Du für welche Anwendung nutzt bleibt Dir überlassen, und richtet sich vor allem nach der
Anwendung.

Gruß
K-H

[Sir Rufo]

Man kann die Anwendung direkt mit der Datenbank bzw. mit den Abfragen koppeln, muss man aber nicht. Die Minimalanforderung für die Anwendung ist das Holen von Informationen. Das kann man abstrakt definieren. Eine konkrete Implementierung kann dann mit einem beliebigen Datenspeicher kommunizieren. Der Anwendung ist es egal, solange die geforderten Informationen geliefert werden. Wie das passiert ... das ist Aufgabe der Implementierung und nicht der Anwendung, und kann bei Bedarf auch getauscht werden.