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

[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

[Ghostwalker]

@TigerLilly

Ich stimm dir schon zu, das das bei kleineren Datenmengen eher irrelevant ist. Ich hab mir aber grundsätzlich einfach angewöhnt, möglichst eindeutige Zahlen (Integer usw. ) als Primärschlüssel zu verwenden (auch wenn er dann "nur" ein technischer Schlüssel ist), da mir die Erfahrung gezeigt hat, das die Datenmenge am Projektanfang grundsätzlich viel zu niedrig angesetzt wird. Hinterher ist der Aufwand größer, das ganze zu ändern.

Unter der Voraussetzung, das dort wirklich nur Zahlenwerte gespeichert werden, sollte man auch in einer DB den richtigen Datentyp verwenden. Im Programm verwendet man ja auch für Ganzzahlen Integer-Variablen und nicht Strings

[stalkingwolf]

Ob Natural oder Surrogate Key ist abhängig davon was man drin speichern will.
Das wird auch bei jedem Vergleich der beiden Logiken angesprochen.

Das Datenmodell was ich hier genutzt habe für die Tabelle auf dem Pad i
st die gleiche wie in unserer DB, so dass ich einfach alles 1 zu 1 übernehmen kann ohne mir große einen Kopf zu machen.

[jobo]

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

Diese Rechnungsnummer und wie sie aufgebaut ist soll ja nur ein beliebiges Beispiel sein. Jede Firma macht da so ihr Ding, oft sind heterogene Systeme im Einsatz, Quelle/Format der Rechnungsnummer oder irgendeiner anderen Bearbeitungsnummer sind häufig nicht in der (alleinigen) Hoheit der eigenen Anwendung.
Hinzu kommt, dass diese "Welten" nicht statisch sind. Der Tag kommt also, wo dank einer Änderung eines Ablaufs oder dem Austausch einer Software die Dinge plötzlich anders laufen.
Ich sehe das eher so, das die Verwendung natürlicher Schlüssel aus Zeiten stammt, wo Speicherplatz noch kostbar war. Heute liegen die Prioritäten anders, mehr Schnittstellen, mehr Interoperabilität, mehr Flexibilität sind gefordert.
Kleines Beispiel: Kontonummer / BLZ könnte man vielleicht mal als Primärschlüssel verwendet haben. Schwierig wird es schon mit der Bankenkonsolidierung, immer mehr Zweigstellen werden unter einer BLZ zusammengefasst. Dann kommt SEPA und alles ist ganz anders.
Fazit: Je mehr ich die reine Mechanik von fachlicher Funktion trenne, desto besser kann ich ein System auf Änderungen einstellen oder schlicht customizen, wenn ich Stangenwahre anbiete, die der Kunde sich zurecht biegen kann.