Databaser & datalager

När två system svarar olika på samma fråga är det första att kontrollera om de menar samma sak. ”Kund” kan betyda alla som någonsin handlat i det ena och alla med ett aktivt avtal i det andra. Då är ingen av siffrorna fel, men båda är oanvändbara tills någon bestämt vilken definition som gäller. Ju längre den frågan står obesvarad, desto fler rapporter och integrationer bygger på var sin.

En källa per uppgift

Varje uppgift behöver en ägare: ett system där den får ändras, och som de andra läser från. Det låter självklart, och det är i vardagen det glider. Kundens adress ändras i affärssystemet av ekonomi och i CRM:et av säljaren, och vilken som gäller avgörs av vem som frågar. Vi kartlägger var varje uppgift får ändras och gör de andra kopiorna till just kopior.

Skilj drift från analys

En rapportfråga som går igenom ett års ordrar konkurrerar om processor, minne och lås med de användare som just nu lägger nya ordrar i samma databas. Användarna märker det som att systemet blir segt, utan att kunna se varför. Ett separat datalager för analys tar bort den konkurrensen. Om det är värt kostnaden beror på hur ofta det händer och vad segheten kostar, och det går att mäta innan du bestämmer dig. Vi har byggt datalager i Azure Synapse, men vilken plattform som passar beror på vad du redan kör.

Vad ett datalager ska klara

• Datamodell där varje uppgift har en ägare, en källa och en definition.
• Datalager för analys, uppdaterat i den takt besluten fattas i.
• Historik som går att fråga bakåt i tiden, inte bara på dagens läge.
• Schemaändringar planerade så att systemet kan vara igång under tiden, och med en väg tillbaka som är bestämd innan de körs.
• Index och frågeoptimering där mätningarna visar att svarstiderna gör ont, inte överallt.

En rörig datamodell är teknisk skuld som betalas av den som bygger på den: nästa rapport, nästa integration, nästa nyanställd som ska förstå varför det finns tre kundtabeller. Hur du sätter en siffra på det står i vad kostar teknisk skuld?.