NLEN
Direct technisch advies?
035 369 0304
dba@optimadata.nl
Home > Blog

Invloed van Datamodellering vaak onderschat

Martijn Wallet 9-1-2017 8:16
Categorie├źn: BLOG

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.

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:

  • vaststellen van de primary key, deze is zuiver en alleen bedoeld als logische primary key voor integriteit controle van unieke records;
  • vaststellen van de clustered index, deze hoeft niet noodzakelijk dezelfde te zijn als de primary key.
  • indexering voor integrity checking:
    • unieke kolommen of combinaties van kolommen;
    • foreign key kolommen;
  • andere handige indexen voor performance.

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

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.

Terug naar Blog overzicht

Reageer