Eindeutiger Zahlenwert für einen String

[musicman56]

Hallo,

ich muss in eine meiner Datenbanken Daten aus externen Anwendungen (Kontoauszüge aus Banking-Programmen) einlesen, die teilweise keine eindeutige Kennung haben. Also war der Gedanke aus den Daten Auszug-Nr, Konto, BLZ, Verwendungszweck(e) usw. einen String zu bilden, und daraus einen eindeutigen Hash-Wert.

In einem anderen Beitrag in diesem Forum bin ich auch fündig geworden:

Delphi-Quellcode:

// This is a pretty good general purpose string hash function. It is derived
// from the PJWHash and is used inside the UNIX OS

Function HashFromStr(Const Value: String): Cardinal; // ELF-Hash
Var
  i: Integer;
  x: Cardinal;

Begin
  Result := 0;
  For i := 1 To Length(Value) Do Begin
    Result := (Result Shl 4) + Ord(Value[i]);
    x := Result And $F0000000;
    If (x <> 0) Then
      Result := Result Xor (x Shr 24);
    Result := Result And (Not x);
  End;
End;

Dachte ich zumindest...:oops: Es kommen doppelte Hash-Werte heraus. Hat jemand eine andere oder bessere Idee / Routine / Tipp ?

Natürlich könnte ich aus einigen Feldern ein Datenfeld zusammensetzen und indizieren, aber das möchte ich nicht, weil das nur unnötig die Datenbank aufbläht.

[mkinzler]

Ein Hash ist nunmal nicht ein-eindeutig, wie wäre es mit einer GUID?

[DeddyH]

Falls der Zweck des Hashs lediglich die Eindeutigkeit sein soll, wieso dann nicht einen Unique Index über die relevanten Felder bilden?

[mjustin]

Ein Unique Index über alle Felder frisst entsprechend viele Resourcen. Eine synthetische ID (Generator / AutoInc oder die vorgeschlagene GUID) ist sparsamer im Verbrauch.

[DeddyH]

Damit sichert man aber keine Eindeutigkeit der Kombination der Feldwerte, deshalb mein "Falls...".

[himitsu]

Zitat:

Zitat von mkinzler (Beitrag 1116442)

Ein Hash ist nunmal nicht ein-eindeutig, wie wäre es mit einer GUID?

Eine GUID ist es aber auch nicht.

Mit den 128 Bit ist es, im Gegensatz zum ELF-Hash oder CRC32 mit ihren 32 Bit, einfach nur "etwas" unwahrscheinlicher daß sich Werte/Hashs gleichen können.



Um es kurz zu machen:
100%ig eindeutig wäre nur ein vollständiger Binärvergleich, bzw. ein Unique-Index über alles.
Oder du legst dir eine neue Spalte an, welche als Unique-Index entweder fortlaufende (einfacher) oder zufällige Werte (z.B. aus der Einfügezeit und den Daten berechnet, gibt es den wert schon, wird ein anderer zufällig gewählt).

Wenn keine der Daten (der anderen Felder) doppelt sein dürfen und du keinen Index willst, dann wirst du wohl beim einfügen vorher prüfen müssen, ob es das nicht schon gibt.

[stahli]

Schau mal, ob Dich das weiter bringt (insb. #8).

[DeddyH]

Nochmal: welche Absicht steckt dahinter? Geht es lediglich darum, ein eindeutiges Feld zu haben? Dann würde ja ein künstlicher Schlüssel (AutoInc oder derartige Geschichten) vollkommen ausreichen. Soll aber sichergestellt sein, dass ein Hans Meier mit der KtoNr 123546 und BLZ 11122233 nur einmal vorkommen kann, ist IMO ein Unique Index über die 3 Spalten die beste Variante.

[musicman56]

Hallo,

@stahli

Vielen Dank für den "adler"-Tipp. Bei 10.000 Testdatensätzen immer noch 7 Doubletten. Mit der ersten Methode waren es 11. Aber, der Weg scheint erfolgversprechender zu sein. Werde mal weiter testen.

@DeddyH

Zitat:

Soll aber sichergestellt sein, dass ein Hans Meier mit der KtoNr 123546 und BLZ 11122233 nur einmal vorkommen kann, ist IMO ein Unique Index über die 3 Spalten die beste Variante.

Das ist das Ziel. Aber, er (der Hans Meier) kommt natürlich öfter vor, auch eventuell mehrmals am Tag. Darum: Konto-Nr + Bankleitzahl + Verwendungszweck alleine reichen eben nicht aus. Brauche mindestens noch das Datum + Betrag + Auszug-Nummer + Auszug-Seite + Datum/Zeit der Importdatei + Importdatei-Zeilen-Nummer bzw. Datensatz-Nummer dazu. Weil...könnte ja beispielsweise sein, dass eine Auszahlung an einem Geldautomaten am selben Tag zweimal mit demselben Betrag enthalten ist.

Diese Variante würde einen ziemlich großen/langen Unique-Index ergeben, und das möchte ich nach Möglichkeit vermeiden.

[Bernhard Geyer]

Es gibt keine 100% Lösung dafür soviel Infos in 4 oder 8 oder 16 Bytes eindeutig "komprimiert" zu speichern.

Du benötigst mindestens eine Umsetztabelle In der du für jede "Quellfelder" eine selbst generierte (GUID oder AutoInc-Feld) vergiebst du du dann in deinem weitern DB-Modells als Schlüsssel verwendest.