Object-Id

Maandag, 2 juli 2001
Heeft een moderne database nog wel de derde normaalvorm nodig?
  • Je kunt toch elke row uniek identificeren met een object-id? Het sluit ook mooi aan bij Object georiënteerde software, waar elk object ook uniek is.
  • Een object-id is een mooie standaard identificatie. Erg makkelijk voor generieke software.
  • En een object-id is ook nog goed voor de performance want een join hoeft maar over één kolom.
Ja, ja, klinkt prachtig allemaal. En toch... wat kanttekeningen.

Derde normaalvorm nog nodig?

Ja! Ja! Ja! De derde normaalvorm is nodig, voor elk database ontwerp.

Ook met Object-ids in een database moet de database-ontwerper data analyse doen. Object-ids zijn slechts een mogelijke technische implementatie, maar dan wel van een functionerend logisch model graag. Object-id's zijn geen geldig excuus om data analyse maar over te slaan. Sterker nog: ook voor een object model is data anlyse nuttig. Object model en database ontwerp zijn geen eeneiïge tweeling. Het zijn slechts halfbroers met als gemeenschappelijke ouder: een conceptueel model (bijvoorbeeld een ERD).

Elk object uniek met eigen object-id

Ja. In OO is elk object uniek, net als in de werkelijke wereld. Dit is een drogreden, een irrelevant argument.

Het is ook werkelijkheid om dubbelzinnigheden te vermijden.

  • Bij een gegeven sofi# hoort maar één persoon, nooit 2.
  • Bij een gegeven combinatie van sofi# en krantnaam hoort maar één abonnement.
In Smalltalk zijn zowel een Dictionary als een Set prachtig instrumenten om dubbele occurrences te vermijden. In Java voldoet een Hashmap. En wat maakt een object uniek in Set, Dictionary of Hashmap? Juist, de keys uit het ERD!

Met object-Ids lijkt een database mooi op een objectenbase maar is dat belangrijk? Stelling: Object-Ids zijn hooguit leuk voor intern gebruik in de objectenlaag. Hou ze a.u.b. verborgen in de user interface en koppelingen met andere systemen.

Object-ids zijn mooi generiek

Ja, prachtig. En wat doet u er dan mee? Waarom is dat generieke een voordeel? Als generiek een voordeel is, ga dan nog een stap verder: Richt één generieke tabel op met de volgende kolommen:
entiteitsnaam (key) object-id (key) kolomnaam kolomwaarde
... ... ... ...
Veel plezier met de programmeerinspanning en de performance!

Snelle joins

Hmm. Voor de performance is geen join veel en veel beter dan een snelle join.

En hoe voorkomt u joins? Kijk eens naar denormalisatie. In derde normaalvorm zijn keys als vanzelf gedenormaliseerd, beschikbaar zonder join. En die key informatie heeft juist vaak de hoogste frequentie van gebruik en dus de grootste impact op de performance.

Ja, ja, u kunt die key informatie alsnog denormaliseren. En ja, u kunt er een extra index op leggen voor de uniciteit. En welk voordeel biedt het object-id dan nog voor de performance?

Tot de volgende week,
Henk Jan Nootenboom

Zaterdag 30 juni 2001: Suzanne Piet geslaagd voor haar C diploma zwemmen. Gefeliciteerd!