Mitt råd om datamodellering är:
- Du bör gynna valfria (nullbara) kolumner över 1:1-kopplingar allmänt sett . Det finns fortfarande tillfällen där 1:1 är vettigt, vanligtvis kretsar kring subtyping. Människor tenderar att vara mer brådskande när det gäller nollbara kolumner än vad de gör om sammanfogningar konstigt nog;
- Gör inte en modell för indirekt om inte verkligen motiverad (mer om detta nedan);
- Fördelar sammanfogningar framför aggregering. Detta kan variera så det måste testas. Se Oracle vs MySQL vs SQL Server:Aggregation kontra går med för ett exempel på detta;
- Joins är bättre än N+1-val. En N+1-val är till exempel att välja en beställning från en databastabell och sedan utfärda en separat fråga för att få alla rader för den beställningen;
- Skalbarheten för kopplingar är vanligtvis bara ett problem när du gör massutval. Om du väljer en enskild rad och sedan ansluter den till några saker är det sällan ett problem (men ibland är det);
- Främmande nycklar bör alltid indexeras om du inte har att göra med en trivialt liten tabell;
Mer i Databasutvecklingsmisstag gjorda av apputvecklare .
Nu när det gäller direktheten hos en modell, låt mig ge dig ett exempel. Låt oss säga att du designar ett system för autentisering och auktorisering av användare. En överkonstruerad lösning kan se ut ungefär så här:
- Alias (id, användarnamn, användar-id);
- Användare (id, ...);
- E-post (id, användar-id, e-postadress);
- Logga in (id, user_id, ...)
- Inloggningsroller (id, login_id, role_id);
- Roll (id, namn);
- Rollprivilegium (id, role_id, privilege_id);
- Privilege (id, namn).
Så du behöver 6 joins för att komma från det angivna användarnamnet till de faktiska privilegierna. Visst kan det finnas ett verkligt krav för detta men oftare än inte sätts den här typen av system in på grund av handvridning av en utvecklare som tror att de en dag kan behöva det även om varje användare bara har ett alias, användaren att logga in är 1 :1 och så vidare. En enklare lösning är:
- Användare (id, användarnamn, e-postadress, användartyp)
och ja, det är det. Kanske om du behöver ett komplext rollsystem men det är också mycket möjligt att du inte gör det och om du gör det är det ganska lätt att få plats (användartyp blir en främmande nyckel i en användartyps- eller rolltabell) eller så är det i allmänhet enkelt att kartlägga gammalt till nytt.
Det här handlar om komplexitet:det är lätt att lägga till och svårt att ta bort. Vanligtvis är det en konstant vaka mot oavsiktlig komplexitet, vilket är illa nog utan att gå och göra det värre genom att lägga till onödig komplexitet.