Een tijd geleden heb ik een pleidooi gehouden voor een splitsing van een zaakidentificatie (voor het uitwisselen van zaakinformatie in de keten met andere applicaties) en een zaakkenmerk (leesbaar en bruikbaar voor inwoners en bedrijven).
Deze discussie laait weer op en graag wil ik de zienswijze van Decos nogmaals onder de aandacht brengen en een constructieve oplossing zoeken voor het probleem dat wij aan zien komen (al bezig is) als we doorgaan op de manier zoals het in het RGBZ bedacht is.
in de bijlage probeer ik helder te schetsen wat de voors- en tegens zijn en ik zie graag jullie reacties hierop tegemoet.
Interessante vraagstelling. Hieronder een paar opmerkingen en vragen.
GUID: Altijd uniek, door iedereen te genereren => wel zorgen dat iedereen correct guids genereert ;)
Oude zaakkenmerken kunnen worden hergebruikt: Zaak-123 is vernietigd, dus Zaak-123 kan opnieuw gebruikt worden. => vanuit archiveringsoogpunt dubieus als je wilt borgen dat het voor de betreffende burger een blijvende identificatie is.
Zaak kan naar andere organisatie overgezet worden, maar blijft identificatie houden als unieke waarde. Hierdoor kan deze zaak in meerdere systemen bestaan maar gaat updaten, afhandelen, doorsturen, vernietigen altijd goed. => gebeurt dit in praktijk? En zo ja, is gedefinieerd hoe overdracht en afhandeling dan in het oorspronkelijke systeem plaats moet vinden?
Bezwaren tegen RGBZ 2.0 -> lijken me valide redenen voor heroverweging omdat er steeds meer situaties ontstaan dat een zaak niet meer 'voor eeuwig' bij de oorspronkelijke zaakcreator blijft.
Lezend door de andere discussieitems zie ik dat ook allerlei andere identificerende rubrieken betekenis bevatten (rsin, gemeentecode, medewerkercode, domeincode, etc.). Verbaast me omdat het bij databaseontwerp common practice is om nooit betekenis in identificerende rubrieken op te nemen voor maximale flexibiliteit. Vraag is dus: waarom is/wordt er eigenlijk steeds gekozen voor betekenisvolle identificaties?
Ik ben het er niet helemaal mee eens dat identificerende rubrieken betekenis bevatten.
In veel definities van identificerende velden is impliciet bepaald hoe de range van mogelijke waarden is verdeeld over de instanties die de nummers uit kunnen geven. Dat is gedaan door bijvoorbeeld te stellen dat de eerste 4 posities van het veld gevuld worden met de gemeentecode. Voor bijvoorbeeld de BAG is dit een werkbare oplossing omdat deze nummers alleen door gemeenten (uniek geïdentificeerd met die code) worden uitgegeven. Het identificerende gegeven bevat daarmee geen betekenis. Elke betekenis die eraan wordt ontleend is puur voor de verantwoordelijkheid van degene die dat doet.
Het toekennen van ranges is overigens onvermijdelijk als je een uniek nummer wil gebruiken dat toegekens wordt door verschillende instanties. In het verleden zag je bijvoorbeeld ook bij GUID's een vergelijkbare constructie toen MS nog het MAC-adres gebruikte als basis voor de laatste getallen. Daarmee zijn die GUID's natuurlijk ook niet betekenisvol geworden.
De vraag is natuurlijk of je een constructie met vooraf gedefinieerde ranges in alle gevallen aan kunt houden. Bij zaken kun je verwachten dat de ID's door veel verschillende soorten instanties worden gegenereerd. Je zou dan dus kunnen kiezen voor het gebruik van een RSIN in plaats van bijvoorbeeld die gemeentecode (de RSIN wordt ook uniek verondersteld), of een GUID; beide leveren lange nummers op die voor een mens moeilijk te onthouden en lastig over te typen zijn.
Een andere optie is om de uniciteit van het nummer los te laten en identificatie te laten plaatsvinden op basis van nummer en uitgevende instantie (twee rubrieken ipv één). De vraag is in hoeverre dit nog werkt bij zaken die worden overgedragen tussen organisaties. Een klant die dan de status van de zaak in wil zien, moet nummer en oorspronkelijke organisatie weten en opgeven bij het zoeken (als hij/zij de pech heeft dat een zaaknummer daardoor toevallig dubbel voor komt in de afhandelende organisatie). De vraag is of de klant de status van de zaak niet altijd zou moeten opvragen bij de organisatie waarbij de zaak is gestart. Voor de klant zou het niet relevant moeten zijn dat de zaak is overgedragen: de klant heeft te maken met de oorspronkelijke organisatie en zou van die organisatie de terugkoppeling moeten krijgen (in mijn ogen).
Voor alle duidelijkheid: de meerwaarde van een random gegenereerde unieke sleutel is dat je hem altijd kunt blijven gebruiken als omstandigheden veranderen. Punt is dat er keer op keer meer blijkt te veranderen dan we vooraf verwachten (ook gebruik van een RSIN stelt me wat dit betreft niet gerust).
Unieke sleutels zijn van belang voor opslag en gebruik door applicaties. Gebruikersvriendelijkheid regel je bijv. door het gebruik van kenmerk(en) zoals Rene in zijn pdf beschreef. Wil je daarbij vooraf gedefinieerde ranges gebruiken dan is een evt. toekomstig probleem daarmee peanuts in vergelijking met de situatie met een tekortschietend sleutelgegeven.