Alternative für SQLite auf Android Gerät (fmx)

[TigerLilly]

Zitat:

Zitat von jobo (Beitrag 1381006)

Zitat:

Zitat von TigerLilly (Beitrag 1381001)

Weil je größer das transaction log wird, desto langsamer wird die Sache...

Das ist pauschal nicht richtig und vielleicht auch nicht im Fall von SQLite.

Also in MEINER Welt ist das schon so, egal ob Oracle, mySQL oder MSSQL. Das ist in 1-Benutzersystemen nicht so sehr das Problem, da geht es eher um Performance und Platz, aber bei Mehrbenutzersystem jedenfalls, denn lange/große Transaktionen killen dann das System.

Eine Transaktion sorgt dafür, dass Operationen "danach" vollständig ungeschehen gemacht werden können. Abgesehen davon, dass das nicht für alle Operationen gilt (zB DDL, manche Formen von Löschen (TRUNCATE), etc), gibt es drei Probleme, wenn die Transaktion lange dauert oder sehr groß wird:
- der Platzbedarf für das notwendige loggen steigt - vor allem in Mehrbenutzersystemen!
- die Operationen werden langsamer (auch für andere User) weil der Verwaltungsaufwand immer größer wird
- mit dem COMMIT müssen alle gepufferten Operationen ausgeführt werden - die Wahrscheinlichkeit, dass das mit einer Änderung eines anderen Users kollidiert, steigt

Darum hätte mich das hier bei SQLite ja interessiert. SQLite funktioniert da ja anders, eher auf Dateiebene, als auf Satzebene, was ich weiß.

[jobo]

Ok, ich will das hier nicht sprengen, in SQLite ist es vielleicht irgendwie anders.

Ich würde sagen, Du wirst keinen Oracle Mitarbeiter finden, der behauptet, mach kleine Transaktionen, weil es dann schneller ist. Und ein Redolog muss so groß sein, dass alle Transaktionen, die die Businesslogik fordert auch durchgezogen werden können. (Natürlich kann man Operationen definieren, die ein -immer nur endlich großes- Redolog sprengen).

Und richtig, Transaktionen sorgen für die Möglichkeit eines vollständigen Rollback.
Welchen Sinn macht es dann, logisch zusammenhängende Oprationen in mehrere kleine Transaktionen zu zerlegen, so dass im Fall eines Rollbacks ein inkonsistenter Zustand zurückbleibt?

In keinem meiner Programme gibt es irgendeine Codezeile, die sich damit auseinandersetzt, wie weit eine Operation bereits fortgeschritten ist, was auf den Schrott kommt, geschweige denn vielleicht kommen müsste. Dafür ist die DB mit ihren Transaktionen zuständig.

Na vielleicht etwas übertrieben, wenn Millionen von Datensätzen importiert werden müssen, kann man eine Entwickler DB schon etwas schonen und stückeln, aber es ist m.E. prinzipiell falsch.

Wenn eine große Transaktion in einem Produktivsystem andere Benutzer behindert und das häufig der Fall ist, ist das System unterdimensioniert, falsch administriert oder falsch konzipiert.

[mkinzler]

SnapShots machen nur Sinn, wenn man auf Teil-Transaktionsebene rücksetzen möchte.

[Ghostwalker]

Hihi,

vielleicht noch am Rand eine andere Sache. So wie ich das in deinem Code sehe ist der Primärschlüssel ein Textfeld und speichert eine Nummer. Das ist jetzt nicht wirklich optimal, da das verwalten des Index so länger dauert, als z. B. bei einem Integer. Von den Lese/Such-Operationen mal ganz abgesehen.

Ist es denn wirklich notwendig das Feld als Text zu definieren ?

[stalkingwolf]

da Text drin steht ... ja :wink:

[TigerLilly]

Zitat:

Zitat von Ghostwalker (Beitrag 1381093)

So wie ich das in deinem Code sehe ist der Primärschlüssel ein Textfeld und speichert eine Nummer. Das ist jetzt nicht wirklich optimal, da das verwalten des Index so länger dauert, als z. B. bei einem Integer. Von den Lese/Such-Operationen mal ganz abgesehen.

Das halte ich für eine sehr gewagte Behauptung. In der Regel wirst du den Unterschied nicht mal messen können. Integer-Keys brauchen weniger Platz als String-Keys, darum geht der Vergleich ein kleines bisschen schneller, aber da sind andere Faktoren viel viel wichtiger. Je mehr Datensätze es sind und je länger der Key ist, desto mehr schlägt das zu Buche, aber ich würde sagen, da reden wir von > x Mio Datensätzen und Keylänge > 250 (wobei du da ziemlich sicher schon einen Designfehler hast).

Also: Index so bauen, wie es die Daten nahelegen + keine Kopfstände machen.

[jobo]

Zitat:

Zitat von TigerLilly (Beitrag 1381196)

Zitat:

Zitat von Ghostwalker (Beitrag 1381093)

So wie ich das in deinem Code sehe ist der Primärschlüssel ein Textfeld und speichert eine Nummer. Das ist jetzt nicht wirklich optimal, da das verwalten des Index so länger dauert, als z. B. bei einem Integer. Von den Lese/Such-Operationen mal ganz abgesehen.

Das halte ich für eine sehr gewagte Behauptung. In der Regel wirst du den Unterschied nicht mal messen können. Integer-Keys brauchen weniger Platz als String-Keys, darum geht der Vergleich ein kleines bisschen schneller, aber da sind andere Faktoren viel viel wichtiger. Je mehr Datensätze es sind und je länger der Key ist, desto mehr schlägt das zu Buche, aber ich würde sagen, da reden wir von > x Mio Datensätzen und Keylänge > 250 (wobei du da ziemlich sicher schon einen Designfehler hast).

Also: Index so bauen, wie es die Daten nahelegen + keine Kopfstände machen.

Naja, wenn im Feld tatsächlich text steht, sollte es natürlich ein Textfeld sein. Wobei es sqlite glaub ich sogar egal ist.

Tatsächlich sollte aber ein Primärschlüssel ein technischer sein, also nicht fachlich und nicht Daten enthalten, die fachlich verwendet werden. Ist also eine Auftragsnummer aus Zahlen,Tagesdatum und Bearbeiterkürzel zusammen gesetzt (und natürlich eindeutig) nehme ich sie dennoch nicht als Primärschlüssel.

Insofern ist die Behauptung von Ghostwalker nicht sonderlich gewagt, sondern entspricht mehr oder weniger der gängigen Praxis.

[TigerLilly]

Zitat:

Ist also eine Auftragsnummer aus Zahlen,Tagesdatum und Bearbeiterkürzel zusammen gesetzt (und natürlich eindeutig) nehme ich sie dennoch nicht als Primärschlüssel.

Das würdest du nur dann nicht tun, wenn dein Datennmodell das verhindert. Dein Beispiel ist ein zusammengesetzter Schlüssel - dessen Teile müssen foreign keys sein oder elementare Datentypen. Wenn du zusätzlich zu diesem Key noch einen weiteren PK einführst, hast du nichts gewonnen und nur Aufwand.

Aber du hast trotzdem recht - manche DB-Systeme unterstützen kaskadierende Änderungen nicht + dann müssen wir notgedrungener Weise einen zusätzlichen PK einführen, aber nie freiwillig. :-)

[mkinzler]

Ich würde grundsätzlich einen "künstlichen" Primärschlüssel verwenden.

[TigerLilly]

Natural key vs surrogate key - das Netz ist voll davon :-)

Ich geb dir recht, manchmal macht ein "künstlicher" Primärschlüssel einem das Leben leichter. Aber für mich ist das immer ein Hinweis, dass das Datenmodell nicht stimmt. Oder das abzubildende Problem nicht verstanden wurde.

Ein künstlicher Primärschlüssel macht Datenaustausch/Datenabgleich nahezu unmöglich. Ich fürchte mich vor surrogate keys wie der Teufel vor dem Weihwasser :-)