relacyjnych baz danych rodzaje wielokrotnego użytkowników

Question

mam 4 rodzaje użytkowników i każdy ma konkretnych danych, ale także udostępniać dane komun, jak username, password ..

Moja pierwsza myśl jest stworzenie głównego users stół user_type kolumna. Następnie, podczas wysyłania zapytań o dane użytkownika, mogę najpierw wybrać ich user_type, a następnie, w zależności od output, uruchomić inne zapytanie, aby pobrać określone dane "typu użytkownika". Nie lubię tego, ponieważ chciałbym pobrać wszystkie dane związane z użytkownikiem za pomocą jednego zapytania i najlepiej za pomocą kluczy obcych.

Drugą ideą jest, aby nie mieć kolumny user_type w tabelii zamiast tego używać klucza obcego, który z konkretnej tabeli typu użytkownika wskaże wiersz tabeli głównej users. Podoba mi się to trochę lepiej, ale myślę, że będę musiał uruchomić N zapytań, gdzie N to liczba typu użytkownika za każdym razem, gdy potrzebuję pobrać dane użytkownika.

Czy są jeszcze jakieś opcje? Jaka byłaby dobra praktyka w takim przypadku?

Dziękujemy

Answer 1

Twój przypadek wygląda jak instancja klasy/podklasy.

Istnieją dwa klasyczne sposoby projektowania tabel SQL do obsługi podklas. Każda ma zalety i wady.

Jeden ze sposobów nazywany jest dziedziczeniem z pojedynczego stołu. W tym projekcie jest tylko jedna tabela dla wszystkich typów użytkowników. Jeśli dana kolumna nie odnosi się do danego wiersza, przecięcie pozostawia NULL. Można dodać kolumnę, aby wskazać typ użytkownika.

Inny sposób nazywany jest "Dziedziczeniem tabeli klas". Jest to podobne do odpowiedzi udzielonej przez Nanego, z niewielkimi zmianami. Istnieje jedna tabela dla użytkowników, z wszystkimi typowymi danymi i polem identyfikatora. Dla każdej podklasy istnieje jedna tabela z danymi, które odnoszą się do tej podklasy. Pole id jest często konfigurowane jako kopia pola id w pasującym wierszu z powrotem w tabeli użytkowników.W ten sposób klucz podklasy może wykonywać podwójne zadanie, działając zarówno jako klucz podstawowy, jak i jako klucz obcy odnoszący się do tabeli użytkowników. Ta ostatnia technika nosi nazwę "Wspólny klucz podstawowy". Wymaga trochę programowania w czasie wstawiania, ale jest tego warte. Wymusza on jeden na jeden charakter relacji i przyspiesza niezbędne sprzężenia.

Możesz wyszukać wszystkie trzy projekty jako tagi w SO lub jako artykuły w Internecie.

single-table-inheritance class-table-inheritance shared-primary-key

Answer 2

Mój sposób to zrobić byłoby utworzyć jedną tabelę „osoba” ze wspólnymi polami oraz jedną tabelę dla każdego rodzaju użytkownika z klucza obcego „person_id”.

W swoim żądaniu wystarczy połączyć dwie tabele z kluczem foreign_key, aby uzyskać wszystkie dane dla jednego typu użytkownika.

Ile rodzajów użytkowników posiadasz?

Answer 3

Chociaż efektywniejsze wykorzystanie miejsca na dysku, problem z dzieleniem na osobne tabele polega na tym, że skutecznie wymaga to warunkowego dołączania - łączenia się z tabelą typu użytkownika opartą na typie user_type. To jest trudny do zakodowania kod jak SQL, a obecnie kogo obchodzi przestrzeń dyskowa?

Lepszą opcją jest posiadanie jednej tabeli użytkownika z wystarczającą ilością kolumn do przechowywania informacji o typie użytkownika dla dowolnego typu, wiedząc, że niektóre kolumny nie będą używane dla niektórych typów użytkowników. "Nieefektywność" posiadania nieużywanych kolumn zostanie z nadwyżką skompensowana przez szybkość wykonania i prostotę zapytania.

Jest również łatwy do rozbudowy, na wypadek gdybyś otrzymał inny typ użytkownika - znacznie łatwiej jest dodawać kolumny niż dodawać tabele, a gdy dodałeś więcej typów użytkowników, zapotrzebowanie na nowe kolumny by się zmniejszyło t wiele różnych rzeczy na temat użytkownika, którego chcesz przechowywać)