Eineindeutigen Schlüssel generieren - wie?

[Martin Altmann]

Hallo allerseits,
ich stehe vor dem Problem, einen eineindeutigen Schlüssel generieren zu müssen, ohne prüfen zu können, ob es ihn schon gibt.
Wie geht man da am besten vor?
Meine Überlegungen bisher:
Datum und Uhrzeit, wobei bei der Uhrzeit auch Hundertstelsekunden berücksichtigt werden müssen (das zwei Leute zur selben Sekunde auf einen Knopf drücken, ist realistisch - zur selben Hundertstel eher nicht).
Daraus folgt:
3112200723595999
Sind insgesamt 16 Zeichen und viel zu lang zum späteren Eingeben.
Also habe ich mir überlegt, auf das Jahrhundert zu verzichten (in 93 Jahren interessiert mich das eh' nicht mehr...)
31120723595999
Aber auch 14 Zeichen sind noch zu viel.
Nächste Idee: Jahr und laufender Tag:
0736523595999
Wieder ein Zeichen gespart, aber immer noch zu viel.
Aber nach dem selben Prinzip bei der Uhrzeit: Wenn diese in Hundertstelsekunden umgerechnet wird, erhält man:
073658640000
Nun sind wir mittlerweile bei 12 Zeichen - noch zu lang!
Also eine andere Basis bei der Darstellung gesucht und umgerechnet. Als Basis die höchstmögliche: 36 (Ziffern 0-9 und Buchstaben A-Z). Somit sind maximal 8 Zeichen nötig (ZZZZZZZZ ist Dezimal: 2821109907455)
Acht Zeichen geht auch bequem einzugeben.

Oder sehe ich das zu kompliziert?
Habt ihr eine bessere oder einfachere Idee?

Viele Grüße,
Martin

[Krause]

Hallo Martin,

dieses Problem haben wir anders gelöst. Wir halten in einer Datenbank beliebig viele standardisierte zentralen Counter. So gibt es zum Bsp. einen (normal darstellbaren) Tagescounter:

YYMDxxxxxx

YY - Jahr (zum Bsp. 07 etc)
M - Monat (A (Januar) - L (Dezember))
D - Tag, 1-9, A- max. V (der 31. -te))
Counter 0 - 999999

man kann also pro Tag 1.000.000 unikate Werte bilden (zum Bsp. Timestamp). Dadurch, das der Counter in einer Datenbank abgebildet ist, kann man eine wirklich absolute Einmaligkeit der Werte realisieren. Nebenbei schreiben wir auch noch in manchen Fällen eine so genannte "Historyfile", wer hat wann einen Wert für was generiert. Diese File kann auch zur zusätzlichen Überprüfung der Einmaligkeit der Werte genutzt werden (zum Bsp. Rechnungsnummern) ...

Mit freundlichen Grüßen
Joachim Krause

[brandelh]

Hallo Martin,

also auf jeden Fall würde ich DtoS() verwenden und nicht DtoC()

20070127045612 sieht einfach besser aus

Du könntest diese Zahl in HEX umwandeln, das wäre im Beispiel F0CB0BEC (laut HEX$ aus PowerBasic). 8 Zeichen zur bekannten Basis 16.
Somit müsste bei der Basis 36 das Ergebnis kürzer sein.

[Martin Altmann]

Hallo Hubert,
das optische ist mir recht egal, da die Erzeugung relevant ist - man muß nicht unbedingt entschlüsseln können. Außerdem fehlten bei Deinem Beispiel zwei Stellen - die Hundertstel.

Hallo Joachim,
hatte ich auch erst gedacht. Aber ich will nicht mit so viel Datenbanken im Hintergrund arbeiten.
Das ganz soll auf meinem Webserver laufen. Sobald der Kunde fertig ist mit allem, bekommt er seine "Nummer" und das ganze wird bei ihm ausgedruckt. Dann kann ich mich in Ruhe um das Ablegen im Archiv kümmern.
Webserver bedeutet halt auch, dass belibig viele Threads parallel laufen können...

Viele Grüße,
Martin

[AUGE_OHR]

hi,

Sind insgesamt 16 Zeichen und viel zu lang zum späteren Eingeben.

wie Huber anmerkte könnte man die Daten ja "komprimieren", aber
dann hast du andererseitz bei der Eingabe ein Problem ("F0CB0BEC")

auch würde ich dann Problem bei "Filtern" oder SCOPE sehen ...

vielleicht solltest uns sagen wie und wofür du den "unique" Key brauchst ?

gruss by OHR
Jimmy

[Martin Altmann]

Hallo Jimmy,
gerne.
Über meinen Webserver können Leute ihre Hunde zu diversen Hundeausstellungen melden.
Wir haben uns jetzt überlegt, ihnen die Sache zu vereinfachen. Wird ein Hund gemeldet, bekommt er automatisch eine eineindeutige Kennzeichnung und wird in einer Archivdatei abgelegt.
Beim nächsten Mal kann er ganz einfach nur durch Eingabe dieser eineindeutigen Kennzeichnung (und ein bis zwei weiterer Angaben zur Kontrolle) erneut gemeldet werden.
Die Nummer darf erst zugeordnet werden, wenn der Hund auch wirklich gemeldet wird - also ganz am Ende des Prozesses. Wenn der Eingebende fertig ist, werden alle seine gemeldeten Hunde bei ihm ausgedruckt - zu diesem Zeitpunkt müssen dann auch die "Nummern" zugewiesen werden - und die Hunde in der Datei für die betreffende Schau abgelegt sowie in das Archiv übernommen (bzw. - falls dort bereits vorhanden - überschrieben) werden.
Ich persönlich finde es einfacher, bis zu 8 Buchstaben/Ziffern einzugeben, als 16 Ziffern.

Viele Grüße,
Martin

[brandelh]

Hallo Hubert,
das optische ist mir recht egal, da die Erzeugung relevant ist - man muß nicht unbedingt entschlüsseln können. Außerdem fehlten bei Deinem Beispiel zwei Stellen - die Hundertstel.

Hallo Martin,

das mit den vergessenen Hunderstel ist allerdings peinlich , aber die Aussage, dass du zuerst zurückliefern und dann speichern willst funktioniert so auch nicht. XB2NET läßt dass zwar technisch sicherlich zu, aber erst wenn du gespeichert und zuvor eventuell auch nachgesehen hast ob es den Hund schon gibt (es soll DAUS geben) kannst du sicher sein, dass der Rückgabewert stimmt.

Aber das ist doch kein Problem oder ?
Schreibe dir die Funktion mit dem 36er System und gut ist.

[Martin Altmann]

Hallo Hubert,
doch, das funktioniert.
Gibt der Meldende eine solche Schlüsselfolge ein, wird der passende Hund gesucht und angezeigt.
Dadurch, das ich am Ende dann keinen Schlüssel generieren muß, weiß ich, dass die Daten den bereits vorhandenen Hund im Archiv ersetzen müssen.
Wurde kein Schlüssel angegeben, muss ich einen generieren und den Hund in das Archiv aufnehmen.
Ich tendiere auch dazu, das mit der Basis 36 umzusetzen.
Hätte ja nur sein können, das einer von Euch noch eine bessere und einfachere Idee hat...

Viele Grüße,
Martin

[Rolf]

Hi

würde die MAC-Adresse gehen? Oder aus dem Geburtsdatum + Namen etwas generieren.

Grüße Rolf

[Martin Altmann]

Hallo Rolf,
vielen Dank für Deine Vorschläge.
MAC-Adresse würde definitiv nicht gehen, da von einer MAC-Adresse mehrere Hunde (auch von verschiedenen Besitzern - Internetcafé oder Terminalserver oder große Firma mit eigener Firewall) gemeldet werden können....
Name und Wurfdatum ist interessant, aber ich komme da sicherlich auch nicht auf weniger als acht Zeichen für einen eineindeutigen Schlüssel...

Viele Grüße,
Martin

[thomas]

Hallo Martin.

Vielleicht kannst du die Chip-Nummer des Hunds verwenden, denn die ist absolut eineindeutig.
Das geht natürlich nur, wenn für diese Paradeveranstaltungen eine Chip-Pflicht für die gemeldete Hunde besteht.

Gruß
Thomas

[Bertram Hansen]

Hallo,

ich benutze öfters die Funktion Seconds(), die liefert bei Sekunden nur eine maximal 5 stellige Ziffer. Das ganze noch kombiniert mit dem Datum .....

[Martin Altmann]

Hallo Thomas,
die Idee ist gut - aber nicht jeder Hund ist gechippt!
Noch besser ist natürlich die Zuchtbuchnummer. Die ist weltweit eineindeutig!
Dies scheitert jedoch an der Art und Weise, wie die Meldenden diese eingeben.
Es gibt z.B. die VDH/BCD 25/612/31 (als Beispiel).
In den seltensten Fällen wird sie jedoch so eingegeben.
Häufiger geben die Leute BCD2561231 an oder VDHBCD 25-61231.
Noch beliebter ist aber, die Buchstaben wegzulassen und nur die Zahlen zu nehmen - also 2561231.
Es gibt aber natürlich auch die VDH/DDC 2561231 - von ausländischen ganz zu schweigen...

Viele Grüße,
Martin

[Martin Altmann]

Hallo Bertram,
genau - das mal hundert und man hat die Anzahl der Hunderstelsekunden des laufenden Tages. Sind 7 Ziffern. Dazu das Datum und das ganze wird recht lang. Darum die Idee, das ganze in eine andere Darstellungsform zu bringen...

Viele Grüße,
Martin

[Tom]

Hallo, Martin.

Wahrscheinlich ist es zwar nicht, aber durchaus möglich, daß zwei Benutzer die selbe Aktion zur bis auf Hundertstelsekunden gleichen Zeit auslösen; ich habe sowas sogar schon in Zwei-Arbeitsplätze-Netzwerken erlebt. Dem könntest Du natürlich vorbeugen, indem Du die fragliche Datenbank vor der Generierung des Schüssels und beim anschließenden Schreiben für mindestens eine Hundertstelsekunde lockst, aber besonders elegant ist das nicht. Was spricht eigentlich genau gegen eine gesonderte Ein-Feld-Tabelle, die bei der Neuerzeugung der Anmeldung gesperrt wird, dann wird der Zähler hochgesetzt und erst nach erfolgter Anmeldung wird sie wieder entsperrt (worauf der möglicherweise parallel Anmeldende warten müßte, aber das wären wahrscheinlich nur Sekundenbruchteile)? Den Initialwert dieses Zählers könntest Du extern setzen, und Probleme mit langen Ziffernfolgen hättest Du auch nicht, weil selbst bei einer Million Meldungen eine maximal 7-stellige Zahl entstehen würde.

[Martin Altmann]

Hallo Tom,
dagegen spricht eigentlich nicht wirklich was, außer, dass ich das persönlich nicht sonderlich elegant finde (eine Datenbank mit einem Feld und einem Satz - brr) und das ganze für mich mit mehr programmtechnischem Aufwand verbunden ist.
Aber wahrscheinlich werde ich die Zugriffe auf das Archiv eh' zentralisieren (wie macht man das am besten mit Threads - mit einer eigenen Klasse und entsprechenden sync-Methoden?) und nur über diesen zentralen Zugriff das auslesen (suchen) und updaten (ändern) der Hunde zulassen. Dadurch kann das Archiv einmalig geöffnet und offen gehalten werden und innerhalb dieser Klasse kann dann der Schlüssel verwaltet werden...
Hat da irgendjemand Erfahrungen oder eine Idee, wie das sinnvoll realisiert werden kann?

Viele Grüße,
Martin

[Tom]

Huhu, Martin.

Muß ja auch keine Tabelle sein, .XML, .INI, sogar .XPF oder meinethalben ein Registry-Schlüssel (Deine Anwendung läuft ja schließlich auf einem einzigen Server) täten's auch.

[brandelh]

Hi Martin,

Ich vermute du legst einen Datensatz für die aktuelle Meldung an.
Beim FOXCDX kann man ein autoincrement Integerfeld anlegen.
Somit hättest du eine eindeutige Nummer.

Und alle paar Minuten (oder Abends etc.) startest du auf deiner Kiste eine Routine, die alle neuen Datensätze in das Archiv wegschreibt. Da du den Server selbst verwaltest kannst du das ja machen (ginge mit meinen CGIs nicht). Die Hauptdatei bräuchte dieser Prozess nur lesen, das Archiv könnte er sogar exclusiv öffnen.

[Manfred]

Hi Martin,

Hallo Thomas,
die Idee ist gut - aber nicht jeder Hund ist gechippt!
Noch besser ist natürlich die Zuchtbuchnummer. Die ist weltweit eineindeutig!
Dies scheitert jedoch an der Art und Weise, wie die Meldenden diese eingeben.
Es gibt z.B. die VDH/BCD 25/612/31 (als Beispiel).
In den seltensten Fällen wird sie jedoch so eingegeben.
Häufiger geben die Leute BCD2561231 an oder VDHBCD 25-61231.
Noch beliebter ist aber, die Buchstaben wegzulassen und nur die Zahlen zu nehmen - also 2561231.
Es gibt aber natürlich auch die VDH/DDC 2561231 - von ausländischen ganz zu schweigen...

Viele Grüße,
Martin

warum arbeitest Du nicht mit einer Maske (PICTURE) innerhalb des Eingabefeldes, in dem eben nur diese Möglichkeit der Eingabe möglich ist? Dann ist jeder gezwungen es richtig zu machen? Ich habe Dich doch richtig verstanden, die Kombination ist vorgegeben?

[brandelh]

Huhu, Martin.

Muß ja auch keine Tabelle sein, .XML, .INI, sogar .XPF oder meinethalben ein Registry-Schlüssel (Deine Anwendung läuft ja schließlich auf einem einzigen Server) täten's auch.

Wobei nur eine DBF leicht und sauber von Xbase++ gesperrt werden kann.
Ich verstehe auch nicht, was an einer 1 Feld 1 Satz DBF 'unsauber' sein soll

[Martin Altmann]

Hallo Ihr drei,
vielen Dank für Eure Anregungen.
Manfred, es geht um eine Webseite - da gibt es kein Picture. Und abgesehen davon kann ich Hinz und Kunz nicht erziehen - da kann ich froh sein, dass die wissen, wie man surft
Hubert, unsauber ist es nicht - nur nicht elegant in meinen Augen.
Tom, wie Hubert ja schon angemerkt hat, kann ich da den exklusiven Zugriff so ohne weiteres nicht realisieren. Höchstens wieder über eine zentrale Klasse/Funktion, die das realisiert...
Wobei ich vielleicht viel zu kompliziert denke?
Eine static-Variable innerhalb einer Funktion bleibt doch inhaltlich nach Verlassen der Funktion erhalten?
Dann könnte ich doch einfach eine Funktion schreiben, die ich mit mehreren Parametern aufrufe:
Entweder (bei Programmstart) wird das Archiv geöffnet und der aktuell höchste Schlüssel gesucht und in der Static-Variable der Funktion abgelegt.
Oder der Schlüssel wird um eins erhöht und zurückgegeben.
Oder der Hund wird gesucht und überschrieben.
Oder der Hund wird gesucht und zurückgegeben.
Macht das Sinn? Funktioniert das so?
Beispiel (Pseudocode):

Code: Alles auswählen

Function usearchiv( cWas, @aData )
static cKey
do case
case cWas == "I"
  oeffne_Archiv_und_Index
  cKey := höchster_benutzter_Schlüssel
case cWas == "A"
  cKey++
  Füge_Hund_aData_mit_key_cKey_in_Archiv_ein
case cWas == "S"
  aData_füllen_mit_im_Archiv_gefundenen_Hund
endcase
return cKey

Viele Grüße,
Martin

[Manfred]

Oooch Martin,

ich würde denen einfach erzählen, wenn die Daten nicht korrekt eingegeben werden, dann kann es durchaus vorkommen, dass ihr Hund X den Preis gewinnt, aber durch die falschen Daten der Hund Y letztendlich den Preis zugesprochen bekommt. Wenn das nicht wirkt......

Naja, mach watte wills......

PS: das mit dem Picture war mir schon klar, ich wollte nur kurz andeuten, was ich meine. Das das auf einer Webseite nicht irgendwie geht, lasse ich jetzt mal im Raume stehen, dass werde ich mir irgendwann mal selber anschauen.

[Martin Altmann]

Hallo Manfred,
prinzipiell geht sowas auch auf einer Webseite - nur nicht auf meiner!
Ich nutze extra kein Java, JavaScript oder sonstiges - sondern nur rein HTML!
Dadurch kann auch der größte Phobiker, der diese Dinge bei sich deaktiviert hat, melden.
Mit z.B. AJAX wäre sowas wunderbar möglich - aber das kommt in meinem Fall halt nicht in Frage.
Abgesehen davon geht ein einfaches Picture auch nicht wirklich - dafür sind die Zuchtbuchnummer weltweit zu unterschiedlich aufgebaut...

Viele Grüße,
Martin

[Tom]

Hallo, Martin.

Nur so am Rande - Du hast einen eindeutigen Schlüssel, vorausgesetzt, Du packst Deine DB nie, was bei eleganter Programmierung nicht erforderlich sein dürfte. Du erreichst ihn über diese Funktion:

Code: Alles auswählen

RecNo()

[Manfred]

Hi Martin,

deshalb "frugte" ich ob die Nummern immer gleich aufgebaut sind, aber da bist Du ja geflissentlich drüber weg gegangen.....