Invloed van Datamodellering vaak onderschat

Door: Martijn Wallet 9-1-2017

Categorie├źn
:
Beheer, BLOG, DBMS, Ontwerp, Technisch,

Datamodel

Bij onze klanten komt het vaak al gauw boven water bij een QuickScan of HealthCheck. Een datamodel dat voor verbetering vatbaar is. Dan hebben we het niet alleen over het toepassen van de principes van normalisatie maar ook het daadwerkelijk technische datamodel.

Een indicatie voor een "zwaar" technisch datamodel is geheugen druk. Het database systeem vreet geheugen. In het meest ideale geval is er voldoende geheugen voor de gehele database, data en indexen. In veel gevallen is dit niet mogelijk, zorg er dan voor dat tenminste de clustered indexen en vervolgens de non-clustered indexen in geheugen passen.

Indexering

Wat betreft indexering is het van belang dat de clustered indexen smal (zo klein mogelijke opslag) en bij voorkeur incrementing (oplopend) zijn. Dit voorkomt een sortering bij het toevoegen van elk nieuwe record. Liever een integer dan een biginteger, en liever een integer dan een varchar(...). Wanneer er geen geschikt datatype in de tabel voorkomt dan luidt het advies voeg een automatisch gegenereerd incrementing integer veld toe aan het begin van de tabel. De keuze om die wel of niet te gebruiken in de toekomst staat los van deze beslissing. De optie om geen clustered index aan te maken is onverstandig omdat dan het risico wordt gelopen dat niet ieder record (elke regel) uniek te identificeren is.

De volgende stappen kunnen worden onderscheiden bij het toepassen van een indexering strategie:

Datatypen

De keuze van datatypen dient zorgvuldig te worden gemaakt. Wanneer bijvoorbeeld huisnummers moeten worden opgeslagen kan doorgaans worden volstaan met een smallint of int en zorgt een bigint voor verspilling van ruimte. Dit geldt voor alle Wat betreft varchar (varying character) kolommen is dit niet het geval.

 Data type  Range  Storage
 bigint  -2^63 (-9,223,372,036,854,775,808) to 2^63-1 (9,223,372,036,854,775,807)  8 Bytes
 int  -2^31 (-2,147,483,648) to 2^31-1 (2,147,483,647)  4 Bytes
 smallint  -2^15 (-32,768) to 2^15-1 (32,767)  2 Bytes
 tinyint  0 to 255  1 Byte

Volgorde kolommen

Ook de volgorde van kolommen of velden kan van wezenlijke invloed zijn op de uiteindelijke prestaties van de database. Vaak wordt er voorbijgegaan aan het feit dat de specifieke kenmerken van kolommen (verplicht/niet-verplicht) en het datatype (fixed/variable width) de daadwerkelijke opslag op de data-pages beinvloeden. Dit zal op DML (data manipulation language) statements van invloed zijn. Doorgaans wordt onderstaande volgorde aangehouden:

  • Primary key kolommen
  • Foreign key kolommen
  • Veel geselecteerde kolommen
  • Veel gemuteerde kolommen
  • Nullable kolommen als laatste
  • Weinig gebruikte nullable kolommen na meer gebruikte nullable kolommen

Met bovenstaande informatie hopen we enkele richtlijnen te hebben gegeven voor een "snel" datamodel. Wilt u meer weten? Neem vrijblijvend contact op!

Terug naar blogoverzicht