AGB  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Alternative für SQLite auf Android Gerät (fmx)

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

Ein Thema von stalkingwolf · begonnen am 12. Sep 2017 · letzter Beitrag vom 15. Sep 2017
Antwort Antwort
Seite 3 von 4     123 4   
Foren-Tage 2017
DIE Konferenz für Delphi-Entwickler mit vielen Vorträgen und ganztägigen Workshops, veranstaltet u.A. von der Delphi-PRAXiS und Embarcadero.
21.-23. September 2017 in Hamburg · Mehr Infos unter forentage.de.
TigerLilly

Registriert seit: 24. Mai 2017
Ort: Wien, Österreich
112 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#21

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

  Alt 13. Sep 2017, 11:05
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ß.
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
1.920 Beiträge
 
Delphi 2010 Enterprise
 
#22

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

  Alt 13. Sep 2017, 13:15
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.
Gruß, Jo
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
38.196 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#23

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

  Alt 13. Sep 2017, 15:09
SnapShots machen nur Sinn, wenn man auf Teil-Transaktionsebene rücksetzen möchte.
Markus Kinzler
  Mit Zitat antworten Zitat
Ghostwalker

Registriert seit: 16. Jun 2003
Ort: Schönwald
1.013 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#24

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

  Alt 14. Sep 2017, 04:12
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 ?
Uwe
e=mc² or energy = milk * coffee²
  Mit Zitat antworten Zitat
stalkingwolf

Registriert seit: 6. Mai 2011
238 Beiträge
 
#25

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

  Alt 14. Sep 2017, 16:10
da Text drin steht ... ja
  Mit Zitat antworten Zitat
TigerLilly

Registriert seit: 24. Mai 2017
Ort: Wien, Österreich
112 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#26

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

  Alt 14. Sep 2017, 17:25
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.
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
1.920 Beiträge
 
Delphi 2010 Enterprise
 
#27

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

  Alt 14. Sep 2017, 20:12
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.
Gruß, Jo
  Mit Zitat antworten Zitat
TigerLilly

Registriert seit: 24. Mai 2017
Ort: Wien, Österreich
112 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#28

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

  Alt 14. Sep 2017, 20:39
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.
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
38.196 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#29

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

  Alt 14. Sep 2017, 20:55
Ich würde grundsätzlich einen "künstlichen" Primärschlüssel verwenden.
Markus Kinzler
  Mit Zitat antworten Zitat
TigerLilly

Registriert seit: 24. Mai 2017
Ort: Wien, Österreich
112 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#30

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

  Alt 14. Sep 2017, 21:14
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
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:58 Uhr.
Powered by vBulletin® Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2017 by Daniel R. Wolf