Relacja 1-1, kiedy uzyc?

Witam!

Mam taki dylemat. Mam tabele company i musze dodac 6 nowych kolumn, ktore beda przechowywac pewne ustawienia modulu dla firmy. Niekazda firma bedzie miala wlaczony ten modul wiec jedna firma bedzie przechowywac dane w tych kolumnach inne beda mialy null'e.

Mam dwie opcje do wyboru.
**(1) *zaktualizowac baze danych o te 6 kolumn i dodac je do tabeli company
(2) stworzyc nowa table i relacje 1-(0)1. Tutaj klania sie DEFERRABLE czy jakos, bo skad postgresql ma wiedziec, ze to 1-(0)1 *a nie 1 - many.

Dodam, ze tabela company ma juz 141 kolumn. Uzywam PostgreSQL w wersji 10.

I moje pytanie to co w takim przypadku byscie zrobili i dlaczego? Ktory rozwiazanie wybralibyscie? Ja mam swojego faworyta. Jednakze, jestem ciekaw co inny mysla o tym problemie. I czy moj faworyt to dobre rozwiazanie? :D Moze za bardzo sie rozczulam, ale chce miec pewnosc, ze wybrane przeze mnie rowiazanie jest odpowiednie.

Pozdrawiam! :)

Dodam, ze tabela company ma juz 141 kolumn

To chyba coś poszło nie tak

Jak na moje oko to trochę nie kumasz idei relacyjnych baz danych. Co w przypadku utworzenia kolejnego modułu? Dodajesz kolejne 6 kolumn czy tworzysz kolejną tabelę do jego konfiguracji?

Związek 1:1 jest dobry gdy:

1. Jakaś sekcja jest niewymagana (np. kolumny związane z adresem)
2. Jest dziedziczenie, np. mamy pracownika który może być na UD/UoD ze stawką godzinową albo gościa na UoP

@666: To zalezy. Nowe kolumny dla modulu nie sa wymagane, beda dla wiekszosci firm null'ami. Wiec dla mnie relacja 1-1 ma duzy sens. Jak wrzucilbym to w ta sama tabele to nie bedzie normalizowane (czy jak to sie zwalo w SQL) wie nie ma dla mnie sensu. Chociaz kumpel powiedzial, ze on by wrzucil wszystko w jedna tabele, bo to dalej sa bliskie dane firmy etc. Dla mnie nie ma sensu. Juz nawet pomijajac fakt, ze tabela i tak ma duzo kolumn. W sumie to jakosc tez nie zauwazylem, zeby ta tabela company smigala wolniej przez te 141 kolumn kolumn. Smiga normalnie. Porownywalnie do tabel, ktore maja po np 10-20 kolumn.

Wg mnie relacja 1:1 jest potrzebna tylko w sytuacji, gdy mamy "ciężkie" pola typu BLOB, i nie chcemy ich ani pobierać, ani w ogóle odczytywać z tabelą "podstawową". Tylko na żądanie.

Tworząc dodatkową relację połączoną kluczem obcym ponosisz następujące koszty:

• tworzysz dodatkową tabelę
• w tabeli powiązanej masz dodatkową kolumnę na klucz obcy
• w zapytaniach musisz stosować JOIN, prawdopodobnie za każdym razem

Zamiast dodatkowej relacji, możesz pomyśleć o polu typu JSONB, które nadaje się na trzymanie dodatkowych, rzadko występujących danych. Minusem jest składnia dostępu do pola JSON zarówno przy odczycie jak i modyfikacji danych. Ma to sens kiedy masz ogromną liczbę rekordów liczoną np. w milionach, i szkoda każdego dodatkowego bajta na kilka dodatkowych kolumn.

Marcin.Miga napisał(a):

Wg mnie relacja 1:1 jest potrzebna tylko w sytuacji, gdy mamy "ciężkie" pola typu BLOB, i nie chcemy ich ani pobierać, ani w ogóle odczytywać z tabelą "podstawową". Tylko na żądanie.

No nie tylko.
Np maja być jednocześnie niepuste (czego nie da się zrobić rozszerzajac tabelę), tak pobieżnie wymyśliłem, i pewnie inne racjonalne powody

poniatowski napisał(a):

W sumie to jakosc tez nie zauwazylem, zeby ta tabela company smigala wolniej przez te 141 kolumn kolumn. Smiga normalnie. Porownywalnie do tabel, ktore maja po np 10-20 kolumn.

Powtórzę za @666
Obawiam się płytko to rozumiesz. Dzisiejszy sprzęt wybaczy bardzo dużo co do szybkości.

Wg mnie najcenniejsze jest dobre odwzorowanie "realnego życia", i stawiam dolary przeciw orzechom, te 141 kolumn to przynajmniej kilka bytów, o jakich da się samodzielnie mówić.
najczęściej "dobre odwzorowanie życia" nie daje mierzalnego negatywnego kosztu.

BARDZO RZADKO są sytuacje, że w krytycznych miejscach normalizację doprowadzamy do postaci "dwa i pół", klasyczny przykład: w programie magazynowym powtarzamy pole "typ dokumentu" przy pozycji, choć jego matematyczne miejsce jest przy nagłowku (wpływa na interpretację pozycji, choćby plus/minus/brak efektu).
Ale to jest mowa o poszerzeniu tabeli na 6-15 kolumn o jedną, i mamy racjonalne uzasadnienie.
Do 141 to "trochę" brakuje.

Pointa: jak już masz 141, to dodaj 6, większa kiła z tego nie będzie

Zależy od kilku czynników:

• rozmiaru tabeli jeśli ta wyjściowa company ma już jakieś gigabajty to pewnie był zrobił 1:1
• co do modułowości... Jeśli faktycznie to moduł dla "jednego lub mniejszości" klientów lub ściśle związany z jego branżą /specjalizacją to zrobiłbym 1:1
• jakie to kolumny? Jeśli pola binarne o dużych rozmiarach to zrobiłbym 1:1
• jeśli funkcjonalność wynikająca z tych kolumn daje ogólne korzyści dla systemu na przyszłość a ich znaczenie jest dość ogólne dodałbym to jako kolumny.

Mamy taki system ofertowy, gdzie pewne dane są wspólne niemal dla wszystkich branż t.j. :tytuł, grupa, podgupa, opis, seo-title, seo-keywords itp...
Jednak już ceny są bardzo wyspecjalizowane pod rożne branże i dlatego dla każdej branży mamy inną tabelę w relacji 1:1 z tą główną ofertową a to jaka branża jest w relacji z danym rekordem jest właśnie w rekordzie głównym. W samym CMS szczegóły formularza także są doczytywane dynamicznie w zależności jakiej branży jest dany rekord.

Uważam, że nie ma tu ogólnie poprawnej odpowiedzi i wszystko zależy od tego co się bardziej opłaca i co będzie mniej szkodziło lub pomagało w przyszłości...

Jedynie mogę dodać, że w mojej ocenie każda tabela powinna zawierać dane jak najmniejszego opisywalnego skrawka rzeczywistości. Czyli firma to tylko nazwa, nip, regon itp... Ja nawet adresy mam w osobnej tabeli bo każda firma czy też osoba mogą mieć wiele adresów.

Jednak w Twoim przypadku tych 141 kolumn już nic nie uratuje i chyba to jeden chooy gdzie te nowe kolumny dodasz.

Mam taki dylemat. Mam tabele company i musze dodac 6 nowych kolumn, ktore beda przechowywac pewne ustawienia modulu dla firmy. Niekazda firma bedzie miala wlaczony ten modul wiec jedna firma bedzie przechowywac dane w tych kolumnach inne beda mialy null'e.

Mam dwie opcje do wyboru.
(1) zaktualizowac baze danych o te 6 kolumn i dodac je do tabeli company

Jeśli chodzi Ci o tok myślenia, to zadałbym przy projektowaniu proste pytanie, czy jest szansa, że za pół roku będzie 5 nowych modułów i czynność trzeba będzie powtarzać?
Może zrobić prosty model raz i do tego API umożliwiające zarządzaniem modułami w kontekście company? A nie co miesiąc robić copy&paste 6 atrybutów.

Może nie warto komplikować modelu, bo będzie max 1 moduł?

(2) stworzyc nowa table i relacje 1-(0)1. Tutaj klania sie DEFERRABLE czy jakos, bo skad postgresql ma wiedziec, ze to 1-(0)1 a nie 1 - many.

To nie postgres ma wiedzieć jak Twój model powinien wyglądać, a Ty masz powiedzieć postgresowi czego ma pilnować ;)

w Postgresie była taka koncepcja jak dziedziczenie tabel, ciekawe czy tutaj by mogła mieć zastosowanie