In FIlemaker 12 werd de Get ( UUID ) functie geïntroduceerd. Filemaker zelf suggereert deze te gebruiken als primary key. Het resultaat van de functie is bv ‘FB80E672-4AC3-4A0A-9B77-F5255E80952D’. Het doel van een UUID (http://en.wikipedia.org/wiki/Universally_unique_identifier) is duidelijk. Voor Filemaker 12 gebruikten een aantal ontwikkelaars al custom functions om een UUID te genereren. Het toepassen van een UUID als primary key ( auto entry ) garandeert de ontwikkelaar een altijd unieke sleutel waar deze verder geen omkijken heeft na bv. conversies, samenvoegen van records uit verschillende bestanden etc. . Dit in tegenstelling tot bv het in Filemaker gebruikelijke ‘serial nummer’, al dan niet met een alfanumerieke prefix. Deze moet na conversies of imports goed worden gezet. Voor records die uitgewisseld moeten worden met andere bedrijven is het zinvol om een UUID te gebruiken. Daarnaast is het natuurlijk handig om get(UUID) te gebruiken voor namen van exportfiles e.d..
Aan UUIDs zitten echter ook een paar nadelen in Filemaker.
- Een UUID is een veld dat door auto enter of script wordt gesteld. Bij het dupliceren van records zul je hier dus rekening mee moeten houden.
- Een UUID is een alfanumeriek veld en dito index. Dit is veel zwaarder dan een numerieke variant.
Om dit eens te testen heb ik 4 bestanden gemaakt met allemaal 4 miljoen records met slechts 1 veld:
- numeriek (serial nummer van 1-400000 )
- numerieke primary key zoals ik deze doorgaans gebruik:( get(currenttimestamp) *1000000 ) + mod( get( recordid ) ; 1000000)
- UUID volledig
- UUID zonder ‘-‘ (1word)
Alle tests uitgevoerd met Filemaker Advanced 12v3 onder Mac OSX 10.8.02 ( zonder FMServer )
4000000 records
De verschillende bestandsgroottes voor 4000000 records, allemaal een compressed copy en geen index.
Dezelfde bestanden maar dan geïndexeerd. Merk op dat de UUID-bestanden in verhouding veel groter worden dan die met de numerieke index. Ook heeft Filemaker meer tijd nodig voor de alfanumerieke indexen, maar is in dit geval nog redelijk verwaarloosbaar.
Weer dezelfde bestanden maar nu met index ‘all’ aan (bij de numerieke varianten staat dit standaard aan). Bij deze index worden values geïndexeerd tot 100 karakters, en wordt aangemaakt zodra er gelinkte table occurences worden aangemaakt. Dit zal bij primary en foreign keys doorgaans het geval zijn. Het is hier dat iets opmerkelijks gebeurt: Filemaker heeft opeens heel veel tijd nodig om de indexen aan te maken, vooral bij de alfanumerieke UUID records. Kostte het indexeren van de numerieke indexen zo’n 5 minuten, voor de UUID value index duurt het opeens meer dan een 3uur! Filemaker staat zelfs regelmatig compleet stil (voor het oog). Stel je voor wat dat betekent als je regelmatig grotere bestanden moet importeren of omwerken. Blijkbaar is dit ergens een bug in Filemaker want de eerste 1.8 miljoen records gaan in een te verwachten tempo waardoor je verwacht dat eea in een kwartier klaar is. Bij het bestand met de UUID zonder ‘-‘ idem dito, 3,5 uur waarbij ook de eerste 2 miljoen normaal gaan daarna in happen van zo’n 10 duizend records met grote pauzes.
Vervolgens heb ik in een UUID omgebouwd naar een nummer:
hex2num ( filter( get( UUID ) ; “0123456789ABCDEF” ) ) // hex2num is een custom function
Het aanmaken van de numerieke UUIDs duurt wel een stuk langer, maar is aanmerkelijk kleiner dan de alfanumerieke.
Ook Zoektijden voor de Alfanumerieke versie zijn langer dan de numerieke! (tot 5x trager)
Conclusie: Als je UUID gaat gebruiken, en daar zijn goede redenen voor, neem dan een numerieke variant.