Wie würdet Ihr das lösen?

[Kralle]

Moin,

in meiner Anwendung gibt es viele TabSheets auf denen viele Checkboxen , RadioButton und Edits drauf sind.
Am Ende des Programmes soll eine struktuierte ASCII-Datei erstellt werden.

Mein erster Ansatz war die Informationen immer an ganz bestimmte Stellen eines StringGrids zu schreiben und das hinterher in eine Datei zu schreiben.
- Aber, so einfach ist das auch nicht, wenn man bedenkt das ja durch Ändern eines Radiobuttons sich auch Inhalte ändern. Oder durch Änderungen in einem Edit.

Also, war meine zweite Überlegung erst am Ende alle Seiten durch zu gehen und die Informationen einzusammeln, da gegen spricht, das der Anwender keine Live-Vorschau mehr hat.

Dann über legte ich das mittel MyBase zu lösen, empfand es aber auch hier als sehr schwer dafür zu sorgen das egal in welcher Reihenfolge die Daten eingegeben werden, die Reihenfolge immer gleich bleibt.

Also, überlegte ich alles außer den Daten der Editfelder schon fest einzutragen und nur über ein Feld als aktiv oder passiv zu definieren. Macht aber die Erweiterbarkeit schwerer weil man an zwei Stellen erweitern muß.

Auch für jedes TabSheet eine Stringliste führen hatte ich schon überlegt.

Welche Möglichkeiten gibt es noch?

Gruß Heiko

[Sir Rufo]

Auf jeden Fall würde ich die Daten nicht in den Controls verwalten/halten, sondern in entsprechenden Daten-Containern (Klassen).

[pelzig]

Eine INI-Datei ist doch eine struktuierte ASCII-Datei.

MfG

[mkinzler]

Eine Ini-datei ist eine Textdatei, welche zwar eien Struktur aufweist aber nicht unbeding das, was man/der TE unter einer strukturierten ASCII-Datei versteht.

[Sir Rufo]

Der strukturelle Aufbau der Datei ist in diesem Zusammenhang doch sowas von schnurzpiepe.

Wäre irgendetwas an der Frage anders, wenn es sich um eine XML, ein sonstwie geartetete Binärdatei handeln würde?

Nein, denn der Ablauf bleibt immer gleich.

Irgendwas liest die Informationen aus der Datei in eine sinngebende Struktur.
Die Informationen in der Struktur werden bearbeitet und möglichst deren Plausibilität gewahrt.
Die Informationen der Struktur werden gespeichert.

[Kralle]

Hallo Sir Rufo,

Zitat:

Zitat von Sir Rufo (Beitrag 1286211)

Auf jeden Fall würde ich die Daten nicht in den Controls verwalten/halten, sondern in entsprechenden Daten-Containern (Klassen).

wie würde so was aussehen, wenn die Daten nachher in der Ascii diese Stuktur haben:

Fortlaufende Zeilennummer, Codenummer, Beschreibung, Vorbelegung

Wie ich sowas in eine Stringliste, ein StringGrid oder eine MyBase-Tabelle bekomme weiß ich, aber wie soll das mit einer Klasse gehen?

Die Daten werden nur in die Datei geschriben und nicht von dort gelesen und dann weiterbearbeitet.

Gruß Heiko

[Sir Rufo]

Wie sehen denn die Vorgaben aus, bzw. was steht dort konkret nachher drin und wie muss es dort drin stehen?

Da müsstest du ja eine Information zu haben.

Also woher weißt du, wohin der Wert von Edit64 in diese Datei kommt?

Dieses Wissen teilst du der Klasse mit ;)

[jobo]

Mir scheint, das Problem ist nicht die ASCII Struktur, sondern die derzeit fehlende oder unklare Struktur in der Präsentation, und daraus folgend das fehlende Mapping auf die ASCII Struktur.
Mach Dir bitte klar, dass es erstmal nie um die Frage mybase, ASCII oder binäre records geht- wie Sir Rufo schon schrieb- und auch nie an erster Stelle um die Darstellung- die ja anscheind schon "gegeben" ist.

Du hast Daten(strukturen), die in irgendeiner Form gespeichert und ggF. verarbeitet werden.
Du hast ebenso eine Präsentation dieser Daten im GUI, die Form der Darstellung ist auch hier sekundär. Von Tortengrafik über Stringgrids bis 3D Animation, alles möglich.

Da Du davon sprichst, dass die zu speichernden Daten nie gelesen werden müssen, dient Dein jetziges Programm offenbar der Eingabe?
Mache eine Aufstellung der einzugebenden (zu speichernden) Daten.
Lege Dir Klassen an, die diese Daten aufnehmen und wie gewünscht wegschreiben können.
An der Stelle äußere ich mal den Verdacht, dass es innerhalb Deiner Daten Abhängigkeiten gibt, die zu den von Dir geschilderten Schwierigkeiten führen. Bei der Klassenkonstruktion musst Du das also berücksichtigen.
Lege darüber eine GUI Schicht zur Eingabe und Darstellung.

[Kralle]

Moin,

Zitat:

Zitat von Sir Rufo (Beitrag 1286223)

Wie sehen denn die Vorgaben aus, bzw. was steht dort konkret nachher drin und wie muss es dort drin stehen?

Da müsstest du ja eine Information zu haben.

Also woher weißt du, wohin der Wert von Edit64 in diese Datei kommt?

Dieses Wissen teilst du der Klasse mit ;)

Also ich weiß das Daten die nachher in der Datei stehen, als erstes die Informationen vom Sheet 1 bekommen, dann die vom Sheet 2 usw.

Die Zeilennummern dürfen am Ende KEINE Lücken aufweisen

Manche Sheets und deren Objekte dürfen aber auch nur dann aktiv sein wenn auf den vorherigen Sheets bestimmte Bedingungen erfüllt sind.

Gruß HEiko

[mm1256]

Zitat:

Zitat von Kralle (Beitrag 1286210)

Mein erster Ansatz war die Informationen immer an ganz bestimmte Stellen eines StringGrids zu schreiben und das hinterher in eine Datei zu schreiben.
- Aber, so einfach ist das auch nicht, wenn man bedenkt das ja durch Ändern eines Radiobuttons sich auch Inhalte ändern. Oder durch Änderungen in einem Edit.

So ungeschickt ist der Ansatz doch gar nicht. Ich würde die Tag-Property der Komponenten verwenden, um den Index in der Stringliste festzulegen, und somit können mehrere Edit's, Checkboxen...was auch immer, einen eigenen oder auch einen gemeinsamen Wert im StringGrid ändern/zuweisen.

EDIT: Sorry, hat sich mit dem vorherigen Beitrag überschnitten. Ist dann doch keine so gute Idee

[Perlsau]

Zitat:

Zitat von Kralle (Beitrag 1286210)

... Mein erster Ansatz war die Informationen immer an ganz bestimmte Stellen eines StringGrids zu schreiben und das hinterher in eine Datei zu schreiben. ... Welche Möglichkeiten gibt es noch?

Wie Sir Rufo bereits bemerkt hat: Wirklich niemals, auf gar keinen Fall, echt nicht darstellende Komponenten zur Datenspeicherung einsetzen! Darstellende Komponenten sollten allein der Darstellung bzw. als Benutzerschnittstelle dienen.

Ich würde für sowas immer eine Datenbank nehmen. Das ist übersichtlich, leicht zu verwalten und leicht zu pflegen. Daten sind leicht zu selektieren, zu sortieren, zu speichern usw. Alles andere ist bei Programmen, die über ein Hello World hinausgehen, der falsche Ansatz.

Einfachste Datenbank-Verwendung beschreibt z.B. ein Tutorial im Delphi-Treff: Einfache Datenbanken mit MyBase. Da du aber sowieso mit XE7 arbeitest, kannst du auch gleich eine richtige Datenbank einsetzen und diese mit den FireDac-Komponenten ansprechen. Hier würde ich zu einer Firebird-Datenbank raten, die ist leicht zu erlernen und stellt sogar eine Embedded-Variante zur Verfügung (= läuft dann auch ohne installierten Firebird-Server).

Weitere Datenbank-Tutorials im Delphi Treff

Zum Erstellen einer Firebird-Datenbank installiert man sich erst einmal den passenden Firebird-Server. Danach lädt man sich von IbExpert den Datenbank-Manager herunter.

Weitere Infos zur Datenbank-Entwicklung erhältst du bei Bedarf, falls du dich dafür entscheiden solltest.

Bemerkung:
Wenn man sich mal daran gewöhnt hat, mit Datenbanken zu arbeiten, möchte man das nicht mehr missen :-D

[Sir Rufo]

Man könnte also die Basisdaten folgendermassen darstellen:

Delphi-Quellcode:

TDataItem = class
public
  property Code : Integer;
  property Comment : string;
  property Value : string;
end;

TData = class
public
  property Dialog : TList<TDataItem>;
end;

Da ich keinen Gesamtüberblick habe, kann ich das natürlich schlecht überschauen, was nun wirklich benötigt wird, bzw. wie man die Struktur passend in einer Klasse darstellen kann. Wichtig ist und bleibt aber immer der Zusammenhang zwischen Daten und Kontext. Die Eigenschaften Comment und Value sind beide vom Typ string, aber durch den Aufbau der Klasse und die Benennung stelle ich auch noch den Kontext dar.

[AlexII]

Zitat:

Zitat von Perlsau (Beitrag 1286230)

Hier würde ich zu einer Firebird-Datenbank raten, die ist leicht zu erlernen.

Da würde ich lieber SQLite nehmen, sie ist zig mal einfacher als Firebird und installieren muss man da auch nix.

[Perlsau]

Zitat:

Zitat von AlexII (Beitrag 1286263)

Da würde ich lieber SQLite nehmen, sie ist zig mal einfacher als Firebird und installieren muss man da auch nix.

Also wenn du Firebird wirklich kennen würdest – und das wäre ja die Voraussetzung für den Vergleich mit SQlite –, dann wüßtest du, daß man auch Firebird nicht installieren muß. Zum Entwickeln einer Firebird-Embedded-Anwendung genügt es nämlich, die entsprechende Dll ins Bin-Verzeichnis zu kopieren und der Connect-Komponente lediglich den vollständigen Dateinamen mitzuteilen. Dennoch empfehle ich stets auch die Installation des Firebird-Servers (geht quasi vollautomatisch), weil sich's dann leichter entwickeln läßt.

Im Grunde ist's mir aber völlig egal, was du lieber nehmen würdest. Das kannst du halten wie "sella uff'm Dach". Jeder nimmt am liebsten immer das, was er schon kennt und macht das andere schlecht, weil er's nicht lernen will. Derartige Threads hatten wir hier ja schon bis zum Abwinken und darum geht's hier auch nicht, sondern um die Beantwortung der Frage, wie man das Problem des TE am besten lösen könnte. Wenn er sich für eine Datenbank statt ominösem Dateigefuchtel entscheidet, ist's mir auch piepe, welche DB er sich da aussucht.

Alles klar?

[AlexII]

Zitat:

Zitat von Perlsau (Beitrag 1286264)

Alles klar?

Hast Du schlecht geschlafen oder was?
Ich mache keine DB schlecht, oder kritisiere sonst irgendwas... ich schreibe nur wie ICH (und nicht jemand) das machen würde. Jeder schreibt hier was er machen würde, und ich mache nichts anderes. Deswegen verstehe ich deine Aufregung nicht.

[mkinzler]

Zitat:

Ich mache keine DB schlecht, oder kritisiere sonst irgendwas...

Zitat:

Da würde ich lieber SQLite nehmen, sie ist zig mal einfacher als Firebird und installieren muss man da auch nix.

Dann erklär uns doch einfach, warum SQLite zig mal einfacher wie FireBird ist.

[p80286]

Zitat:

Zitat von Kralle (Beitrag 1286225)

Die Zeilennummern dürfen am Ende KEINE Lücken aufweisen

Dann numeriere eben kurz vor dem Ende.

Zitat:

Zitat von Kralle (Beitrag 1286225)

Manche Sheets und deren Objekte dürfen aber auch nur dann aktiv sein wenn auf den vorherigen Sheets bestimmte Bedingungen erfüllt sind.

Das ist ein Problem der Oberfläche.

Und als Zwischenspeicher würde ich eine TList, TObjectlist oder eine TStringlist benutzen.

Gruß
K-H

[p80286]

Zitat:

Zitat von mkinzler (Beitrag 1286267)

Zitat:

Ich mache keine DB schlecht, oder kritisiere sonst irgendwas...

Zitat:

Da würde ich lieber SQLite nehmen, sie ist zig mal einfacher als Firebird und installieren muss man da auch nix.

Dann erklär uns doch einfach, warum SQLite zig mal einfacher wie FireBird ist.

Wäre dafür nicht ein eigener Thread geeigneter?

Gruß
K-H

[Perlsau]

Zitat:

Zitat von AlexII (Beitrag 1286266)

Zitat:

Zitat von Perlsau (Beitrag 1286264)

Alles klar?

Hast Du schlecht geschlafen oder was?
Ich mache keine DB schlecht, oder kritisiere sonst irgendwas... ich schreibe nur wie ICH (und nicht jemand) das machen würde. Jeder schreibt hier was er machen würde, und ich mache nichts anderes. Deswegen verstehe ich deine Aufregung nicht.

Nein danke, ich hatte zu dieser Zeit noch gar nicht geschlafen, sondern bis kurz vorher gearbeitet und dank etlicher Erfolgserlebnisse sogar auffallend gute Laune :wink:

Die Frage danach, ob bei dir jetzt alles klar sei, sollte dich keinesfalls provozieren, sondern diente einfach nur der Bestätigung, daß du meinen Ausführungen zu folgen verstehst. Aufgeregt hatte ich mich dabei in der Tat kein bißchen, das hast du dir lediglich eingebildet :lol:

Und nun wieder zurück zum Thema, bitte :!:

Achso, bevor ich's vergesse: Ist es richtig anzunehmen, daß du Firebird nicht wirklich aus der Praxis kennst :?:
Die Annahme liegt nahe, da du wie bereits erwähnt als angeblichen Vorteil von SqLite angibst, man müsse es nicht installieren, wobei du offenbar nicht wußtest, daß man Firebird ebenfalls nicht installieren muß, wenn man die Embedded-Variante wählt. Oder ist es nicht tatsächlich so, wie ich bereits oben ausführte: Man verteidigt, was man kann/kennt, und lehnt ab, was man nicht kann/kennt?

[AlexII]

Zitat:

Zitat von Perlsau (Beitrag 1286275)

[SIZE="9"]Achso, bevor ich's vergesse: Ist es richtig anzunehmen, daß du Firebird nicht wirklich aus der Praxis kennst :?:

Na ja... was heißt wirklich? Klar habe ich mich mit Firebird beschäftigt aber ich fand SQLite einfacher, allein bei der "Einrichtung" schon. Will hier aber nicht mehr darauf eingehen, sonst kommen wir vom Thema ab. Aber wenn Du irgendwelche Tutorials für Firebird hast, dann schaue ich mir diese DB noch mal an.

[Kralle]

Hallo,

erstmal Entschuldigung das ich erst jetzt reagiere.

Wenn ich das Konzept von Datenbanken richtig verstehe, dann werden die Daten dadrinnen über Ihren Index verwaltet.
Jeden Index-Wert gibt es solange wie die DB existiert nur einmal - richtig?
Wenn ich jetzt 5 Werte von TabSheet1 in die DB schreibe, dann erhalten die den Index 1-5 - soweit richtig?
Wenn ich die Werte von TabSheet2 Dann von Index 10-15 schreiben will, dann geht das nur solange gut, wie der Anwender nicht 5 mal etwas in TabSheet1 löscht und neu anlegt.
Denn wenn er Index5 löscht und dann doch wieder anlegt, wird daraus Index6 und dann 7, 8, 9, und dann würde Index 16 folgen - richtig?

Wenn ich obiges richtig verstanden habe, ist eine DB für mich nicht nutzbar.

Gruß Heiko

[Dejan Vu]

Ich glaube, Du hast es nicht verstanden.
In einer Datenbanktabelle gibt es keine (durchnummerierten) Zeilen, sondern nur Mengen. Der Name 'Table' ist schon irreführend. Deine Menge sollte zwei Eigenschaften aufweisen:
1. Die einzelnen Datensätze sollten eindeutig identifizierbar sein (Primary Key)
2. Es sollte eine totale Ordnung auf den Datensätzen bestehen.

Beides ist nicht zwingend, erleichtert aber die Arbeit ungemein. Punkt 1 muss eigentlich immer umgesetzt werden, während sich #2 meistens aus #1 ergibt, einfach weil die eindeutige Identifizierbarkeit am einfachsten über eine sortierbare Eigenschaft eines Datensatzes (z.B. Kundennummer) erfolgt.

Wenn Du jedem Datensatz eine feste Zeilennummer spendieren willst, dann ist das eine explizite Eigenschaft des Datensatzes, die DU festlegen musst. Entweder direkt, oder über Automatismen in der Datenbank(tabelle), sog. Trigger. Das sind Aktionen, die immer (und wirklich immer, deshalb ist eine Datenbank eine Bank) eintreten, wenn ein Datensatz angefasst wird. Eine solche Aktion könnte z.B. lauten:

Code:

Trigger on Insert:
Datensatz.Zeilennummer = Maximale Zeilennummer der Datenmenge (bzw. 0, wenn die Menge leer ist) + 1;

Damit ist aber noch nicht geklärt, wie man eine Lücke auffüllt, die ein gelöschter Datensatz hinterlässt.
Dann müsste man ... denk selbst nach.

Derartige Nummerierungen haben meist keinen Wert (außer für die Anzeige), weswegen man Selbige i.d.R. auch nur bei der Ansicht der Datenmenge erzeugt.

Wenn Du aber unbedingt Zeilennummern benötigst, verwende EXCEL oder eine Text-Datei, oder einen anderen Container, der Dir genau das bietet.

Überlege aber genau, ob du das wirklich brauchst. Denn was 100.000.000 Programmierer nicht benötigen, könnte auch in deinem Fall überflüssig sein.

[Blup]

Das Konzept einer fortlaufenden Zeilennummer ist in der Praxis nicht sinnvoll, die Probleme beim Löschen hast du ja bereits selbst dargestellt.
Noch viel schwieriger wird das ganze, wenn mehrere Benutzer zur selben Zeit Datensätze hinzufügen oder entfernen.
Unmöglich kann man so Beziehungen zwischen Datensätzen unterschiedlichen Tabellen darstellen z.B.:

Tabelle1 (Kundentabelle)
Zeile, Kundennummer, Name, Ort(Zeile)
1, 10003, Hans, 2
2, 10005, ALf, 4

Tabelle2 (Ortetabelle)
Zeile, ORT
1, Berlin
2, Hamburg
3, Bremen
4, Dachboden

Muss jetzt z.B. Berlin gelöscht werden, müssen nicht nur in der Ortetabelle alle Zeilennummern neu vergeben werden.
Auch in allen abhängigen Tabellen müssen alle Nummern aktualisiert werden.
Mal abgesehen von dem Aufwand, der bei hundertausend Datensätzen nicht mehr beherrschbar wäre.
Wenn Benutzer A gerade den Datensatz mit Hans bearbeitet und Benutzer B löscht in der Zwischenzeit Berlin.
Der Benutzer A müsste dann eine Fehlermeldung beim Speichern bekommen oder er schreibt seine Daten mit der falschen Ortszeilennummer zurück.
Das ist bei sehr vielen komplexen Beziehungen nicht beherrschbar.

Deshalb hat sich das Konzept einer eindeutigen Identifikationsnummer je Datensatz als Primärschlüssel durchgsetzt.
Diese Nummer wird zwar auch fortlaufend bei der Neuanlage eines Datensatzes vergeben, es sind aber durchaus Lücken erlaubt.
Wichtig ist, diese Nummer wird niemals dem Anwender angezeigt. Der wählt den Datensatz z.B. über die Kundennummer oder die Postleitzahl aus.
Das Programm führt die ID aber immer mit dem Datensatz mit. Eine Zeilennummer ist eigentlich überflüssig, da der Anwender die Daten nach verschiedenen Spalten sortieren kann.
Diese könnte man aber beim Lesen der Daten auch einfach fortlaufend mitzählen und ausgeben.

Ist eine vom Anwender frei definierbare Sortierung der Datensätze einer bestimten Tabelle erforderlich, kann man dafür z.B. eine Hilfstabelle anlegen, die ID und fortlaufende Sortiernummer zur eigentlichen Datentabelle enthält. Dadurch werden durch einen Umsortierung die Datensätze in der Datentabelle nicht verändert.

[jobo]

Zitat:

Zitat von Kralle (Beitrag 1286651)

Wenn ich das Konzept von Datenbanken richtig verstehe, dann werden die Daten dadrinnen über Ihren Index verwaltet.

Könnte man so sagen (umgangsprachlich) ist aber nicht richtig.
Der Index auf eine oder mehrere Felder in einer Tabelle ist ein Hilfsmittel zur Beschleunigung des Zugriffs auf gesuchte Werte / Feldinhalte. Eine Datenbank kann komplett ohne Index arbeiten und tadellos funktionieren, ist dann aber um ein Vielfaches langsamer, als eine halbwegs ordentlich indizierte DB. Die Indizierung ist extra nahezu unabhängig von der Logik im Datenmodell, teilweise legt eine DB Indizes automatisch an, ansonsten kann man das alles aber selbst definieren oder automatische Indizierungen ändern. Vergiß erstmal den Index.
Der richtige Begriff ist hier Schlüssel. Schlüsselfelder werden meist in Primär-/Sekundär- und Fremdschlüssel unterteilt. Entscheidend ist zu Anfang der Primärschlüssel, ein eindeutiger Wert, mit dessen Hilfe jeder Datensatz in einer Tabelle eindeutig gefunden werden kann.
Die Erzeugung dieser Werte wird idR durch den Datenbankserver vorgenommen, der weiß, wie er das machen muss. Fortlaufend sind diese Werte nicht notwendiger Weise, das ist unnötig (für die Eindeutigkeit und damit den Sinn dieses Feldes) und wird meist nicht so gemacht.

Zitat:

Zitat von Kralle (Beitrag 1286651)

Jeden Index-Wert gibt es solange wie die DB existiert nur einmal - richtig?

Ja, aber dieser Indexwert, den ich oben beschrieben habe, kann Dir wurscht sein. Ein Datenbank-Index wird niemals direkt durch Abfragen oder so angesprochen. Er wird sofern definiert automatisch vom Server verwaltet, existiert nur einmal, kann aber auf mehrere Werte in der Tabelle zeigen. (Bspw. ein Indexwert 'Meier' zeigt auf viele Datensätze)

Zitat:

Zitat von Kralle (Beitrag 1286651)

Wenn ich jetzt 5 Werte von TabSheet1 in die DB schreibe, dann erhalten die den Index 1-5 - soweit richtig?

Nein, Du würdest einen Primärschlüssel definieren (anstelle des Index), die Werte werden vom Server eingetragen. Du musst sie ggF. nach dem Anlegen eines Datensatzes auslesen, um sie weiterverwenden zu können. Das hängt von den Möglichkeiten des verwendeten Datenbank Clients ab.

Zitat:

Zitat von Kralle (Beitrag 1286651)

Wenn ich die Werte von TabSheet2 Dann von Index 10-15 schreiben will, dann geht das nur solange gut, wie der Anwender nicht 5 mal etwas in TabSheet1 löscht und neu anlegt.
Denn wenn er Index5 löscht und dann doch wieder anlegt, wird daraus Index6 und dann 7, 8, 9, und dann würde Index 16 folgen - richtig?

Nein, nein, nein,.. Ausgehend davon, dass in Deinen Tabsheets nicht die gleiche Datenstruktur vorliegt, hättest Du hinter Tab1 Tabelle A und hinter Tab2 Tabelle B. In beide schreibst Du und jeder andere nach herzenslust rein.
Damit das bei mehreren Nutzern Sinn macht, werden solche Daten idR mit einem Bezug zu einem übergeordneten Objekt (Tabelle C) geschrieben und dargestellt. In Tabelle A und B wird jeweils dieser Bezug auf C mitgeführt. Das nennt man einen Fremdschlüssel (der idR auch über einen Index verfügt - zur Beschleunigung- aber egal).

Zitat:

Zitat von Kralle (Beitrag 1286651)

Wenn ich obiges richtig verstanden habe, ist eine DB für mich nicht nutzbar.

Vielleicht bist Du mittlerweile auf der richtigen Spur, aber Du solltest Dir vielleicht mal ein paar Datenbankgrundlagen aneignen.
Wie auch immer Du Deine Daten bis jetzt verwaltest und abspeicherst, ein Datenbanksystem tut das auch und zwar standardisiert, zuverlässig und schnell. (Und noch mehr, ließ dazu über Transaktionen usw.)

[mkinzler]

Zitat:

Zitat von Kralle:
Wenn ich das Konzept von Datenbanken richtig verstehe, dann werden die Daten dadrinnen über Ihren Index verwaltet.
Könnte man so sagen (umgangsprachlich) ist aber nicht richtig.

Nein, der Index ist nur ein zusätzliches Instrument zur Beschleunigung. Man kann ein Buch auch ohne Inhalts-/Stichwort-/Abbildungs-Verzeichnis lesen. Sucht man nach einem Stichwort beschleunigt das Stichwortverzeichnis aber die Suche, da man nicht das gesamte Buch durchsuchen muss, sondern nur das Verzeichnis, in dem die Seitennummer steht.

Zitat:

Jeden Index-Wert gibt es solange wie die DB existiert nur einmal - richtig?

Jede Kombination gibt es pro Index (Übeersicht) nut einmal.

[Perlsau]

Zitat:

Zitat von Blup (Beitrag 1286672)

Das Konzept einer fortlaufenden Zeilennummer ist in der Praxis nicht sinnvoll ...

Doch, das kann durchaus Sinn machen. Z.B. hab ich eine DB-Anwendung für Waffenfachhändler entwickelt, die das gesetzlich vorgeschriebene Waffenhandelsbuch ersetzt. Voraussetzung ist eine ununterbrochene, d.h. fortlaufende Serie von IDs. Gelöst wird das ganz einfach, indem das Löschen in der DB strikt verboten ist: Der Anwender hat keine Möglichkeit, mittels dieser Application einen Datensatz zu löschen. Würde er mit irgend einem DB-Manager in der Datenbank rumpfuschen, um einen Datensatz zu löschen, könnte er Schwierigkeiten mit dem entsprechenden Aufsichtsamt bekommen, da seine Waffenan- und verkäufe dann nicht mehr lückenlos dokumentiert wären.

[Sir Rufo]

Zitat:

Zitat von Perlsau (Beitrag 1286705)

Zitat:

Zitat von Blup (Beitrag 1286672)

Das Konzept einer fortlaufenden Zeilennummer ist in der Praxis nicht sinnvoll ...

Doch, das kann durchaus Sinn machen. Z.B. hab ich eine DB-Anwendung für Waffenfachhändler entwickelt, die das gesetzlich vorgeschriebene Waffenhandelsbuch ersetzt. Voraussetzung ist eine ununterbrochene, d.h. fortlaufende Serie von IDs. Gelöst wird das ganz einfach, indem das Löschen in der DB strikt verboten ist: Der Anwender hat keine Möglichkeit, mittels dieser Application einen Datensatz zu löschen. Würde er mit irgend einem DB-Manager in der Datenbank rumpfuschen, um einen Datensatz zu löschen, könnte er Schwierigkeiten mit dem entsprechenden Aufsichtsamt bekommen, da seine Waffenan- und verkäufe dann nicht mehr lückenlos dokumentiert wären.

Dazu muss man sich aber Gedanken um den Kontext machen und nicht wie der TE in TabSheets denken ;)

[Kralle]

Moin,

ich glaube wir driften ab.

Also,

1. Die Anwendung ist wird eine StandAlone-Anwendung die nicht auf einem Server laufen wird.
2. Die Anwendung wird nur gebraucht um eine ASCII-Datei zu erstellen, deren Erstellung mit dem Fremdprogramm in dem Sie später genutzt wird zu aufwendig ist.
3. Die Reihenfolge der Einträge ist wichtig.
4. Zeilennummer werden am Ende beim Erstellen der Datei eingefügt.

Als ich eure Beiträge las und darüber nachdachte, bin ich zu folgender Lösung gekommen:

1. Ist erstelle eine StringList
2. Ich fülle eine bestimmte Anzahl von Strings in der Liste einem Leerzeichen (wobei ich mir in diesem Punkt nicht sicher bin ob das nötig ist, oder ob ich auch direkt in die z.B. zehnte Zeile einen String einfügen kann ohne das vorher Zeile 0-9 vorhenden waren.)(Muss ich noch prüfen).
3. Ich führe für jedes TabSheet (sind eigene Units) eine Variable ein in der ich die Startposition in der StringList vorgebe (so kann ich bei Erweiterungen relativ einfach ändern)
4. Ich nutze folgendes in den einzelnen TabSheets:
   z.B. im OnChange-Ereignisses einer CheckBox
   
   Delphi-Quellcode:

   If Checked then StringList[ListenPosIndex+1]:= '4022,Symb.auswerten(0/2),0'
   else StringList[ListenPosIndex+1]:= '4022,Symb.auswerten(0/2),1';

   @Sir Rufo: Wie sollte ich diese Texte anders unterbringen, als im Quellcode:?: Sollte ich in einem DatenModul eine Stringlist mit diesem Texten anlegen und auf diesen dann zugreifen. Wenn ich dann etwas erweitern will, müsste ich überall im Quellcode die Verweise anpassen.
   
5. Ich erstelle nach einem Klick auf einen entsprechenden Button die ASCII-Datei.

Die Vorgängerversion ist diese hier: http://www.rompelsoft.de/index.php/d...alog-generator

Ich denke alles andere wäre für diese Anwendung zu groß - oder:?:

Gruß Heiko

[p80286]

Zitat:

Zitat von Kralle (Beitrag 1286719)

@Sir Rufo: Wie sollte ich diese Texte anders unterbringen, als im Quellcode:?: Sollte ich in einem DatenModul eine Stringlist mit diesem Texten anlegen und auf diesen dann zugreifen. Wenn ich dann etwas erweitern will, müsste ich überall im Quellcode die Verweise anpassen.

Wenn ich mir das so anschaue, dann fällt mir spontan XML/DTD ein, leider bin ich nicht firm genug darin, um zu beurteilen was diese Idee wert ist. aber hier lesen genügend XML-Könner mit.

Gruß
K-H

[Kralle]

Hallo,

Zitat:

Zitat von p80286 (Beitrag 1286725)

Wenn ich mir das so anschaue, dann fällt mir spontan XML/DTD ein, leider bin ich nicht firm genug darin, um zu beurteilen was diese Idee wert ist. aber hier lesen genügend XML-Könner mit.

Dann wären wir wieder bei MyBase :-D

Gruß Heiko

[mkinzler]

Nicht unbedingt. MyBase verwendet zwar XML, aber XML ohne MyBase ist u.U. flexibler.

[Kralle]

Moin,

Zitat:

Zitat von mkinzler (Beitrag 1286737)

Nicht unbedingt. MyBase verwendet zwar XML, aber XML ohne MyBase ist u.U. flexibler.

und wie würdest Du schematisch Gesehen das in meinem Fall einsetzen?

Gruß Heiko

[Perlsau]

Zitat:

Zitat von Kralle (Beitrag 1286752)

Zitat:

Zitat von mkinzler (Beitrag 1286737)

Nicht unbedingt. MyBase verwendet zwar XML, aber XML ohne MyBase ist u.U. flexibler.

und wie würdest Du schematisch Gesehen das in meinem Fall einsetzen?

Die XML-Struktur ist bereits das Schema.

[Dejan Vu]

Zitat:

Zitat von jobo (Beitrag 1286681)

Eine Datenbank kann komplett ohne Index arbeiten und tadellos funktionieren, ist dann aber um ein Vielfaches langsamer, als eine halbwegs ordentlich indizierte DB.

Ein Index verlangsamt die INSERT und DELETE-Operationen, da dieser aktualisiert werden muss. Auch ein UPDATE ohne WHERE wird dann langsamer. Auch für ein ungeordnetes SELECT benötigt man keinen Index und ein Index beschleunigt die Abfrage auch nicht (oder?).
Wenn man das allerdings auf eine ganze Datenbank ausdehnt, also mit Beziehungen zwischen den Tabellen, hast Du vollkommen Recht-

Allerdings fallen mir nicht viele sinnvolle Anwendungen ein, wo man komplett ohne Index auskommt.

Zitat:

...teilweise legt eine DB Indizes automatisch an...

Ich kenne hier nur den Primary-Key Constraint. Wo passiert das noch?

[Sir Rufo]

Also auf jeden Fall würde ich mir ein Repository anlegen, von wo aus ich auf den Kontext zugreifen kann.

Delphi-Quellcode:

TDataContext = class
  private
    FIdent: Integer;
    FText: string;
  public
    constructor Create( Ident: Integer; const Text: string );
    function ToString: string; override;

    property Ident: Integer read FIdent;
    property Text: string read FText;
  end;

IDataContextRepository = interface
  function Find( Ident : Integer ) : TDataContext;
end;

Wenn an dem Datenkontext jetzt auch noch fest der Datentyp der Eingabe festgemacht werden kann, dann haue ich den auch noch dazu. Daraus kann ich mir dann die passende Datenklasse zusammenbauen und den Wert dort hineinlegen.

Delphi-Quellcode:

  TDataValue = class abstract
  private
    FDataContext: TDataContext;
  public
    constructor Create( DataContext: TDataContext );
    property DataContext: TDataContext read FDataContext;
  end;

  TDataValueClass = class of TDataValue;

  TDataValue<T> = class( TDataValue )
  private
    FValue: T;
  public
    property Value: T read FValue write FValue;
  end;

Und so geht man Schritt für Schritt weiter bis man die gesamte Struktur logisch abgebildet hat. Dann baut man sich noch einen Importer/Exporter für die benötigten Datenformate (Text, XML, HTML, Datenbank) und jagt das da einfach durch.

[jobo]

Zitat:

Zitat von Dejan Vu (Beitrag 1286780)

Zitat:

Zitat von jobo (Beitrag 1286681)

Eine Datenbank kann komplett ohne Index arbeiten und tadellos funktionieren, ist dann aber um ein Vielfaches langsamer, als eine halbwegs ordentlich indizierte DB.

Ein Index verlangsamt die INSERT und DELETE-Operationen, da dieser aktualisiert werden muss.

Kommt drauf an, Du hast selbst unten nach mit und ohne 'Where' unterschieden.
Ein Delete mit 'Where' dürfte mit (verwendetem) Index und ausreichender Selektivität der Bedingung auch mal gern schneller sein.

Zitat:

Zitat von Dejan Vu (Beitrag 1286780)

Auch ein UPDATE ohne WHERE wird dann langsamer.

'dann'? Wann? Mit Index ohne 'where'? Auch das ist von anderen Bedingungen abhängig.

Zitat:

Zitat von Dejan Vu (Beitrag 1286780)

Auch für ein ungeordnetes SELECT benötigt man keinen Index und ein Index beschleunigt die Abfrage auch nicht (oder?).

Benötigt sowieso nicht, das war ja meine Kernaussage. Ungeordetes Select? Ich nehme an, Du sprichst nicht von Order by clauses oder doch? Beschleunigen sollte er trotzdem, wenn der Index für die Abfrage genutzt werden kann.

Zitat:

Zitat von Dejan Vu (Beitrag 1286780)

Wenn man das allerdings auf eine ganze Datenbank ausdehnt, also mit Beziehungen zwischen den Tabellen, hast Du vollkommen Recht-

Meine Ausführungen zum Index waren eher grundsätzlicher Natur. Ich glaube nicht, dass es dem TE an erster Stelle hilft, solche Unterscheidungen zu berücksichtigen, wenn der Begriff selbst nicht richtig verstanden ist oder ein vages Verständnis besteht, aber unter einem falschen Begriff.

Zitat:

Zitat von Dejan Vu (Beitrag 1286780)

Allerdings fallen mir nicht viele sinnvolle Anwendungen ein, wo man komplett ohne Index auskommt.

Wie gesagt, es ging nur um eine plastische Darstellung der Bedeutung/Funktion eines Index.

Zitat:

Zitat von Dejan Vu (Beitrag 1286780)

Zitat:

...teilweise legt eine DB Indizes automatisch an...

Ich kenne hier nur den Primary-Key Constraint. Wo passiert das noch?

[/QUOTE]
Kann ich nicht allgemein sagen, würde sogar davon ausgehen, dass es irgendwo da draußen Systeme gibt, die nicht mal bei einem Primärschlüssel automatisch indizieren. Es gibt aber bspw. Systeme, die das automatisch bei Unique Constraints machen.
Solche und ähnliche Konstrukte beeinflussen sicherlich auch die Insert / Update Geschwindigkeit positiv mit Index und ohne dessen direkte Verwendung in der Where Clause.

Den TE dürfte das aber eher wenig interessieren.

[mkinzler]

Zitat:

Ein Delete mit 'Where' dürfte mit (verwendetem) Index und ausreichender Selektivität der Bedingung auch mal gern schneller sein.

Es müssen aber alle Indizes (der Tabelle) mit angepasst werden.

[jobo]

Zitat:

Zitat von mkinzler (Beitrag 1286783)

Zitat:

Ein Delete mit 'Where' dürfte mit (verwendetem) Index und ausreichender Selektivität der Bedingung auch mal gern schneller sein.

Es müssen aber alle Indizes (der Tabelle) mit angepasst werden.

Das ist richtig.
Es müssen u.U. sogar noch mehr Indizes als nur die der einen Tabelle angepasst werden, wenn z.B. Cascade Delete Constraints verwendet werden. Wenn in einem CRM System ein(!) Personendatensatz gelöscht wird, betrifft das dann auch alle abhängigen Datensätze, das führt u.a. zu einem Vielfachen an Löschoperationen und erneuten Indexkorrekturen. Gleichzeitig können die vorhandenen Indizes der Fremdschlüssel aber zur Lokalisierung der zu löschenden Datensätze verwendet werden und Summa Summarum ist es immer noch schneller als ohne Indizes und den dann notwendigen Full Scans.

Ich bin mir aber immer noch sicher, dass diese Diskussion hier im Thread fehlplaziert ist. Es ging mir darum Indizes und ihre Verwendung von Schlüsselfeld Definitionen zu unterscheiden. Und ein Index hat nunmal (fast) keine funktionale Bedeutung für ein Datenmodell bzw. eine Datenbank.

Hier können jetzt Anmerkungen gemacht werden, dass man gar keine Datensätze löschen soll...

[Dejan Vu]

Ohne Index sind DML-Operationen (ohne WHERE) schneller. Ich hätte das auch so einfach schreiben können. Ob das den TE interessiert, glaube ich auch nicht, aber wenn man schreibt das eine DB mit Index schneller wird, darf man das doch wohl mal klarstellen (und zwar für andere, die das dann lesen), ohne das einem das Mund im Drehen verwirdet wort, oder Wortklauberei betrieben wird oder jedes Wort auf die Goldwaage gelegt wird oder Sätze mit nicht eindeutigem Bezug in Frage gestellt werden oder obwohl wirklich sonnenklar ist, was gemeint ist, oder? :roll: Manchmal, aber nur manchmal, nervt das Forum bzw. einige kleinkarierte Beiträge und ob nun dieser oder mein voriger Beitrag dazu gezählt wird oder nicht, überlasse ich den Kleinkarierten.

[BUG]

Zitat:

Zitat von Perlsau (Beitrag 1286771)

Die XML-Struktur ist bereits das Schema.

Nicht wirklich.
Das XML-Dokument ist zwar selbstbeschreibend; es beschreibt wie es selbst aufgebaut ist. Ein XML-Schema ermöglicht es zu prüfen, ob das Dokument richtig aufgebaut ist.