Moja rada dotycząca modelowania danych to:
- Powinieneś preferować kolumny opcjonalne (nie dopuszczające wartości null) zamiast sprzężeń 1:1 ogólnie mówiąc . Nadal istnieją przypadki, w których 1:1 ma sens, zwykle obracając się wokół podtypów. Ludzie są bardziej wrażliwi, jeśli chodzi o kolumny z wartościami null, niż dziwnie o połączeniach;
- Nie rób modelu też pośrednio, chyba że naprawdę uzasadnione (więcej na ten temat poniżej);
- Przychylność łączy się z agregacją. Może się to różnić, dlatego należy to przetestować. Zobacz Oracle vs MySQL vs SQL Server:agregacja a przyłączenia jako przykład tego;
- Połączenia są lepsze niż N+1 zaznaczeń. Wybór N+1 to na przykład wybranie zamówienia z tabeli bazy danych, a następnie wysłanie oddzielnego zapytania, aby uzyskać wszystkie pozycje dla tego zamówienia;
- Skalowalność złączeń jest zazwyczaj tylko problem, gdy robisz masowe wybory. Jeśli wybierzesz pojedynczy wiersz, a następnie dołączysz go do kilku rzeczy, rzadko jest to problem (ale czasami jest);
- Klucze obce powinny zawsze być indeksowane, chyba że masz do czynienia z banalnie małym stołem;
Więcej w artykule Błędy podczas tworzenia bazy danych popełniane przez deweloperów aplikacji .
Teraz, jeśli chodzi o bezpośredniość modelu, podam przykład. Załóżmy, że projektujesz system do uwierzytelniania i autoryzacji użytkowników. Przeprojektowane rozwiązanie może wyglądać mniej więcej tak:
- Alias (identyfikator, nazwa użytkownika, identyfikator_użytkownika);
- Użytkownik (identyfikator, ...);
- E-mail (id, user_id, adres e-mail);
- Zaloguj się (id, user_id, ...)
- Role logowania (id, login_id, role_id);
- Rola (identyfikator, nazwa);
- Przywilej roli (id, role_id, privilege_id);
- Przywilej (identyfikator, imię).
Potrzebujesz więc 6 przyłączeń, aby przejść od wprowadzonej nazwy użytkownika do rzeczywistych uprawnień. Pewnie, że może to być rzeczywiste wymaganie, ale najczęściej ten rodzaj systemu jest wprowadzany z powodu załamywania rąk przez niektórych programistów, którzy myślą, że mogą go kiedyś potrzebować, mimo że każdy użytkownik ma tylko jeden alias, użytkownik do zalogowania się to 1 :1 i tak dalej. Prostsze rozwiązanie to:
- Użytkownik (identyfikator, nazwa użytkownika, adres e-mail, typ użytkownika)
i cóż, to wszystko. Być może, jeśli potrzebujesz złożonego systemu ról, ale jest też całkiem możliwe, że tego nie zrobisz, a jeśli to zrobisz, jest to dość łatwe do umieszczenia (typ użytkownika staje się kluczem obcym w tabeli typów użytkowników lub ról) lub generalnie jest to łatwe do zmapowania od starego do nowego.
Chodzi o złożoność:łatwo ją dodać, a trudno ją usunąć. Zwykle jest to ciągłe czuwanie przeciwko niezamierzonej złożoności, która jest wystarczająco zła, gdy się nie zagłębia i pogarsza ją przez dodanie niepotrzebnej złożoności.
