Delphi-PRAXiS
Seite 3 von 5     123 45      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Delphi Wie würdet Ihr das lösen? (https://www.delphipraxis.net/183461-wie-wuerdet-ihr-das-loesen.html)

Kralle 16. Jan 2015 06:54

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

Dejan Vu 16. Jan 2015 07:55

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:
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 16. Jan 2015 10:07

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.

jobo 16. Jan 2015 10:52

AW: Wie würdet Ihr das lösen?
 
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 16. Jan 2015 11:06

AW: Wie würdet Ihr das lösen?
 
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 16. Jan 2015 12:46

AW: Wie würdet Ihr das lösen?
 
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 16. Jan 2015 13:04

AW: Wie würdet Ihr das lösen?
 
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 16. Jan 2015 13:58

AW: Wie würdet Ihr das lösen?
 
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 16. Jan 2015 14:35

AW: Wie würdet Ihr das lösen?
 
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 16. Jan 2015 14:58

AW: Wie würdet Ihr das lösen?
 
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


Alle Zeitangaben in WEZ +1. Es ist jetzt 09:05 Uhr.
Seite 3 von 5     123 45      

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