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?
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.
ź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)?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.
źródło