[Erledigt] Eindeutige ID in Mehrbenutzerungebung

[eiko]

Hallo alle Zusammen,

ich möchte mehrere Datensätze über eine TMsSqlConnection in eine MS-SQL-Datenbank schreiben,
welche alle eine gemeinsame ID haben sollten.

Eine Möglichkeit dazu wäre:
- letzte benutzte ID aus einer Tabelle auslesen
- ID inkrementieren und verarbeiten
- neuen Stand der ID in die Tabelle zurückschreiben

Problem dabei, genau in diesem Moment könnte eine andere Anwendung auch auf diese ID zugreifen und somit wäre die erhaltene nicht mehr eindeutig!

Ich habe versucht die Zeit zwischen Lesen und Zurückschreiben über eine Transaction zu sperren, bin aber leider bisher daran gescheitert.

Darum hier die Frage:
Hat jemand eine Tipp wie ich den gleichzeitigen Zugriff auf das Feld verhindern kann
oder gibt es vielleicht eine ganz andere Lösung für mein Problem?


Grüße eiko

[mschnell]

Ich habe versucht die Zeit zwischen Lesen und Zurückschreiben über eine Transaction zu sperren, bin aber leider bisher daran gescheitert.

Das muss gehen !
-Michael

[eiko]

Das muss gehen !

Dachte ich auch,
aber irgendwie mach ich wohl noch was falsch.

Ein funktionierendes Beispiel wäre vermutlich hilfreich.

Grüße eiko

[Warf]

Warum verwendest du nicht einen automatisch inkrementierten Primary Key?

um die neue ID auszulesen hab ich das gefunden: Link. Führe beide queries auf einmal aus dann brauchst du dich nicht mal um das sperren zu kümmern (obwohl das die Transaktion eigentlich machen sollte, keine ahnung was du da falsch machst).

Ansonsten ist es oftmals eventuell auch nützlich einfach zufallsgenerierte ID's zu haben. Bei webanwendungen wird das gerne gemacht, sodass selbst wenn man eine sicherheitslücke haben sollte bei der man mit der ID an Nutzerdaten kommt, man nicht gezielt nach ID's suchen kann.

[af0815]

Selbst eine guid erzeugen und diese verwenden. Wie eindeutig muss der Key sein ?

[Warf]

Selbst eine guid erzeugen und diese verwenden. Wie eindeutig muss der Key sein ?

Selbst wenn sie eindeutig sein muss, die Chance ist so niedrig das man bei einer langen guid eine Kollision hat, dass man das einfach über eine exception Bein insert handeln kann (vorausgesetzt die ID ist unique im sql definiert)

[af0815]

Der automatische inkr. PK ist nur Tabellen uique. Die Frage ist, muss der DB unique, Serverunique oder auch für Replikationen geeignet sein.

[Warf]

Der automatische inkr. PK ist nur Tabellen uique. Die Frage ist, muss der DB unique, Serverunique oder auch für Replikationen geeignet sein.

Ja klar, aber mal ne ganz dumme Frage, wofür braucht man DB oder Server Unique ID's? Mir fällt grade kein Use Case dafür ein und hab sowas auch noch nie gesehen

[af0815]

Versuch mal eine DB bzw. Teile davon zu verteilen und auch über mehrer Standorte zu replizieren. Zusåtzlich noch ein paar Roadwarriordaten einzupflgen. Dann wird es langsam interessant.
Auch wenndu Daten auf verschiedenen Quellen zusammenführst und wieder trennst. Bsp. Filialen, die verteilt Buchen und von Zeit zu Zeit ihre Daten abgleichen.

[eiko]

Erstmal Danke an alle fürs mitdenken!

Eine eindeutige ID für jeden einzelnen Datensatz lasse ich schon von der DB erzeugen,
das ist nicht das Problem.

Ich möchte aber noch mehrere Datensätze zu einer Gruppe zusammenfassen,
dies soll über eine gemeinsame Gruppen-ID geschehen.
Diese eindeutige Gruppen-ID zu erzeugen ist grad mein Problem!
Soweit ich weiß geht das nicht über die DB.

Die IDs müssen nur in dieser Tabelle eindeutig sein,
also nicht auf Serverebene oder gar weltweit.

Grüße eiko

[mschnell]

Wie eindeutig muss der Key sein ?

Eindeutig zweideutig oder nur zweideutig eindeutig ?
Also wie IPv6.
-Michael

[af0815]

Ich möchte aber noch mehrere Datensätze zu einer Gruppe zusammenfassen,
dies soll über eine gemeinsame Gruppen-ID geschehen.
Diese eindeutige Gruppen-ID zu erzeugen ist grad mein Problem!

Gedanklich nimm ganz einfach als ID den PK des ersten Datensatzes den du zu einer Gruppe formen willst. Damit ist das in der Tabelle eindeutig.

Code: Alles auswählen

Bsp:
PK   Grp  Info
01   01   Test1 gehört zu Gruppe 01
02   02   Test1 gehört zur Gruppe 2
03   02   Test1 gehört zur Gruppe 2
05   05   Test1 gehört zu keiner Gruppe, da sonst die ID nicht vorhanden ist
06   01   Test1 gehört zur Gruppe 1
07   07   Test1 gehört zur Gruppe 1
08   04   Test1 gehört zu keiner Gruppe, da sonst die ID nicht vorhanden ist, war aber früher in Gruppe 4
 

Damit kann keine GruppenID IMHO doppelt vorkommen. Weil du die Gruppen ID immer von einem PK ableitest. Wenn umgruppiert wird, dann brauchst du dir ja nur den richtigen PK heraussuchen.

[Warf]

Das klassische verfahren hierfür ist die verwendung von Primary Keys und referenzen mit Foreigh Keys.
Kleines Beispiel für Nutzer und Nutzergruppen (bin nicht so gut mit SQL, daher nicht wundern über kleinere fehler)

Code: Alles auswählen

CREATE TABLE Users (
  ID int NOT NULL AUTO_INCREMENT,
  Name varchar(30) NOT NULL,
  PRIMARY KEY (ID)
);
 
CREATE TABLE Groups(
  ID int NOT NULL AUTO_INCREMENT,
  Name varchar(30) NOT NULL,
  PRIMARY KEY (ID)
);
 
CREATE TABLE UserGroups(
  UserID int NOT NULL,
  GroupID int NOT NULL,
  // Andere daten, z.B. Berechtigungen
  FOREIGN KEY(UserID) REFERENCES Users(ID),
  FOREIGN KEY(GroupID ) REFERENCES Groups(ID),
  CONSTRAINT PK_UG PRIMARY KEY (UserID ,GroupID)
);

Durch den Foreign key wird sicher gestellt das der wert der in dieser Spalte steht eine exsistierende ID aus Groups bzw. Users sein muss, durch den Primary Key in der UserGroups wird sichergestellt das jeder Eintrag (Nutzer, Gruppe) einmalig ist, außerdem falls man access level oder sowas in dieser DB noch speichert wird diese dazu nach diesem Tupel geindext (was suchen darauf schneller macht).

[eiko]

Erstmal Danke an alle fürs Mitdenken!

Ich hab das jetzt so wie von euch angeregt umgesetzt,
indem ich die ID des ersten Datensatzes auslese und diese dann als gemeinsames Kennzeichen weiterverwende!

Problem ist gelöst!

Danke eiko