Eindeutige Zufalls-ID

Computer: Software & Programmierung SQL & Datenbank - Programmierung
#1

Hallo zusammen

Ich habe einen Trigger (MS-SQL 2000) geschrieben, welcher bei einem Insert eine Zufallszahl erzeugt, diese auf Eindeutigkeit innerhalb der Tabelle testet und sie dann mit einem UPDATE speichert.

Soweit so gut. Das Problem ist bloss, dass ich 2 Mio Sätze erstellen muss und das Teil ist extrem langsam … in einer Nacht hat es bloss 80’000 sätze erstellt und logischerweise wird es auch immer langsamer, weil ja immer mehr Sätze geprüft werden müssen.

Gibt es eine schneller Variante, um 2 Mio 12-stellige Zufallszahlen zu erzeugen und in einer Tabelle zu speichern?

Danke und Gruss
Martin

#2

Hi Martin,

Ich habe einen Trigger (MS-SQL 2000) geschrieben, welcher bei
einem Insert eine Zufallszahl erzeugt, diese auf Eindeutigkeit
innerhalb der Tabelle testet und sie dann mit einem UPDATE
speichert.

Ähm - reicht das nicht mit einem Zähler? In MSSQL haißt das glaub ich Identity. Das ist eine Eigenschaft einer Spalte numerischen Inhalts, die vom DBMS automatisch bei jedem Insert um eins erhöht wird. Das System garantiert, daß es eindeutig bleibt.

Willst oder kannst Du darauf nicht zurückgreifen, läßt sich das auch anders regeln. Beispielsweise könntest Du eine Tabelle mit 3 Millionen durchgängig numerierten Datensätzen erstellen, Dein Trigger würde jeweils den kleinsten nehmen (min(spalte)), verwenden und gleich anschließend löschen. Somit würde die Überprüfung der vorhandenen Sätze entfallen.

Gruß

J.

#3

Hallo José

Ähm - reicht das nicht mit einem Zähler? In MSSQL haißt das
glaub ich Identity. Das ist eine Eigenschaft einer Spalte

Leider nein, ich habe eine Spalte Identity, welche raufgezählt wird … aber dann benötige ich zusätzlich noch eine Spalte mit einer 12-stelligen eindeutingen Zufallszahl.

Gruss
Martin

#4

Hi,

Leider nein, ich habe eine Spalte Identity, welche raufgezählt
wird … aber dann benötige ich zusätzlich noch eine Spalte
mit einer 12-stelligen eindeutingen Zufallszahl.

Dann solltest Du Dein Datenmodell überdenken. Zwei Spalten, die jeweils unabhängig voneinander eindeutig sind, machen in den allerwenigsten Fällen Sinn (Normalisierung).
Aber auch so dürfte mein zweiter Vorschlag gangbar sein.

Gruß

J.

#5

Hallo José

Die chronologische ID benötige ich für die interne Kommunikation, die Zufallszahl wird gegen aussen kommuniziert. Damit kann keine Reihenfolge abgeleitet werden und trotzdem sind die Tickets (sorry habe ich vorhin nicht geschrieben) trotzdem eindeutig zuweisbar.

Deine Lösung ergibt leider keine Zufallszahl, sondern einfach eine andere chronologie …

Mein Hauptproblem ist, dass ich zwar eine Lösung hätte, sie ist aber viel zu langsam. In 14 Stunden hat das System lediglich 80’000 Sätze generiert … was ja auch klar ist, da zu jedem Insert auch noch ein Select zur Prüfung und dann noch ein Update gemacht werden musste.

Gruss
Martin

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#6

Deine Lösung ergibt leider keine Zufallszahl, sondern einfach
eine andere chronologie …

Stimmt.

Mein Hauptproblem ist, dass ich zwar eine Lösung hätte, sie
ist aber viel zu langsam.

Hmmm. Muß die zweite Zahl eine Zahl sein? Evtl. könntest Du stattdessen einen MD5-Hash nehmen. Angewandt auf den Tabellenindex ergibt das (ziemlich) wahrscheinlich einen eindeutigen Wert, der aber keinen Rückschluß auf die Reihenfolge erlaubt. Der Rest ginge wie gehabt mit Löschen des Datensatzes.
Irgendwo hatte ich eine MD5-Implementierung gefunden, ansonsten gibt es sicher noch eine gleichwertige Hashfunktion in den Niederungen des DBMS zu finden…

Gruß

J.

#7

Hi

Erstelle in der Tabelle eine Spalte von Typ „uniqueidentifier“ setze dann die eigenschaft „Is RowGUID“ = True

GUID sind immer Eindeutig und mit der Option Is RowGUID werden diese auch Automatisch generiert

Gruss

Giuseppe

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#8

Mein Hauptproblem ist, dass ich zwar eine Lösung hätte, sie
ist aber viel zu langsam. In 14 Stunden hat das System
lediglich 80’000 Sätze generiert … was ja auch klar ist, da
zu jedem Insert auch noch ein Select zur Prüfung und dann noch
ein Update gemacht werden musste.

Ich finde die bereits genannten Lösungen (Hash oder GUID) zwar besser, aber wenn du an deinem Algorithmus festhalten willst, dann könntest du ihn optimieren in dem du einen Unique Index über das Feld erzeugst, und dann ein einfaches INSERT mit der Zufallszahl machen. In den meisten Fällen wird es gut gehen, wenn nicht, dann fängst du den spezifischen Fehlercode der durch das Verletzen des Unique Index ausgelöst wurde ab und probierst ein INSERT mit einer anderen Zufallszahl.

Damit ersparst du dir das SELECT und UPDATE das du scheinbar bei jedem Datensatz durchführst, und bei 99 % der Fälle bleibt es dann wahrscheinlich bei dem einen INSERT.

Grüße, Robert

#9

PLAGIAT
„Ich habe einen Trigger (MS-SQL 2000) geschrieben…“

Na Martin, wer hat den Trigger geschrieben???

:wink: Stefan.

#10

Ich sehe zwar den Zusammenhang zu einem Plagiat nicht ganz … aber habe das Problem jetzt sowieso anders gelöst.

Gruss
Martin

„Ich habe einen Trigger (MS-SQL 2000) geschrieben…“

Na Martin, wer hat den Trigger geschrieben???

:wink: Stefan.