Czy relacja jeden do jednego jest znormalizowana?

Rozważmy, że mamy duży zestaw danych statystycznych do zapisu; np. 20-30 INTkolumn. Czy lepiej jest przechowywać cały zestaw w jednej tabeli, ponieważ wszystkie należą do rekordu LUB tworząc kolejną tabelę związaną z relacją jeden do jednego.

Zaletą tego pierwszego jest unikanie JOINi szybki dostęp do wszystkich danych statystycznych dla odpowiedniego rekordu.

Zaletą tego drugiego jest utrzymanie porządku w kolumnie. Pierwsza kolumna wymaga intensywnego odczytu, a druga intensywnego zapisu. Oczywiście myślę, że nie ma to znaczącego wpływu na wydajność, ponieważ używam InnoDB z blokowaniem na poziomie wiersza.

Zasadniczo chcę wiedzieć, czy rozdzielenie różnych zestawów danych dla jednego rekordu jest praktyczne?

— Googlebot
źródło

„Znormalizowany” oznacza pierwszą postać normalną (1NF) i jest podstawowym wymogiem modelu relacyjnego. „W pełni znormalizowany” oznacza 5NF lub więcej. Proponowana tabela „jeden do jednego” ma większą szansę na bycie w wyższej normalnej formie (być może nawet w 6NF) niż twoja obecna, ponieważ jest rozłożona! Jakie normalne formy spełnia Twój istniejący stół?

— dniu

@onedaywhen Podobnie jak wiele innych, krok po kroku nie przestrzegam normalizacji, ponieważ czasem pomocna jest również dezormalizacja. Ogólnie rzecz biorąc, cała baza danych powinna mieć poziom normalizacji między 3NF - 5NF (zawsze mam problem z 4NF!)

— Googlebot

Odpowiedzi:

Jeśli pasuje do zasad normalizacji, to relacje 1: 1 można znormalizować (z definicji!) - Innymi słowy, nie ma nic w relacjach 1: 1, które uniemożliwiałyby im przestrzeganie normalnych form.

Aby odpowiedzieć na twoje pytanie dotyczące praktyczności relacji 1: 1, zdarza się, że jest to całkowicie przydatna konstrukcja, na przykład gdy masz podtypy z wyraźnymi predykatami (kolumnami).

Powody, dla których użyjesz relacji 1: 1, zależą od twojego punktu widzenia. DBA zwykle myślą o wszystkim jako o decyzji dotyczącej wydajności. Projektanci danych i programiści zwykle myślą o tych decyzjach jako o projektowaniu lub modelowaniu. W rzeczywistości te punkty widzenia nakładają się na siebie. To zależy od twoich perspektyw i priorytetów. Oto kilka przykładów motywacji dla relacji 1: 1:

Masz pewien podzbiór kolumn, które są bardzo szerokie i chcesz je fizycznie posegregować w magazynie ze względu na wydajność.
Masz pewien podzbiór kolumn, które nie są często odczytywane lub aktualizowane i chcesz je odróżnić od często używanych kolumn ze względu na wydajność.
Niektóre kolumny są opcjonalne, ale są obowiązkowe, gdy wiadomo, że dany rekord jest określonego typu.
Masz kilka kolumn, które logicznie należą do podtypu i chcesz je modelować, aby dobrze pasowały do modelu obiektowego kodu.
Masz kilka kolumn, które można zastosować tylko do niektórych podtypów nadtypu encji, i chcesz, aby Twój schemat wymuszał brak tych danych dla innych podtypów.
Masz kilka kolumn należących do jednostki, ale musisz chronić te konkretne kolumny, stosując bardziej restrykcyjne reguły dostępu (np. Wynagrodzenie w tabeli pracowników).

Jak widać, czasami sterownik jest wydajnością, czasem czystością modelu, lub po prostu pragnieniem pełnego wykorzystania deklaratywnych reguł schematu.

— Joel Brown
źródło

You have some subset of columns that are very wide and you want to segregate them physically in your storage for performance reasons.

W jaki sposób ich segregacja poprawia wydajność (zakładając, że dostęp do kolumn zawsze uzyskuje się za każdym razem, gdy znajduje się główna tabela)?

— Gili

@Gili - Jeśli twoje założenie jest prawdziwe, ta sprawa nie miałaby zastosowania. Segregacja dużych i rzadko potrzebnych kolumn pozwala na zmieszczenie większej liczby wierszy na stronie, co umożliwia szybsze pobieranie najczęściej używanych kolumn. Oczywiście czytanie segregowanych kolumn wraz z powszechnie używanymi kolumnami byłoby wolniejsze, ponieważ konieczne jest połączenie.

— Joel Brown

Chcę segregować wzdłuż często używanych kolumn ze względów projektowych (rozdzielenie problemów, zwiększone ponowne użycie kodu). Czy ktoś opublikował oszacowanie kosztu takiego przyłączenia? Czy są one nieistotne, czy czymś, o co powinienem się martwić w perspektywie długoterminowej?

— Gili

@ Gil - re: koszt przyłączeń: Nie ma właściwej odpowiedzi na to pytanie oprócz „zależy”. Na koszt przyłączenia wpływa wiele czynników. Odpowiedź na pytanie, czy są one nieistotne, jest jeszcze trudniejsza, ponieważ jest to ostatecznie subiektywne. Najlepszym sposobem na udzielenie odpowiedzi na pytanie jest wykpienie niektórych danych testowych i przeprowadzenie testów objętościowych. Wypróbuj to na dwa sposoby i sprawdź, czy potrafisz rozpoznać różnicę, używając rzeczywistych woluminów danych (cokolwiek to oznacza dla twojej aplikacji).

— Joel Brown

Zrobiłem to i otrzymałem zaskakujące wyniki: dba.stackexchange.com/q/74693/4719 Przyznaję, że nie jest to typowy przykład normalizacji, ale nie podkreśla, że JOIN są (wciąż) bardzo drogie.

— Gili

Główne powody, dla których użyłbyś mapowania jeden do jednego, aby podzielić dużą tabelę na dwie, to na przykład ze względu na wydajność:

a) Tabela zawiera dane binarne / clob / blob w często dostępnej tabeli, co spowalnia wydajność, ponieważ duże kolumny są obsługiwane inaczej.

b) Tabela ma wiele kolumn, do których można uzyskać dostęp za pomocą różnych zapytań, dlatego wydajność jest obniżona, dlatego należy przenieść powiązane kolumny do osobnej tabeli, aby poprawić wydajność dostępu

Jednak posiadanie wielu kolumn liczb całkowitych nie uzasadnia dodatkowego wysiłku polegającego na rozbiciu tabeli na osobne tabele i konieczności zapytania do nich.

— Stephen Senkomago Musoke
źródło

bardzo dobry punkt do wyjaśnienia problemu!

— Googlebot