Mijn advies over datamodellering is:
- U moet de voorkeur geven aan optionele (nullable) kolommen boven 1:1 joins in het algemeen . Er zijn nog steeds gevallen waarin 1:1 zinvol is, meestal draait het om subtypen. Mensen hebben de neiging om meer preuts te zijn als het gaat om kolommen met nulwaarden dan vreemd genoeg over joins;
- Maak niet teveel een model indirect tenzij echt gerechtvaardigd (meer hierover hieronder);
- Voorkeur wint het van aggregatie. Dit kan variëren, dus het moet worden getest. Zie Oracle vs MySQL vs SQL Server:Aggregation vs sluit zich aan voor een voorbeeld hiervan;
- Joins zijn beter dan N+1-selects. Een N+1-selectie is bijvoorbeeld het selecteren van een bestelling uit een databasetabel en vervolgens een afzonderlijke query uitvoeren om alle regelitems voor die bestelling te krijgen;
- De schaalbaarheid van joins is meestal alleen een probleem als je massaselecties doet. Als je een enkele rij selecteert en die vervolgens aan een paar dingen toevoegt, is dit zelden een probleem (maar soms wel);
- Buitenlandse sleutels moeten altijd worden geïndexeerd, tenzij je te maken hebt met een triviaal kleine tabel;
Meer in Databaseontwikkelingsfouten gemaakt door AppDevelopers .
Wat betreft de directheid van een model, laat me je een voorbeeld geven. Stel dat u een systeem ontwerpt voor authenticatie en autorisatie van gebruikers. Een doorontwikkelde oplossing kan er ongeveer zo uitzien:
- Alias (id, gebruikersnaam, user_id);
- Gebruiker (id, ...);
- E-mail (id, user_id, e-mailadres);
- Aanmelden (id, user_id, ...)
- Inlogrollen (id, login_id, role_id);
- Rol (ID, naam);
- Rolprivilege (id, role_id, privilege_id);
- Privilege (id, naam).
Je hebt dus 6 joins nodig om van de ingevoerde gebruikersnaam naar de daadwerkelijke privileges te gaan. Natuurlijk kan hier een daadwerkelijke vereiste voor zijn, maar vaker wel dan niet wordt dit soort systeem ingevoerd vanwege de handwringing door een ontwikkelaar die denkt dat ze het ooit nodig zullen hebben, ook al heeft elke gebruiker maar één alias, de gebruiker om in te loggen is 1 :1 enzovoort. Een eenvoudigere oplossing is:
- Gebruiker (id, gebruikersnaam, e-mailadres, gebruikerstype)
en, nou ja, dat is het. Misschien als je een complex rollensysteem nodig hebt, maar het is ook heel goed mogelijk dat je dat niet doet en als je dat wel doet, is het redelijk eenvoudig in te voegen (het gebruikerstype wordt een externe sleutel in een gebruikerstype of rollentabel) of is het over het algemeen eenvoudig om de oud naar nieuw.
Dit heeft te maken met complexiteit:het is gemakkelijk toe te voegen en moeilijk te verwijderen. Meestal is het een constante wake tegen onbedoelde complexiteit, wat al erg genoeg is zonder te gaan en het erger te maken door onnodige complexiteit toe te voegen.