![]() |
Wie würdet Ihr das lösen?
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 |
AW: Wie würdet Ihr das lösen?
Auf jeden Fall würde ich die Daten nicht in den Controls verwalten/halten, sondern in entsprechenden Daten-Containern (Klassen).
|
AW: Wie würdet Ihr das lösen?
Eine INI-Datei ist doch eine struktuierte ASCII-Datei.
MfG |
AW: Wie würdet Ihr das lösen?
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.
|
AW: Wie würdet Ihr das lösen?
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. |
AW: Wie würdet Ihr das lösen?
Hallo Sir Rufo,
Zitat:
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 |
AW: Wie würdet Ihr das lösen?
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 ;) |
AW: Wie würdet Ihr das lösen?
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. |
AW: Wie würdet Ihr das lösen?
Liste der Anhänge anzeigen (Anzahl: 1)
Moin,
Zitat:
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 |
AW: Wie würdet Ihr das lösen?
Zitat:
EDIT: Sorry, hat sich mit dem vorherigen Beitrag überschnitten. Ist dann doch keine so gute Idee |
AW: Wie würdet Ihr das lösen?
Zitat:
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: ![]() ![]() Zum Erstellen einer Firebird-Datenbank installiert man sich erst einmal den passenden ![]() ![]() 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 |
AW: Wie würdet Ihr das lösen?
Man könnte also die Basisdaten folgendermassen darstellen:
Delphi-Quellcode:
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.
TDataItem = class
public property Code : Integer; property Comment : string; property Value : string; end; TData = class public property Dialog : TList<TDataItem>; end; |
AW: Wie würdet Ihr das lösen?
Zitat:
|
AW: Wie würdet Ihr das lösen?
Zitat:
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? |
AW: Wie würdet Ihr das lösen?
Zitat:
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. |
AW: Wie würdet Ihr das lösen?
Zitat:
Zitat:
|
AW: Wie würdet Ihr das lösen?
Zitat:
Zitat:
Und als Zwischenspeicher würde ich eine TList, TObjectlist oder eine TStringlist benutzen. Gruß K-H |
AW: Wie würdet Ihr das lösen?
Zitat:
Gruß K-H |
AW: Wie würdet Ihr das lösen?
Zitat:
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? |
AW: Wie würdet Ihr das lösen?
Zitat:
|
AW: Wie würdet Ihr das lösen?
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 |
AW: Wie würdet Ihr das lösen?
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:
Damit ist aber noch nicht geklärt, wie man eine Lücke auffüllt, die ein gelöschter Datensatz hinterlässt.
Trigger on Insert:
Datensatz.Zeilennummer = Maximale Zeilennummer der Datenmenge (bzw. 0, wenn die Menge leer ist) + 1; 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. |
AW: Wie würdet Ihr das lösen?
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. |
AW: Wie würdet Ihr das lösen?
Zitat:
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:
Zitat:
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:
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.) |
AW: Wie würdet Ihr das lösen?
Zitat:
Zitat:
|
AW: Wie würdet Ihr das lösen?
Zitat:
![]() |
AW: Wie würdet Ihr das lösen?
Zitat:
|
AW: Wie würdet Ihr das lösen?
Moin,
ich glaube wir driften ab. Also,
Als ich eure Beiträge las und darüber nachdachte, bin ich zu folgender Lösung gekommen:
Die Vorgängerversion ist diese hier: ![]() Ich denke alles andere wäre für diese Anwendung zu groß - oder:?: Gruß Heiko |
AW: Wie würdet Ihr das lösen?
Zitat:
Gruß K-H |
AW: Wie würdet Ihr das lösen?
Hallo,
Zitat:
Gruß Heiko |
AW: Wie würdet Ihr das lösen?
Nicht unbedingt. MyBase verwendet zwar XML, aber XML ohne MyBase ist u.U. flexibler.
|
AW: Wie würdet Ihr das lösen?
Moin,
Zitat:
Gruß Heiko |
AW: Wie würdet Ihr das lösen?
Zitat:
|
AW: Wie würdet Ihr das lösen?
Zitat:
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:
|
AW: Wie würdet Ihr das lösen?
Also auf jeden Fall würde ich mir ein Repository anlegen, von wo aus ich auf den Kontext zugreifen kann.
Delphi-Quellcode:
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.
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;
Delphi-Quellcode:
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.
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; |
AW: Wie würdet Ihr das lösen?
Zitat:
Ein Delete mit 'Where' dürfte mit (verwendetem) Index und ausreichender Selektivität der Bedingung auch mal gern schneller sein. Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
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. |
AW: Wie würdet Ihr das lösen?
Zitat:
|
AW: Wie würdet Ihr das lösen?
Zitat:
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... |
AW: Wie würdet Ihr das lösen?
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.
|
AW: Wie würdet Ihr das lösen?
Zitat:
Das XML-Dokument ist zwar selbstbeschreibend; es beschreibt wie es selbst aufgebaut ist. Ein ![]() |
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:22 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz