När du skriver ett blogginlägg om databasmodellering måste du vara beredd på att din abstrakta modell inte uppfyller behoven hos de flesta läsare. Anledningen är enkel. Databasmodeller i verkligheten skapas vanligtvis i nära relation till specifika affärs- och utvecklingskrav, medan bloggmodellerna inte är det.
De senaste veckorna har jag skrivit blogginlägg om att skapa databasmodeller. Ämnen sträckte sig från en allmän inställning till databasmodellering via ett enkelt onlineforum till en modell för en mer komplex onlineundersökning.
För varje databasmodell som jag skapar försöker jag att tydligt förstå affärsdomänen och räkna ut den stora bilden av modellen i mitt sinne.
Utmaningen med utveckling av abstrakt databas
Normalt som en lösning arkitekt , tar jag specifika affärskrav och omvandlar dem till tekniska detaljer om vad som behöver skapas från den tekniska sidan:översätta från affärsspråket till fackspråket – designa algoritmerna på hög nivå och modellera datakraven för algoritmerna.
Tyvärr kan jag inte blogga om de verkliga databasmodellerna som jag skapar på jobbet. Dels är de väldigt specifika för affärsdomänen och dels är jag begränsad av sekretessavtal. För bloggen skapar jag en rent abstrakt koncept utan specifika affärskrav förutom de som jag föreställer mig finns inom affärsdomänen. Nu är det bra; Jag har en ganska bra fantasi och jag påpekar ofta att dina krav kan vara annorlunda när jag beskriver de val jag gör. Men den här bloggprocessen fick mig att tänka på hur annorlunda den här processen är från att skapa modellerna i ett riktigt projekt.
Den verkliga utvecklingsprocessen
I en verklig situation skulle jag arbeta nära utvecklingsteamet efter att ha skapat högnivålösningen och teknisk design i en interaktiv sätt så att modellen passar utvecklingsbehoven.
Utvecklarna kan klaga på att datamodellen är för normaliserad för att stödja högpresterande, eller så kan de begära ytterligare normalisering inom vissa områden. Om några alternativa nycklar saknades skulle utvecklarna klaga ganska snabbt och vi skulle också märka det under prestandatestning av databasen.
Vi skulle överväga vad de exakta fältlängderna bör baseras på den maximala längden på data som ska lagras och på utformningar av skärmar för inmatning och visning av data. Naturligtvis är de exakta fältlängderna i en konceptuell databasmodell inte viktiga.
Vi skulle arbeta igenom exempel på vilken data som kommer att lagras i tabellerna och hur den kommer att användas av applikationen, och skapa skript för att förfylla tabellerna för enhetstestning av applikationen. På så sätt skulle vi fånga hörnfallen för att säkerställa att modellen stödjer gränserna för applikationen.
Så i grund och botten skulle vi massera modellen tills den verkligen stöder systemets affärsmässiga och icke-funktionella krav med hjälp av en iterativ process tills vi har utvecklat en modell till något som vi alla kan acceptera trots de kompromisser som är inbyggda i den.
Som jag sa skulle det vara en mycket iterativ process som kan fortsätta under många månader medan applikationskoden, användargränssnitten och applikationsgränssnitten utvecklas.
Begränsningar för välmenande feedback
I den nuvarande bloggsituationen, medan mitt visserligen begränsade antal läsare ger mig feedback på problem och utmaningar som de observerar med modellerna, är det nödvändigtvis ytligt. Jag tvivlar på att någon av läsarna direkt använder modellerna för att skapa en applikation och upptäcka vad som verkligen fungerar och var det finns problem.
Så kommentarerna som "modell inte genomtänkt" är nästan säkert rätt. Å andra sidan är "det saknas FKs" ganska exakta, men förhoppningsvis har jag förklarat i artikeltexten varför jag inkluderar en främmande nyckel eller inte.
Slutsats
Läs nu inte det här inlägget som ett klagomål eller en kommentar om den feedback som läsarna ger, utan jag reflekterar över svårigheten att göra en databasmodell när du inte är i en miljö som tillåter ett interaktivt utbyte med en iterativ utvecklingsprocessen.
Det finns förmodligen andra situationer där databasmodellerare är avskurna från utvecklingsprocessen, men jag har nu insett hur farligt det skulle vara och hur benägna att få problem de skulle vara.
Kan du föreställa dig en databasmodell som aldrig ändras? Aldrig en enda justering av en kolumn, aldrig tillägget av en främmande nyckel, aldrig behovet av en ny tabell. Ärligt talat, den enda situation som jag kan föreställa mig så är när applikationen som använder databasen inte längre utvecklas och har nått en återvändsgränd:livets slut.