Mit råd om datamodellering er:
- Du bør foretrække valgfrie (nulbare) kolonner frem for 1:1 joinforbindelser generelt set . Der er stadig tilfælde, hvor 1:1 giver mening, som normalt drejer sig om subtyping. Folk har en tendens til at være mere sarte, når det kommer til nullable kolonner, end de gør om joinforbindelser mærkeligt;
- Lav ikke også en model indirekte medmindre virkelig berettiget (mere om dette nedenfor);
- Foretrukket joinforbindelser frem for aggregering. Dette kan variere, så det skal testes. Se Oracle vs MySQL vs SQL Server:Aggregation vs Joins for et eksempel på dette;
- Joins er bedre end N+1-valg. Et N+1-valg er for eksempel at vælge en ordre fra en databasetabel og derefter udstede en separat forespørgsel for at få alle linjeposterne for den ordre;
- Skalerbarheden af joinforbindelser er normalt kun et problem, når du laver masseudvælgelser. Hvis du vælger en enkelt række og derefter forbinder det med nogle få ting, er dette sjældent et problem (men nogle gange er det);
- Fremmednøgler skal altid blive indekseret, medmindre du har at gøre med en trivielt lille tabel;
Mere i Databaseudviklingsfejl lavet af appudviklere .
Hvad angår en models direktehed, så lad mig give dig et eksempel. Lad os sige, at du designer et system til godkendelse og godkendelse af brugere. En overkonstrueret løsning kan se sådan ud:
- Alias (id, brugernavn, bruger_id);
- Bruger (id, ...);
- E-mail (id, bruger_id, e-mailadresse);
- Login (id, bruger_id, ...)
- Login-roller (id, login_id, rolle_id);
- Rolle (id, navn);
- Rolleprivilegium (id, rolle_id, privilege_id);
- Privilege (id, navn).
Så du skal bruge 6 joins for at komme fra det indtastede brugernavn til de faktiske privilegier. Sikker på, at der kan være et reelt krav til dette, men oftere end ikke er denne type system sat ind på grund af håndvridning af nogle udviklere, der tror, at de en dag kan få brug for det, selvom hver bruger kun har et alias, bruger til at logge på er 1 :1 og så videre. En enklere løsning er:
- Bruger (id, brugernavn, e-mailadresse, brugertype)
og jamen det er det. Måske hvis du har brug for et komplekst rollesystem, men det er også meget muligt, at du ikke gør det, og hvis du gør det, er det rimeligt nemt at sætte ind (brugertypen bliver en fremmednøgle i en brugertype- eller rolletabel), eller det er generelt ligetil at kortlægge gammelt til nyt.
Det her handler om kompleksitet:det er nemt at tilføje og svært at fjerne. Normalt er det en konstant vagt mod utilsigtet kompleksitet, hvilket er slemt nok uden at gå og gøre det værre ved at tilføje unødvendig kompleksitet.