Datenbankzugriffskomponenten

[Christian]

Ich wollte mal ansprechen wie die subjektiven Meinungen hier von den Komponenten sind.
meine Erfahrungen mit dem prometheus Datenbanklayern:

TDbf
Viele werden jetzt sagen wie kann man überhaupt nur versuchen ein aktuelles grösseres Programmsystem versuchen mit einer Desktopdatenbank und dazu noch mit TDbf aufzuziehen...
Nunja ich hatte damals nur mit der BDE zu tun und bin so beim naheliegensten geblieben.
Tatsächlich hab ich damit bisher auch die besten Erfahrungen gemacht.
Fast die gesamte Entwicklungszeit des Prometheus hab ich damit verbracht, bis vor ca einem halben Jahr.
Und ich muss heute noch sagen es ist immernoch das schnellste Datenbanklayer fürs Prometheus.
Allerdings hab ich vor einem halben jahr einen ehrben Rückschlag hinnehmen müssen als ich das e-Mail System implementiert hab und dort plötzlich so 500 Datensätze pro Tag auf TDbf eingehämmert haben. Das ging 3 Monate gut und dann haben sich meine Mail Tabellen auf äusserst merkwürdige Weise selbst zerstört unwiederherstellbar. Sowas hab ich selbst mit der BDE nie erlebt.
Woraufhion ich dann sehr schnell ein neues Datenbanklayer für SQLite gebaut habe.
Nebenbei bemerkt laufen heute noch einige Datenbanken auf TDbf Basis und bisher ohne Probleme. Jedoch hab ich es offiziell herausgenommen weil mit die Daten darin zu unsicher sind.

SQLite
Die TSqlite3Dataset Klasse hat mich von anfang an arg entäuscht.
Ich hab glaub ich 8 richtig böse fehler da rausgemacht bis das ding sich halbwegs wie ein TDataSet nachfahr verhalten hat (incl Master/Detail und co).
Die Geschwindigkeit ist beim einfügen von Daten ziemlich schlecht, fast schon unnütz. Abfragen hingegen sind superschnell.
Als es dann kurz bevor ich es produktiv einsetzen wollte dazu kam das Plötzlich interne Datensatzzeiger ungültig waren und Access Violations daraus resultierten hab ich davon auch die Finger gelassen.

ZeOS DBO
Ich hab nur gutes davon gehört bisher allerdings sind meine Erfahrungen bisher auch nicht reinweg positiv.
Das Datenbanklayer war recht schnell gebaut und nach ein paar kleinen Eigenheiten lief auch Prometheus damit sauber.
Bis auf ein paar merkwürdige Effekte die ich dann auf Locate zurückführen konnte welches in der Stable nicht sauber nach Integerfeldern suchen kann.
Gut ist im SVN behoben weiter...
Vergleicht man mit Locate ein Feld das NULL ist ist der vergleich auch generell Falsch obwohl der Vergleichswert ebenfalls NULL ist...
Solche Fehler bringen mich doch dann schon arg ins Grübeln. Ich hab ihn für mich korrigiert aber im ZeOS Forum Antwortet man bisher nicht auf meien Anfrage warum das so ist und ob ein Patch dafür erwünscht ist.

Was habt Ihr für Erfahrungen gemacht ? Sollt ich vieleicht wirklich noch ein SQLDb Database Layer basteln und damit auch noch mein lück versuchen ?

[monta]

Vergleicht man mit Locate ein Feld das NULL ist ist der vergleich auch generell Falsch obwohl der Vergleichswert ebenfalls NULL ist

Ein Vergleich von NULL mit NULL der false zurückliefert, ist doch aber nach SQL-definition vollkommen korrekt.

1.3.2 NULL-Wert
NULL ist ein Zustandsindikator, welcher angibt, dass ein bestimmter Wert nicht gesetzt wurde und
somit nicht vorhanden ist.
„In SQL, NULL is not a value. It is a state indicating that an item's value is unknown or
nonexistent.“[4]
Außerdem ist zu beachten, dass dieser Zustand durch keinen Wert repräsentiert werden kann, so gilt
grundsätzlich:
NULL ≠ 0 und NULL ≠ [Leere Zeichenkette] und NULL ≠ NULL
Somit wird deutlich, dass ein auf 'leer' gesetztes Feld (aus menschlicher Sicht), beispielsweise durch
Zuweisung eines Strings der Länge 0 nicht NULL enthält, da das Feld ja gesetzt wurde, sondern
stattdessen einen leeren String zurück liefert.
Nullwerte können also wie folgt interpretiert werden (nach [2]):
● Attribut ist auf Tupel nicht anwendbar
● Attributwert für dieses Tupel ist unbekannt
● Wert ist bekannt, aber nicht vorhanden (d.h.: er wurde noch nicht erfasst)

2: Elmasri, R., Navathe, Shamkant B., Grundlagen von Datenbanksystemen; Pearson Studium, München 2002
4: Vinkenoog, Paul , Firebird Null Guide, 26 January 2007

[Christian]

Das will mir nicht in den Schädel wenn ich einen vergleich von NULL mit NULL anstelle muss der doch gleich ergeben. Das NULL und '' oder NULL und 0 ungleich ergeben versteh ich ja aber NULL und NULL ???

[monta]

Ich wollte ja nur sagen, das Zeos das völlig korrekt verarbeitet!

Auch wenn es logisch, wenn man es sich so vorstellt eigentlich keinen Unterschied macht, da hast du schon recht.

[Christian]

Ich wollte ja nur sagen, das Zeos das völlig korrekt verarbeitet!

Und wie kann ich dann ein sinvolles Locate ausführen ? Wenn ich teilweise eben noch nicht eingetragene Werte hab ?

[af0815]

Ich wollte ja nur sagen, das Zeos das völlig korrekt verarbeitet!

Und wie kann ich dann ein sinvolles Locate ausführen ? Wenn ich teilweise eben noch nicht eingetragene Werte hab ?

Ich glaube für die dreiwertige binäre Logik sind die SQL-Eigenschaften in Desktopähnlichen DBs nicht ... hmm.. optimal. Deswegen muss man ja in SQL auch den Vergleich mit 'IS NULL' machen und nicht mit '= NULL'. In diesem Falle würde ich beim Design der DB einplanen ohne NULL-Werte zu arbeiten oder gleich auf SQL arbeiten.

[Christian]

Für zeOS ist in dem Moment "" auch = NULL soweit ich das verstehe

[af0815]

In deinem Fall, soweit ich ich das sehe, würde ich auf reines SQL gehen, das sind die Resultate deterministisch, auch die unterschiede von DB zu DB sind nicht vom Layer dazwischen so stark abhängig. Denn an die DB werden im Endeffekt ja auch nur SQL-Statements abgeschickt. Locate ist meiner Meinung nach etwas aus der DesktopDB Welt und daher für komplexere Aufgaben nur mit starken Einschränkungen verwendbar.

[Christian]

Nein, da ich auch desktopdatenbanken durch das DB Layer unterstütze geht das nicht da leb ich lieber mit einer angepassten ZeOS Version.
Wobei ich das immernoch für einen fehler halte da Locate ja von den Desktopdatenbanken kommt und sich dort damals anders verhalten hat.

[af0815]

Nein, da ich auch desktopdatenbanken durch das DB Layer unterstütze geht das nicht da leb ich lieber mit einer angepassten ZeOS Version.
Wobei ich das immernoch für einen fehler halte da Locate ja von den Desktopdatenbanken kommt und sich dort damals anders verhalten hat.

Kannst du das ev. durch eine änderung in den DBdaten weg von null beherrschen ? Dann wäre es IMHO sauberer als die Zeos zu patchen.

[Christian]

Bei neu angelegten Daten natürlich aber was passiert mit den altdaten ?
Kann irgendwer das verhalten von ZeOS mit Delphi mal bestätigen ?
Ich würd zugern mal wissen ob Locate bei TBDEdataSet UND einem dbExpress oder ADODataSet das selbe Ve4rhalten an den Tag legt.

[af0815]

Kann irgendwer das verhalten von ZeOS mit Delphi mal bestätigen ?
.... oder ADODataSet das selbe Ve4rhalten an den Tag legt.

Kurzes Beispiel, um exakt das Verhalten unter Delphi und ADO bestimmen können, möglich ?

[Christian]

Kann ich schlecht machen da ich kein Delphi hab.

Man müsste in einem Dataset einfach auf ein leeres feld ein Locate ausführen.

[af0815]

Kann ich schlecht machen da ich kein Delphi hab.

Man müsste in einem Dataset einfach auf ein leeres feld ein Locate ausführen.

Hab ich auch nicht gemeint, sondern ein Beispiel in Lazarus, das ich in Delphi dann ausprobieren kann.

[Christian]

In Lazarus gibts kein TBDEDataSet oder TADODataSet