Creatie van uniek ID voor Key Field.

sjuul · 24 december 2007

Wat vinden jullie van deze calculatie om een uniek ID te maken welke als key field dienst kan doen?

"ID" & Get ( RecordID ) & GetAsNumber ( Get ( CurrentTimeStamp ) ) & Left ( Substitute ( Get ( SystemNICAddress ) ; ":" ; "" ) ; 12 )

Ik ben benieuwd naar commentaar voor deze calculatie, en/of andere oplossingen. Ik werk expres niet met automatische serienummers, daar je dan zonder probleem deze data kan importeren, zonder zorgen te maken om de serienummers juist te zetten.

JeanWM · 24 december 2007

Ik ga niet al te diep in de materie, nog wat ruimte laten voor discussie.

Eerst eens kijken welke verschillende keys we kunnen hebben binnen de normalisatie structuur.

Je kunt een ‘Natural’ key hebben of een ‘Surrogate’ key.

Voor beide is de voorwaarde: ze moeten in alle omstandigheden een record uniek maken.

De voorwaarden voor een primary key zijn dus:

- 1. de key moet uniek zijn voor ieder record

- 2. de waarde mag niet ‘null’ zijn (‘null’ is niet ‘zero’, ‘zero’ is een waarde)

- 3. de key waarde moet bestaan bij de aanmaak van het record

- 4. de key waarde moet onveranderlijk zijn

- 5. de key waarde moet compact zijn en de minst mogelijke attributen bevatten

- 6. een keywaarde mag nooit verandert kunnen worden

In deze lijst wil ‘moet’ en ‘mag niet/nooit’ niet zeggen ‘misschien’ of ‘mogelijk’ of ‘gewoonlijk’, ‘moet’ en ‘mag niet/nooit’ is hier absoluut.

Als we nu naar je coding kijken, die voor een natural key is:

"ID" & Get ( RecordID ) & GetAsNumber ( Get ( CurrentTimeStamp ) ) & Left ( Substitute ( Get ( SystemNICAddress ) ; ":" ; "" ) ; 12 )

Je bent in overtreding met regel 2. Wat indien er geen netwerkkaart aanwezig is ¿

Je bent dan ook in overtreding met regel 3.

Je bent in overtreding met regel 4. Wat indien de bestaande netwerkkaart moet vervangen worden ?

Regel 5 laten we even buiten beschouwing.

Voor regel 6: de NIC code is nu een 6 bytes, hexadecimale waarde, gescheiden door colons, wie zegt dat dat zo zal blijven. Wat indien ooit de ':' vervangen wordt door een ';' ?

Surrogate keys zijn altijd beter.

sjuul · 25 december 2007

Je bent in overtreding met regel 2. Wat indien er geen netwerkkaart aanwezig is ¿
Je bent dan ook in overtreding met regel 3.

Je bent in overtreding met regel 4. Wat indien de bestaande netwerkkaart moet vervangen worden ?

Regel 5 laten we even buiten beschouwing.

Voor regel 6: de NIC code is nu een 6 bytes, hexadecimale waarde, gescheiden door colons, wie zegt dat dat zo zal blijven. Wat indien ooit de ':' vervangen wordt door een ';' ?

1. Als er geen netwerkkaart is, dan is er nog altijd het record id, en de timestamp.

2. zie boven, null zal dus ook niet voorkomen.

3. Als de netwerkkaart word vervangen, is het record al gemaakt, dat maakt dus niet uit.

4. MAC adres notatie zal nimmer veranderen, daar zijn stricte RFC's voor. We krijgen hoogstens problemen waneer IPv6 zijn intrede doet. Maar ook daar gebruikt met wederom de zelfde notatie.

Welke andere methodes gebruiken jullie, ik ben benieuwd naar oplossingen van andere mensen.

Maarten Witberg · 25 december 2007

met macadressen kun je toch wel rommelen.

een filemaker serial is volgens mij de enige goede manier om een uniek en veilig en voor relationeel werk geschikt serienummer te maken. en ook nog eens het makkelijkst. ik formatteer ze nooit met voorloop nullen of letters of wat ook, het is gewoon een getal. volgens mij voldoet het volledig aan het lijstje van Jean, mits je het veld afsluit voor gebruikers om aan regel 4 en 6 te voldoen

mijn twee centen: gebruikers zouden nooit serienummers hoeven te zien, tenzij het de zoekfunctie vergemakkelijkt bij klantcontact ("mag ik het nummer van de rekening alstublieft?")

pjotter · 25 december 2007

?

Wat mankeert er aan gewoon een nieuw veld met "uniekID" en met als typen numeriek en als option "serial" ? (eventueel extra als validation "uniek?)

Maarten Witberg · 25 december 2007

psies

sjuul · 25 december 2007

Hoe ga je dan om met deze nummers, waneer er om wat voor een reden dan ook, een import wordt gedaan in bijvoorbeeld het bronbestand. Hier zou de teller dan op 1 staan. waneer je dit als auto-enter doet, krijg je dubbele id's. Mijn methode is naar mijn idee hier wel tegen bestand. Andere meningen zijn welkom.

JeanWM · 25 december 2007

1. Als er geen netwerkkaart is, dan is er nog altijd het record id, en de timestamp.

Dan speelt regel 5, de minst mogelijke attributen gebruiken

2. zie boven, null zal dus ook niet voorkomen.

Null zal dan wel een onderdeel van je berekening zijn, dus is je berekening niet in alle omstandigheden juist. Je kunt je key niet altijd en overal gebruiken.

3. Als de netwerkkaart word vervangen, is het record al gemaakt, dat maakt dus niet uit.

Je kunt de storage van het veld veranderen, wat dan een overtreding van regel 6 is.

4. MAC adres notatie zal nimmer veranderen, daar zijn stricte RFC's voor. We krijgen hoogstens problemen waneer IPv6 zijn intrede doet. Maar ook daar gebruikt met wederom de zelfde notatie.

Regels wel maar gebruikte standards kunnen veranderen.

Welke andere methodes gebruiken jullie, ik ben benieuwd naar oplossingen van andere mensen.

Simpele surrogate keys, aangemaakt en locked door het systeem.

JeanWM · 25 december 2007

.... tenzij het de zoekfunctie vergemakkelijkt bij klantcontact ("mag ik het nummer van de rekening alstublieft?")

Een beetje dieper in de materie...

Het uniek zijn is maar de helft van het verhaal. De key mag geen associatie hebben met de data van het record.

Keys zijn enkel pointers tussen gerelateerde records in verschillende tables.

De primary-key waarde heeft dus totaal geen betekenis en heeft totaal niks te maken met het inhoudelijke van het record.

Als je de key gaat gebruiken als 'rekeningnummer', geef je een 'betekenis' aan een key die iets met het inhoudelijke te maken heeft.

Is een overtreding van een normalisatieregel.

pjotter · 25 december 2007

Hoe ga je dan om met deze nummers, waneer er om wat voor een reden dan ook, een import wordt gedaan in bijvoorbeeld het bronbestand. Hier zou de teller dan op 1 staan. waneer je dit als auto-enter doet, krijg je dubbele id's. Mijn methode is naar mijn idee hier wel tegen bestand. Andere meningen zijn welkom.

Als je al een bestaande database hebt maak je een veld aan met uniek.

Zorg dat alle records zichtbaar zijn en replace field content. Alle records hebben dan een uniek nummer en als het goed is worden bij toevoegen van nieuwe records (import of zo toevoegen) nieuwe nummers aangemaakt.

JeanWM · 25 december 2007

Hoe ga je dan om met deze nummers, waneer er om wat voor een reden dan ook, een import wordt gedaan ...

Dat definieer je in de Import Options.

SuperWimmie · 26 december 2007

Wat ik dus altijd doe en dat werkt bij mij in de praktijk vrijwel waterdicht (inclusief updates van versies van de software!!):

datum & tijd & recordID.

Aangezien het mij wel heel erg toevallig lijkt dat op exact hetzelfde moment twee keer hetzelfde recordID wordt aangemaakt, is dit voor mij een goede oplossing.

Waarom ik geen Serial number gebruik, hangt samen met mijn versiebeheer. Ik exporteer de data vanuit de oude versie en importeer dat weer in de nieuwe. Serialnumbers zijn wel te updaten na een import, maar als je dat ook maar ergens een keertje vergeet ben je de klos.

Liever op mijn eigen manier, dus... en dat werkt fantastisch.

WJ · 27 december 2007

Wil je echt zeker zijn dat je unieke ID hebt kun je van de volgende formule gebruik maken. Universal Unique Indentifier.

Let ( [

UUID =

Let ( [

hexVals = "0123456789ABCDEF";

d1 = GetAsNumber(Get(CurrentHostTimeStamp));

d2 = Div (d1; 16);

d3 = Div (d2; 16);

d4 = Div (d3; 16);

d5 = Div (d4; 16);

d6 = Div (d5; 16);

d7 = Div (d6; 16);

d8 = Div (d7; 16)

];

Middle(hexVals; Mod (d8; 16) + 1; 1) &

Middle(hexVals; Mod (d7; 16) + 1; 1) &

Middle(hexVals; Mod (d6; 16) + 1; 1) &

Middle(hexVals; Mod (d5; 16) + 1; 1) &

Middle(hexVals; Mod (d4; 16) + 1; 1) &

Middle(hexVals; Mod (d3; 16) + 1; 1) &

Middle(hexVals; Mod (d2; 16) + 1; 1) &

Middle(hexVals; Mod (d1; 16) + 1; 1) &

"-" &

Middle(hexVals; Int(Random*16)+1; 1) &

"-" &

Middle(hexVals; Int(Random*16)+1; 1) &

"-" &

Middle(hexVals; Int(Random*16)+1; 1) &

"-" &

Upper(Substitute(GetValue(Get ( SystemNICAddress );1); ":"; "")

)

];

UUID

)

JeanWM · 27 december 2007

Nog een stapje dieper in de materie...

Wat indien je een duplicated record hebt ?

SuperWimmie · 28 december 2007

geen probleem bij mij, want aanmaakdatum, aanmaaktijd en record ID zijn dan mooi aangepast. Evenzo het calculatieveld dat deze drie aan elkaar knoopt.

hiker · 28 december 2007

geen probleem bij mij, want aanmaakdatum, aanmaaktijd en record ID zijn dan mooi aangepast. Evenzo het calculatieveld dat deze drie aan elkaar knoopt.

Bij het importeren van records zet je dan de automatische invoer van data op "uit"? Anders zullen immers de aanmaakdatum en aanmaaktijd bij alle records hetzelfde zijn en heeft die combinatie geen zin.

SuperWimmie · 28 december 2007

Klopt helemaal.

WJ · 28 december 2007

Ik twijfel echter wel aan deze manier van werken met FM. In value lists enzo kun je de ID's niet meer gebruiken.

Je kunt het ook makkelijk de gewone notatie gebruiken en een summary veld gebruiken met een max functie en die gebruiken om na de import het tellertje goed te zetten.

Gr,

WJ

SuperWimmie · 28 december 2007

Deze methode is geschikt voor een technische sleutel, geen logische.

Vandaar dat deze sleutel bij mij ook nooit in een valuelist verschijnt, maar slechts als doel dient om een uniek record op geschikte momenten te kunnen herleiden.

Zelf hanteer ik vrijwel altijd logische sleutels in het systeem. Traceerbaarheid is hierdoor groter, alhoewel wijzigingen in sleutelwaarden natuurlijk als nadeel hier tegenover staat.

BDK · 29 december 2007

Wil je echt zeker zijn dat je unieke ID hebt kun je van de volgende formule gebruik maken. Universal Unique Indentifier.

Let ( [

UUID =

Let ( [

hexVals = "0123456789ABCDEF";

d1 = GetAsNumber(Get(CurrentHostTimeStamp));

d2 = Div (d1; 16); enz

dat ziet er interessant uit! maar wat doet het nu eigenlijk precies (in gewone taal ), en hoe weet je nu zo zeker dat dit inderdaad ALTIJD een unieke ID oplevert? en is het daarvoor niet een wat al te ingewikkelde oplossing?

groet, bdk

JeanWM · 29 december 2007

hoe weet je nu zo zeker dat dit inderdaad ALTIJD een unieke ID oplevert?

Het zal niet altijd een unieke ID opleveren.

De Get(CurrentHostTimestamp) function is een variabele.

Je kunt immers je Host time aanpassen/verzetten.

Dus is het niet betrouwbaar in alle omstandigheden, terwijl de verbinding met de Host een vertraging kan oplopen per toestel, wat mogelijk gelijke waardes zou kunnen opleveren.

Maarten Witberg · 30 december 2007

wat Jean zei, en nog dit, voorzover ik de theorie achter UUID snap en de hier gepresenteerde versie:

de code bestaat uit drie blokken:

1. een bewerking van de timestamp van de host

2. een random getal van 12 cijfers

3. het nic-adres (van de host?).

het random getal op zich geeft geen garantie op uniciteit, net zomin als het tijdstempel. "random" is ook niet helemaal juist als term, de random functie van Filemaker genereert geen werkelijk willekeurige getallen (lees dit).

Als ik het nu goed begrijp zal onder normale omstandigheden de tijdstempel niet vaker gelijk zijn dan het systeem in staat is om binnen 1 seconde een nieuw record te genereren - zou dat meer dan enkele tientallen zijn? in combinatie met een toevalsgetal van 12 cijfers is de kans toch groter dat je de postcodeloterij wint dan dat je twee dezelfde serienummers krijgt.

het nic-adres voegt daar nog wat aan toe. als het nu het nic-adres van de guest was, dan verbetert het nog eens.

maar het blijft rekenen met kansen en dat betekent dat het niet werkelijk uniek is.

mijn vermoeden is dat UUIDs interessant zijn in situaties waar je een zo goed als unieke identificatie nodig hebt maar geen gecentraliseerd systeem om die identificatie toe te kennen. iets dat je in filemaker hebt in de vorm van doodeenvoudige serienummers.

benieuwd of ik het gesnopen heb.

JeanWM · 31 december 2007

Een nic adres gebruiken voor een key heeft absoluut geen zin.

Zelfs niet als onderdeel van een key.

De waarde kan in sommige omstandigheden null zijn en dat maakt de key waardeloos.

Het argument dat je dan toch nog de andere elementen hebt slaat nergens op.

Waarom dan uberhaupt een nic adres gebruiken ?

Op zich een random gebruiken heeft ook geen zin, je kunt nooit via computer een unieke random hebben.

Je kunt wel systematisch de kans op een dupe verminderen, maar nooit helemaal wegwerken.

Zelfs de timestamp geeft geen garantie, die werkt volgens de kloksnelheid van de CPU, en die kan varieren.

Als je dan toch een key buiten het normale wilt hebben is het best dat je met integers werkt en een conversie doet van base X naar base N, waar base N het totaal aantal cijfers of karakters is.

Binnen FileMaker neem je best Get(RecordID) hiervoor en doet een mapping van een subset die je kunt berekenen.

Die mapping kan iets zijn van 1 tot N^baseN. Maar dan zit je al met een afgeleide van een lineair programmatie.

De vraag blijft of het binnen FileMaker toepassingen wel de moeite waard is.

Get(RecordID) samen met een afkorting van de entiteit waar het record deel van uit maakt is doorgaans meer dan genoeg.

Durk · 31 december 2007

Carsten Belling (een guru in Duitsland) gebruikt de volgende berekening om unieke IDs te maken. Hij merkt op, dat er per seconde 36^19 (371.319.292.745.659.279.662.190.166.016) mogelijkheden zijn en deze sleutels dus alleen nog in theoretische zin niet uniek zijn.

Een andere guru (Christopher Busch) heeft een database met ik meen 5 miljard records gemaakt met deze methode en is nooit op een duplikaat gestoten.

Middle( "abcdefghijklm0123456789nopqrstuvwxyz"; Int( Random * 36 ) + 1; 1) &

GetAsNumber( Get ( CurrentDate ) ) &

Middle( "abcdefghijklm0123456789nopqrstuvwxyz"; Int( Random * 36 ) + 1; 1) &

Right( "00000" & GetAsNumber( Get ( CurrentTime ) ); 5 ) &

Middle( "abcdefghijklm0123456789nopqrstuvwxyz"; Int( Random * 36 ) + 1; 1) &

Middle( "abcdefghijklm0123456789nopqrstuvwxyz"; Int( Random * 36 ) + 1; 1)

groet,

Durk

JeanWM · 31 december 2007

Net wat ik zei, een conversie van base X naar base N met een mapping van 1 tot N^baseN, met een lineaire congruentie berekening.

Blijft nog steeds de vraag of het voor FileMaker toepassingen de moeite loont of de noodzaak bestaat om zulke complexe sleutels te hebben.

Feitelijk zit je dan buiten de FileMaker doelgroep - zie Ilyze Kazar - te werken met mogelijk de niet aangepaste tool.

WJ · 2 januari 2008

De formule is afkomstig van Syncdek.com. Specialisten op het gebied van synchronisatie van filemaker databases. Bij synchronisatie is het uniek maken van de sleutels natuurlijk van levensbelang en een noodzakelijk "kwaad".

Universally Unique Identifier

From Wikipedia, the free encyclopedia

(Redirected from UUID)

A Universally Unique Identifier is an identifier standard used in software construction, standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE). The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. Thus, anyone can create a UUID and use it to identify something with reasonable confidence that the identifier will never be unintentionally used by anyone for anything else. Information labeled with UUIDs can therefore be later combined into a single database without needing to resolve name conflicts. The most widespread use of this standard is in Microsoft's Globally Unique Identifiers (GUIDs) which implement this standard. Other significant users include Linux's ext2/ext3 filesystem, LUKS encrypted partitions, GNOME, KDE, and Mac OS X, all of which use implementations derived from the uuid library found in the e2fsprogs package.

A UUID is a 16-byte (128-bit) number. The number of theoretically possible UUIDs is therefore 216*8 = 2128 = 25616 or about 3.4 × 1038. This means that 1 trillion UUIDs would have to be created every nanosecond for 10 billion years to exhaust the number of UUIDs.

In its canonical form, a UUID consists of 32 hexadecimal digits, displayed in 5 groups separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters. For example:

550e8400-e29b-41d4-a716-446655440000

UUIDs are documented as part of ISO/IEC 11578:1996 "Information technology -- Open Systems Interconnection -- Remote Procedure Call (RPC)" and more recently in ITU-T Rec. X.667 | ISO/IEC 9834-8:2005 (freely available). The IETF has published Proposed Standard RFC 4122 that is technically equivalent with ITU-T Rec. X.667 | ISO/IEC 9834-8.

A UUID may also be used with a specific identifier intentionally used repeatedly to identify the same thing in different contexts. For example, in Microsoft's Component Object Model, every component must implement the IUnknown interface, which is done by creating a UUID representing IUnknown. In all cases wherever IUnknown is used, whether it is being used by a process trying to access the IUnknown interface in a component, or by a component implementing the IUnknown interface, it is always referenced by the same identifier: 00000000-0000-0000-C000-00000000004

Ik heb het gebruikt in een project het werkt prima maar ben er nog niet uit of het nou meer nadelen dan voordelen heeft.

Voordelen:

- Makkelijk updaten !

- De sleultels in de verschillende tabbelen zijn altijd uniek levert programmeer gemak op.

-(met nummering heb je in de verschillende tabellen wel dezelfde nummers)

- Samenvoegen van systemen kan makkelijker

- Eventuele synchronisatie mogelijkheden.

Nadelen:

- Custom functie nodig.

- Lange string meer bytes

- Geen logische volgorde meer

- Niet te gebruiken in interface

Ik denk niet dat ik het in vervolgprojecten gebruik. Tenzij ik weet dat er meerdere systemen in het spel kunnen komen.

Groet,

WJ

Inloggen

Creatie van uniek ID voor Key Field.

Vraag

Link naar reactie

25 antwoorden op deze vraag

Aanbevolen berichten

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Link naar reactie

Doe mee aan dit gesprek