GUID als Index?

[Sharky]

Hai,

ich schreibe gerade an einem kleinen Programm. Dieses besteht aus einer lokalen DB und einem DB-Server.

Neue Daten werden immer lokal erfasst. Über eine Exportfunktion können die neuen Daten nun zum Server übertragen werden und über einen Import können die Einträge der anderen Benutzer in die lokale Datenbank eingetragen werden.

Jetzt stellt sich mir die Frage wie ich am besten die IDs vergebe. Einfach hochzählen geht ja nicht. Dann habe ich ja doppelte IDs.

Mir sind bis jetzt zwei Methoden eingefallen.

a) - Als ID wird eine GUID verwendet
b) - Ich erzeuge die ID aus der Benutzernummer und einem Hochgezähltenwert. z.B:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
 gesamt_id : INT64;
 datensatz_id,
 user_id : LongInt;
begin
  user_id := 10000;
  datensatz_id := 4;
  gesamt_id := (user_id SHL 16) + datensatz_id;
  Edit1.Text := IntToStr (gesamt_id);   // Das ist die gesamt ID
  Label1.Caption := IntToStr (gesamt_id SHR 16);  // Herausrechnen der user_id
  Label2.Caption := IntToStr (gesamt_id AND $FFFF);  // Herausrechnen der datensatz_id
end;

Was ist nun der beste Weg?

[Mario]

Der Weg mit dem hinzuzählen von einer Benutzernummer finde ich unglücklich. Was ist, wenn es im Laufe der Zeit mal mehr Benutzer gibt? Dann steht Dein Konzept in einer Sackgasse...

Weg 2 mit der GUID ist nicht schlecht.

Als Weg 3 würde ich Nummernkreise vorschlagen. Beim Anmelden bekommt Deine App einen Nummerkreis von sagen wir mal tausend Nummern vom Server zugeteilt. Wenn die weg sind, werden die nächsten geholt.

[Jens Schumann]

Hallo Sharky,
ich würde es folgendermaßen probieren:

- Lokal eine ID verwenden. Beim IB würde ich hier einen Generator nutzen.
- Wenn die lokalen Daten auf den Server geschoben werden darf die lokale ID
nicht mit gegeben werden. Auf dem Server erhalten die Datensätze dann eine neue ID.
Da der Server die ID's vergibt kommt es auch nicht zu doppelten ID's

Wenn die lokalen Daten auf den Server gespielt wurden können diese ja lokal gelöscht werden.
Weil -> die Daten sind ja erfasst. Deshalb gibt es auch keine weiteren Probleme mit den ID's

Wenn der Client sich jetzt die Daten wieder vom Server holt arbeitet er eben mit den ID's vom Server.

Jetzt könnte der Fall eintreten, dass der Client Daten vom Server geholt hat. Diese Daten werden verändert und neue Daten werden erfasst. Jetzt muss bei den geänderten Daten die ID verwendet werden und bei den neuen Datensätze eben nicht.

[Sharky]

Hai Mario,

Zitat:

Zitat von Mario

.... Was ist, wenn es im Laufe der Zeit mal mehr Benutzer gibt? Dann steht Dein Konzept in einer Sackgasse...

Das sollte bei einem 32Bit Bereich für die Benutzernummer nicht passieren.

Zitat:

Weg 2 mit der GUID ist nicht schlecht.

Ich denke ich werde in diesem Fall über die GUID gehen. Es werden nicht viele Einträge in der Datenbank sein. so das das Suchen über die GUID dein Problem sein wird.

Zitat:

Als Weg 3 würde ich Nummernkreise vorschlagen. Beim Anmelden bekommt Deine App einen Nummerkreis von sagen wir mal tausend Nummern vom Server zugeteilt. Wenn die weg sind, werden die nächsten geholt.

Auch eine gute Idee. Muss ich mir mal durch den Kopf gehen lassen.

Danke.

[sakura]

Zitat:

Zitat von Sharky

Auch eine gute Idee. Muss ich mir mal durch den Kopf gehen lassen.

Ich denke mal, ich weiß was Du meinst und ich würde auch die Nummernkreise vorschlagen. 100er Gruppen reichen allemal.

...:cat:...

[Sharky]

Zitat:

Zitat von sakura

...Ich denke mal, ich weiß was Du meinst und ich würde auch die Nummernkreise vorschlagen. 100er Gruppen reichen allemal...

Die Katze meint zu wissen was ich mache? :stupid:

Aber die Idee Mario ist gut und dürfte leicht zu realisieren sein. Ich brauche ja nur eine Tabelle die ein ID-Feld hat (autoInc) und ein Feld für die User-ID.

Wenn dort ein neuer Eintrag gemacht wird bekommt der User die ID*100 als neuen Bereich.

Code:

 ID    USER
  1    Sharky   <- Bereich 100-199
  2    Mario    <- Bereich 200-299
  3    Sakura   <- Bereich 300-399
  4    Sharky   <- Bereich 400-499

[DelphiDeveloper]

fuer deine ich nenne es mal "replikation on demand" sieht man in der tat oft guids als
ids vor. Ich hatte in meinem letzten Projekt sowas auf dem sql-server implementiert und da war die vorgabe meines auftraggebers guids zu verwenden. Auch zusammengesetzte PK's aus ID+MandantID hatte ich schon gesehen.

Bei Interbase oder Firebird wuerde ich das wie folgt realisieren. In der lokalen DB gibts in jeder Tabelle eine Mandant_id bei dem export auf den server wird dann im bevore insert trigger
folgendes gemacht.

sagen wir wir rechnen mit max 100 lokalen DBs

Code:

CREATE TRIGGER TEST_TABELLE_SERVER_BI FOR TEST_TABELLE_SERVER
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
  IF (NEW.ID IS NULL) THEN
    NEW.ID = GEN_ID(GEN_TEST_TABELLE_SERVER_ID,1) || (new.MANDANT_ID*100);
END

jetzt muesste das exportieren funktionieren. Die ID's sind sprechende bezeichner, denn
die id's mit der endung 200 kommen alle vom mandanten 2, die mit endung 9000 vom mandanten 90
usw. Dadurch kann man auch später noch erkennen von welchem mandant die Saetze angelegt wurden. Auch Masterdetail Relationen machen auf den lokalen DB's kein problem, die Reihenfolge beim export wirst du ja sicherlich bedenken.

Jetzt weiß ich nicht was du bei einem export alles machst:
EXPORT = neue lokale Daten exportieren , LOESCHEN und wieder importieren?

Bei dem import koennten daher noch probleme auftauchen.
Jenachdem wie deine export strategie ist. Es wäre auch denkbar die lokalen ID's
stets negativ zu vergeben, somit koennte man auch erkennen, dass diese nie
exportiert wurden.

[Sharky]

Ich werde mir das mal bei einem Bier durch den Kopf gehen lassen :stupid:

Die Variante mit den ID-Bereichen hat nämlich noch einen kleinen Nachteil! Der User kann das Programm ja auf mehreren Rechnern installiert haben. Dann reicht es nicht wenn ich die Bereiche pro User vergebe sondern ich muss sie pro User/Rechner vergeben.
Aber das wäre auch noch machbar.