danke, aber ich habe das Gefühl du trollst oder liest dir garnicht durch was das Problem ist.
Wie soll ich mit deiner „Lösung“ beim anlegen des 2. Lieferscheins noch wissen welche „Nummer“ der erste Lieferschein des selben Kunden hat, ohne dass ich irgendwie dessen Namen abspeichere (und die Idee ist hier in pseudonymisierter Form, da Klartext nicht in Frage kommt)
Wenn man’s braucht, schon, ich finde deine Vorgehensweise nur unnötig kompliziert.
Wobei ich gerade lese
und das finde ich schon wieder etwas seltsam: du willst Kundenkürzel und Geburtsdatum in einer verschlüsselter Form im Dateinamen speichern, so dass du die selbst nicht mehr entschlüsseln kannst, und im Lieferschein selbst fehlen auch Kundenname und -anschrift.
Aber du speicherst doch den Namen gerade auch so, dass du gar nicht mehr weißt, zu wem der Lieferschein gehört, das hattest du selbst weiter oben geschrieben, oder hast du schon vergessen, was du alles erzählt hast??
Nochmal zur Erinnerung:
Dann ist doch SCH-egal, wie die Dateien heißen, solange du anhand des Dateinamens feststellen kannst, welche zwei Dateien zusammengehören.
Fragt sich hier, wer rumtrollt. 
@Chrita: Danke für deine erneute Mühe eine Antwort zu verfassen, ich weiß aber nicht, warum du diese Kritischen Töne als Kommentar auf dem Post setzt in dem ich mich bei den Mitgliedern mit den besten Antworten bedanke.
Auch bringen mich deine hypothetischen Diskussionen anderer Szenarien die nicht viel mit meinem Anliegen zu tun haben nicht weiter, werde daher nicht mehr auf deine Nachrichten eingehen.
Meine 3 Hauptfragen wurden bereits von anderen Mitgliedern beantwortet - nochmal herzlichen Dank an euch beide
Du scheinst dir selbst über dein Anliegen nicht im Klaren zu sein, aber ich sehe es auch nicht mehr als notwendig, dir das klar zu machen. Irgendwas wirst du schon machen!
Du legst also Lieferscheine an, die keine Kundendaten enthalten. Und das aufgrund einer anonymen Bestellung, von der du nicht weißt, was bereits geliefert wurde, weil das ausschließlich auf dem nicht mehr erkennbaren alten Lieferschein steht. Und schickst die Ware dann ins Nirwana, weil du weder den Kunden noch seine Adresse kennst?
Willst du uns hier verarschen oder was?
Du legst also Lieferscheine an, die keine Kundendaten enthalten.
->Ja, demnächst schon.
Und das aufgrund einer anonymen Bestellung,
-> nein, und von Bestellung war nie die Rede, nur von Lieferscheinen
von der du nicht weißt, was bereits geliefert wurde, weil das ausschließlich auf dem nicht mehr erkennbaren alten Lieferschein steht.
->Der Lieferschein ist nicht „nicht erkennbar“ sondern pseudonymisiert, damit ist der Kundenname rekonstruierbar. Natürlich steht auch drauf was geliefert wurde, sonst wäre es ein leerer Zettel. Zukünftig soll der Name aber nicht mehr allein aus dem Lieferschein rekonstruierbar sein (Anforderung des Chefs, nicht meine)
Und schickst die Ware dann ins Nirwana, weil du weder den Kunden noch seine Adresse kennst?
->Interessant was du dir alles zusammenreimst, aber nein ich bin bei der Auslieferung sogar selbst immer dabei und hatte noch keinen Kundentermin im Nirvana
Willst du uns hier verarschen oder was?
->Wenn du das Anliegen nicht verstehst frag gerne nochmal nach, oder verkneife dir den Beitrag. Wenn du dich nur verbal auskotzen willst mach es doch bitte nicht in diesem Forum. Denn es heißt wer-weiß-was und nicht wer-beschimpft-wen
Allen anderen: keep on surfin’ 
Du redest aber schon von den Lieferscheinen und nicht von den Kunden"daten" im Dateinamen, ja?
Wie denn das? DU warst derjenige, der gesagt hat, ich zitiere dich schon zum dritten Mal:
und weiter auch:
ICH habe mehrfach nachgefragt, aber nur Herumgeeiere statt Antworten bekommen.
Ich bin jetzt raus, freu dich! 
Ich hatte die gleichen Gedanken wie Du.
Scheint mir so ein typischer Fall aus der Praxis zu sein, wo ich immer denke: Warum einfach, wenn’s auch kompliziert geht…
Beatrix
Hallo!
Mal was anderes:
Warum lehnst du die GUID so schnell ab? Letztendlich ist eine GUID eine ziemlich zufällig aussehende Nummer, aus der daher kaum was rekostruiert werden kann. Damit ein und die gleiche GUID nicht zufällig zwei mal erzeugt wird, ist aber ein Zeitstempel drin. Und damit nicht zwei Server zufällig zur gleichen Zeit die gleiche GUID erzeugen, ist ein weiteres pro Server eindeutiges Merkmal drin. Dafür hat man gerne die MAC-Adresse („Seriennummer“ der Netzwerkkarte) genommen, aber dann ließe sich die GUID ja auch wieder zu dem erzeugenden Server zurück verfolgen. Daher die Sache mit dem Registrar, um eine zufällige, aber eindeutige ID für den Rechner zu bekommen. Eigentlich braucht man nur dann einen größeren, und dann sicher kostenpflichtigen Registrar, wenn z.B. viele unabhängige Unternehmen miteinander Daten austauschen wollen, in denen eben GUIDs verwendet werden.
Aber das brauchst du vermutlich alles gar nicht, und der (etwas) kleine Bruder der GUID, die UUID, reicht vollkommen aus.
Die G/UUID enthält keinerlei Informationen über den Kunden oder die Lieferung, für die sie erzeugt wurde. Und: eine UUID können die meisten Datenbanken einfach so erzeugen, dafür braucht es kein Tool. (Ihr habt doch ne Datenbank für Kundendaten/Bestellungen, oder?)
Einziger Nachteil: Für den Menschen einfach zu lesen, oder gar zu merken sind die Dinger nicht:
413b9074-4ecc-4533-9b28-9de812bac4c0
Man könnte zwar sagen, daß man aus dem Zeitstempel der G/UUID und der Datenbank, die sicher die Bestellzeit enthält herausfinden kann, zu wem jetzt ein Dokument gehört. Aber da die G/UUID einen zufälligen Charakter hat, muß man sie eh in der Datenbank speichern.
Vielleicht noch ne andere Idee:
Ich kenne Passwortgeneratoren, die keine kryptischen und kaum zu merkenden Passworte generieren, sondern Passwörter aus Silben, die zusammen aussehen wie Wörter, und für den Menschen einfacher zu verarbeiten sind. Aber auch da muß man sich Gedanken machen, daß man kein Passwort zwei mal erzeugt. Ich wüßte dafür grade auch kein Tool.
Entschuldigung, falls ich mich hier unberechtigt einmische, aber (und Du verstehst mathematische Notation) es geht um ein f, so dass:
f(x,t1) = f(x,t2) für Zeiten t1 und t2
sowie
f(x,t) != f(y,t) => x != y
die Rückrichtung soll oft auch gelten (Kollisionsfreiheit).
Ich sehe nicht, wie ein GUID-Generator oder irgendein PRNG diese Forderungen bewerkstelligen können.
Hallo!
Naja, vielleicht hab ich mich falsch ausgedrückt.
Eine Hash-Funktion ist surjektiv, das heißt, es besteht die Möglichkeit, daß zwei Kunden den gleichen Hash haben. Und zu wem gehören die Dokumente dann?
Außerdem könnte man alleine mit den Dokumentennamen dann per Rainbow-Table die Kundendaten ermitteln. Zwar wird man da auch viele Treffer landen, die wenigsten werden aber wie „Vorname Nachname“ aussehen.
Das andere ist eben sowas wie eine UUID. ich habe mal geschaut, MySQL generiert UUIDs nach Version 1, das sind letztendlich hochpräzise Zeitstempel plus MAC-Adresse. Sollen in schneller Folge UUIDs erzeugt werden, und die Rechnerzeit mit ihrer 1ms-Auflösung ist noch gleich, addiert der Generator einfach 100ns drauf. Und wenn die Uhr mal nachgehen sollte, gibts nen Extra-Zähler, der dann hoch gesetzt wird. Also ja: eine UUID ist immer eindeutig, wenn sie vom gleichen Generator kommt, oder zumindest mehrere Generatoren nicht zeitgleich eingesetzt werden.
Und natürlich muß die UUID in der Kundendatenbank gespeichert werden, wie ich schrieb, können MySQL & Co sowas sogar selbst. Und daß von den Kundendaten aus auf die zugehörigen Dokumente geschlossen werden kann, muß ja möglich sein, und es ist nicht gefordert, daß das nicht geht.
Ok, Du hast Recht, GUIDs zusammen mit einer Zuordnung erfüllen auch alle Forderungen, die "Hash"funktion wäre dann von der Form add_or_get(initialen, geburt), die bei Bedarf GUIDs generiert oder eine bereits vorhandene GUID wieder zurückgibt. Dieses Setup wäre auch streng kollisionsfrei.
Ach, zum Thema kollisionsfrei: Du meintest (und ich auch in Gleichung 2) Injektivität bzw. daß diese verletzt ist. Surjektivität ist weder notwendig noch hinreichend für eine Kollision. h(x) = x ist surjektiv (über Z) und hat keine „Kollisionen“. h(x) = 0 (über Z) ist nicht surjektiv und hat maximal viele „Kollisionen“. Gilt auch in endlichen Strukturen, Z/nZ z.B.
Ich finde die Variante mit den Hashes trotzdem eleganter. Man braucht die Datenbankkomponente nicht, muß sich also insbesondere nicht um deren Wartung, Sicherheit und Backup kümmern, man muß auch nichts programmieren. Und im Super-GAU-Fall, Daten weg, Code weg, kann man sich mit 'nem Taschenrechner (oder sehr viel Papier) hinsetzen und trotzdem die Dateinamen rekonstruieren.
Hi!
Ja, beides hat seine Reize. Ich finde es nett, daß man mit drei Klicks der Datenbank sagen kann, daß die Kundentabelle ne Spalte mit uuids haben soll, und dass diese automatisch gefüllt werden soll.
Klar, die Hashes kann man neu berechnen. Aber wenn die Datenbank kaputt ist, sind wohl auch due Ausgangsdaten weg, und in dieser Firma werden die offensichtlich nirgendswo anders gespeichert.
(was wohl passiert, wenn das Finanzamt einen Blick da rein werfen will?)