Moje rada ohledně datového modelování je:
- Měli byste upřednostňovat volitelné sloupce (s možnou hodnotou Null) před spojením 1:1 obecně řečeno . Stále existují případy, kdy 1:1 dává smysl, obvykle se točí kolem podtypování. Lidé mají tendenci být choulostivější, pokud jde o sloupce s možnou hodnotou null, než o spojení, kupodivu
- Nedělejte model také nepřímé, pokud skutečně odůvodněné (více o tom níže);
- Upřednostněte spojení před agregací. To se může lišit, takže je třeba to otestovat. Viz Oracle vs MySQL vs SQL Server:Agregace vs připojení například toto;
- Spojení jsou lepší než výběry N+1. Výběr N+1 je například výběr objednávky z databázové tabulky a následné zadání samostatného dotazu k získání všech řádkových položek pro danou objednávku;
- Škálovatelnost spojení je obvykle problém pouze, když děláte hromadné výběry. Pokud vyberete jeden řádek a poté jej připojíte k několika věcem, jen zřídka je to problém (ale někdy je);
- Cizí klíče by měly vždy být indexován, pokud nemáte co do činění s triviálně malou tabulkou;
Více v Chyby vývoje databáze způsobené AppDevelopers .
Nyní, pokud jde o přímost modelu, dovolte mi uvést příklad. Řekněme, že navrhujete systém pro autentizaci a autorizaci uživatelů. Přepracované řešení může vypadat nějak takto:
- Alias (id, uživatelské jméno, user_id);
- Uživatel (id, ...);
- E-mail (id, user_id, e-mailová adresa);
- Přihlášení (id, user_id, ...)
- Přihlašovací role (id, login_id, role_id);
- Role (id, jméno);
- Oprávnění role (id, role_id, privilegium_id);
- Oprávnění (ID, jméno).
Takže potřebujete 6 spojení, abyste se dostali od zadaného uživatelského jména ke skutečným oprávněním. Jistě na to může existovat skutečný požadavek, ale častěji je tento druh systému zaváděn kvůli ručnímu ždímání ze strany některých vývojářů, kteří si myslí, že by ho mohli někdy potřebovat, i když každý uživatel má pouze jeden alias, uživatel pro přihlášení je 1 :1 a tak dále. Jednodušší řešení je:
- Uživatel (id, uživatelské jméno, e-mailová adresa, typ uživatele)
no a je to. Možná, pokud potřebujete složitý systém rolí, ale je také docela možné, že ne, a pokud ano, je poměrně snadné jej začlenit (typ uživatele se stane cizím klíčem v tabulce typů uživatelů nebo rolí) nebo je obecně jednoduché mapovat od starého k novému.
To je věc složitosti:je snadné přidat a těžko odstranit. Obvykle je to neustálé bdění proti nezamýšlené složitosti, což je dost špatné, aniž by to šlo a zhoršovalo to přidáváním zbytečné složitosti.