Eindeutige ID aus einem String berechnen

[Bünni]

Die Originalstrings werden bereits gespeichert und etwaige Duplikate schon behandelt.
Die einfachste Umsetzung wäre es das Verzeichnis in den jeweiligen MD5 Hash umzubenennen. Die Benutzerfreundlichkeit sinkt dann aber, weil ein Benutzer nicht mehr auf Anhieb sieht, welches Verzeichnis zu welchem Datensatz gehört.

[Uwe Raabe]

Hast du mal probiert, ob es tatsächlich noch zu Kollisionen kommt, wenn du den CRC an den bereinigten String anhängst?

[Bünni]

Zitat von Uwe Raabe:

Hast du mal probiert, ob es tatsächlich noch zu Kollisionen kommt, wenn du den CRC an den bereinigten String anhängst?

Das kann ich leider später erst testen. Ich bin mir aber sehr sicher, dass es nicht mehr zu Kollisionen kommt.

Zitat:

Wenn in den Strings nur die Großbuchstaben A-Z und die Ziffern 0-9 vorkommen, muss pro Zeichen eigentlich nur ein Wert von 0-35 abgespeichert werden, nicht von 0-255 (AnsiChar) oder gar mehr.

Der Zeichenbereich dürfte wegen Kompatibilitätsgründen eigentlich immer gleich bleiben. Aber es sind dann leider doch ein paar Zeichen mehr die erlaubt sind.

[dummzeuch]

Welche Zeichen können in den Strings denn vorkommen? Ggf. kann durch eine geschickte Kodierung daraus immernoch eindeutige aber deutlich kürzere Binärcodes erzeugen.

Beispiel:

Wenn in den Strings nur die Großbuchstaben A-Z und die Ziffern 0-9 vorkommen, muss pro Zeichen eigentlich nur ein Wert von 0-35 abgespeichert werden, nicht von 0-255 (AnsiChar) oder gar mehr. Damit könnte man 256/36 = > 7 Zeichen in einem Byte abspeichern.

Das ist natürlich nicht ganz ungefährlich, wenn Du nicht sicherstellen kannst, dass sich dieser Zeichenbereich nicht irgendwann ändert. Irgendwann kommt der Chef und sagt, "Wir lassen jetzt auch Kleinbuchstaben und Sonderzeichen zu.", und schon fliegt Dir der Algorithmus um die Ohren. Und erfahrungsgemäß wird der Programmierer bei solchen Entscheidungen nicht vorher gefragt.

EDIT: Ich sehe gerade, dass es im Ergebnis um Verzeichisnamen geht. Damit kann man meine Idee nicht mehr so einfach umsetzen.

[Redeemer]

Zitat von dummzeuch:

Welche Zeichen können in den Strings denn vorkommen? Ggf. kann durch eine geschickte Kodierung daraus immernoch eindeutige aber deutlich kürzere Binärcodes erzeugen.

Beispiel:

Wenn in den Strings nur die Großbuchstaben A-Z und die Ziffern 0-9 vorkommen, muss pro Zeichen eigentlich nur ein Wert von 0-35 abgespeichert werden, nicht von 0-255 (AnsiChar) oder gar mehr. Damit könnte man 256/36 = > 7 Zeichen in einem Byte abspeichern.

Das ist auf so viele Arten und Weisen einfach nur falsch:

• Der Zeichenvorrat beträgt nicht 256. Wenn man von ANSI ausgeht, liegt die Anzahl der Zeichen bei etwa 215 (unter Abzug von neun sichtbaren nicht erlaubten Zeichen und 32 Steuerzeichen).
• Der Zeichensatz von NTFS ist aber UTF-16. Da man UTF-16-Codepunkte nicht beliebig aneinanderreihen kann, muss man stattdessen UCS-2 verwenden. Von dessen 63.488 Zeichen zieht man dann wieder die 41 ab. Ich würde mal vermuten, dass man auch hier nicht alle Zeichen verwenden kann, aber es geht um die Größenordnung.
• Und das schlimmste: Man kann nicht einfach dividieren. Korrekt wären also für ANSI lb(215)/lb(36), was nur ganz knapp unter 1,5 ergibt. Für UCS-2 ergibt sich mit lb(63447)/lb(36) erwartungsgemäßg gut das Doppelte (ca. 3,09). Von deiner 7 ist man sehr sehr weit entfernt.

(Edit: Natürlich kann man statt lb auch ln oder lg rechnen. lb ergibt aber am meisten Sinn, da man so sofort erkennt, dass es hier um die Entropie (in Bit) geht, die sich damit ergibt. Und das Verhältnis der Entropien ist ja anschaulich das, worum es dummzeuch ging.)

[peterbelow]

Zitat von Bünni:

Die Originalstrings werden bereits gespeichert und etwaige Duplikate schon behandelt.
Die einfachste Umsetzung wäre es das Verzeichnis in den jeweiligen MD5 Hash umzubenennen. Die Benutzerfreundlichkeit sinkt dann aber, weil ein Benutzer nicht mehr auf Anhieb sieht, welches Verzeichnis zu welchem Datensatz gehört.

Mal eine Bemerkung dazu, die vielleicht etwas off -topic ist. Für einen Benutzer ist das Ablegen von Datensätzen in Dateien mit langen Namen ein usability-Alptraum, egal ob Du nun noch eine ID anhängst oder nicht. Hast Du mal versucht, in einem Verzeichnis mit mehreren Hundert Dateien mit langen Namen etwas zu finden? Das geht eigentlich (im Explorer) nur mit der Suchfunktion, alles andere ist eine Strafe, besonders, wenn die Namen auch noch so lang sind, dass sie im Explorerfenster abgeschnitten werden.

Häng die ID an, das macht es auch nicht viel schlimmer als es eh schon ist.

[Bünni]

Die Verzeichnisse werden jetzt nach einem MD5 Hash benannt. Das war die einfachste Umsetzung, ohne dass man noch an anderen Stellen Anpassungen machen muss die bei jeder kleinen Änderung hinfällig sind. Eigentlich hat ein Nutzer in diesen Daten nichts zu suchen, da alles über die Benutzeroberfläche und Business Logik erledigt wird.

[TurboMagic]

Schon mal nach alternativen Hash Algorithmen als MD5 geschaut? Es gibt auch welche die nur 64 bit oder 80 bit lange Hashes erzeugen.

DEC beispielsweise enthält die Klasse THash_Sapphire, welche einen Hash Algorithmus umsetzt, der 64 bit Ergebnisse produziert.
DEC ist via Github hier zu finden: https://github.com/winkelsdorf/Delph...tionCompendium

[jfheins]

Zitat von Bünni:

Die einfachste Umsetzung wäre es das Verzeichnis in den jeweiligen MD5 Hash umzubenennen. Die Benutzerfreundlichkeit sinkt dann aber, weil ein Benutzer nicht mehr auf Anhieb sieht, welches Verzeichnis zu welchem Datensatz gehört.

Ich würde mich da an vorhandenen Lösungen orientieren. git zum Beispiel speichert alle Objekcte unter ihren SHA1 Hash-Werten. Das heißt, ein Objekt hat den Hashwert d670460b4b4aece5915caf5c68d12f560a9fe3e4 und wird dann unter dem Dateipfad .git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 abgelegt.

Macht insg. maximal 256 Ordner und darin dann viele Dateien, im Falle von git meistens mit SHA-1 (wird aber umgestellt glaub ich).

Das Argument "Eigentlich hat ein Nutzer in diesen Daten nichts zu suchen, da alles über die Benutzeroberfläche und Business Logik erledigt wird." ist super, wenn eh alle in der Anwendung abrufbar ist, fummeln User in einer zugänglichen Datenstruktur nur zuviel rum.

[Jasocul]

Vielleicht ein wenig OT aber vielleicht doch relevant:

Zitat von Bünni:

Die Benutzerfreundlichkeit sinkt dann aber, weil ein Benutzer nicht mehr auf Anhieb sieht, welches Verzeichnis zu welchem Datensatz gehört.

Der Benutzer kann dirket auf die Verzeichnisse zugreifen?
Das halte ich für nicht ganz ungefährlich. Vielleicht gefällt dem Benutzer ja der Verzeichnisname nicht und er ändert den. Die Konsequenzen für deine Anwendung kannst nur du abschätzen.

Zitat von Bünni:

Jeder Datensatz hat intern einen Index, der sich aber bei jedem Programmstart ändern kann je nachdem, ob die Daten verändert wurden oder nicht. Im Normalfall ist davon auszugehen, dass sich die Daten bei jeder Sitzung mindestens einmal stark ändern.

Der Index (oder besser die ID) eines Datensatzes sollte man nicht ändern. Der Index in deinem TreeView, wo du möglicherweise deine Daten einliest, hat mit dem Datensatz absolut gar nichts zu tun.

Wenn deine Datensätze eine eindeutige ID haben, dann nutze diese. Wenn nicht, dann erzeuge dir welche. Damit bist du dein Problem sofort los, da du die ID für die Verzeichnisse nutzen kannst.
Ich kenne deine Anwendung nicht, aber die Nutzung dieser Verzeichnisse sollte nur über die Anwendung passieren. Sobald ein Anwender darin rumpfuschen kann, wird das auch passieren. D.h.: Die Verzeichnisnamen müssen (besser dürfen) für den Anwender nicht lesbar sein. Sobald diese lesbar sind, werden diese "verbessert".

EDIT:

Zitat von Bünni:

Anhand des Strings wird ein Verzeichnis angelegt. Der String wird vorher aber bereinigt und unzulässige Zeichen und andere besondere Zeichen entfernt.
Es gibt Konstellationen, da bleibt am Ende das gleiche Ergebnis übrig. Deswegen würde ich gerne eine ID hinten dranhängen

Wenn du es denn wirklich so machen willst, ist es ziemlich egal, welche Mehode du verwendest, da der String selbst ja ein Teil des Verzeichnisnamens ist. Ein angehänges crc, Hash oder sonstwas wird es dir eindeutig machen. Die Gefahr, das zwei verschiedene Strings die selbe "ID" erzeugen macht gar nichts, da der String auch Teil des Names ist.