Wie würdet Ihr das lösen?

[AlexII]

Zitat von Perlsau:

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 von 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.

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

Gruß
K-H

[Perlsau]

Zitat von AlexII:

Zitat von Perlsau:

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

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

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 von Perlsau:

[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.

[Perlsau]

Zitat von Blup:

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.

[jobo]

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.
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 von Kralle:

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 von Kralle:

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 von Kralle:

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 von Kralle:

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.)