Philipp Hasenfratz: Die Lösung?

Beitrag lesen

Halihallo Andreas

Habe eine neue Idee, was haltet Ihr von einer "Kombi-Lösung"?

Meistens gut :-)

Eine ClintID die jeder Client im Feld ID mit autoincrement vergibt, dann ein Feld HerkunftsID, wo jeweils die ID des Standortes bei jedem Insert gespeichert wird, und als drittes eine Kombination aus beidem, dann verzicht ich halt auf die paar Millisekunden Zeitvorteil wenn ich Integer abfrage, die Zeit geht normalerweise eh woanders verloren, aber wenn ich eine Varchar ID habe, also z.b.

3.12345
^ ^^^^^
|   |
|   +----- DatensatzID(Client)
+---- HerkunftsID

Welches Format(schreibweise und Spaltenformat) würdet Ihr für eine derarige ID empfehlen?

Keine Fliesskommazahl! - Das könnte bei grossen ID's ins Verderben führen, es sei denn, dass die Genauigkeit so hoch ist, dass er auch die 20'ste Stelle noch richtig "abbildet" und nicht rundet. Naja, ich würde eigentlich ein Char nehmen (Index bei Varchar ist lange nicht so effizient); beim Char die Länge 20 oder so. So ist auch der Index noch sehr effizient (anders eben bei Varchar, da hier nur eine "Referenz" verwendet wird und die eigentlichen Daten nicht im Record sind).

  1. ich begrenze nicht den ID-Raum
  2. ich behalte eine einzige Eindeutige ID
  3. ich kann das System beim nächten größeren Update rel. problemlos auf 2-IDs umstellen

Ich glaube, dass dies hinhauen könnte. Bei den Selects verwendest du dann die DatensatzID, oder? - HerkunftsID ist eine eigene Spalte mit Default-Wert und die Synchronisation bringt das dann in eine ID "CHAR-ID". Habe ich das so verstanden?

Viele Grüsse

Philipp