Zapisywanie atrybutow obiektu w bazie danych

Witam,

Mam obiekt firme oraz dodatkowe informacje na jego temat, ktore musze zapisac jakos w bazie danych. Moge dodac nowe kolumny do tabeli company albo dodac nowa tabele company_details. Powiedzmy jest to 5 nowych kolumn. One nie sa to wymagane pola wymagadane, moga byc wszystkie puste albo tylko 1-2 wypelnione pola. Tworzyc relacje 1-1 nie ma zbyt wiekszego sensu dla mnie. Moge utworzyc tabele id, company_id, attribute_type, attribute_id, ale to tez pozniej jak bede laczyl w zapytaniach to troche bedzie problematyczne, bo dla jednej firmy bede mial od 0 do 5 wierszy. Jak byscie to zrolibi i dlaczego?

A lista tych atrybutów może sie zmieniać, zależeć od rodzaju firmy, w przyszłości może ich być więcej ? Jak zrobisz nowe kolumny to będzie łatwiej obsłużyć na froncie. Jak dużo użytkowników będzie z tego korzystać. Jak jest to aplikacja wewnętrzna (jedna firma korzysta) to bym dodał kolumny i już. Jak jest to jakiś produkt sprzedawany na rynku to bym zrobił atrybuty, bo będzie bardziej elastycznie i łatwiej będzie dostosować do konkretnego zamówienia.

Lista bedzie taka sama. Raczej watpie, zeby bylo ich wiecej.

Wsadz jako JSON w jedną kolumne - przynajmniej będą się wyszukiwać po tekście - tak można to zrobić

Tez myslalem o 1 kolumnie JSONB, tez wcale nie najgorsze rozwiazanie.

titako napisał(a):

Wsadz jako JSON w jedną kolumne - przynajmniej będą się wyszukiwać po tekście - tak można to zrobić

-1

Tylko wyjątkowo można się zgodzić

poniatowski napisał(a):

Witam,

Tworzyc relacje 1-1 nie ma zbyt wiekszego sensu dla mnie.

Chyba że życie pokaże, że N:1. Jak już masz zrelacjonowaną tabelę, to tylko constraits trzeba zmienić.

Moge utworzyc tabele id, company_id, attribute_type, attribute_id, ale to tez pozniej jak bede laczyl w zapytaniach to troche bedzie problematyczne, bo dla jednej firmy bede mial od 0 do 5 wierszy. Jak byscie to zrolibi i dlaczego?

Ten wzorzec się jakoś nazywa i nie jest zawsze zły. Powiem więcej, jest bardzo dobry gdy jest to "pudełkowy" program wdrażany w zróżnicowanych firmach.
Wart myśleć jako generyczny w systemie, tzn nie tylko do "company", ale i "person", "document" czy co tam masz.

Złożonośc wierszowa i tak by mi się schowała w niskiej warstwie, wyżej by było obiekt biznesowy np z mapą atrubutów Map<String,Object>

S4t napisał(a):

A lista tych atrybutów może sie zmieniać ... Jak jest to aplikacja wewnętrzna (jedna firma korzysta) to bym dodał kolumny i już. Jak jest to jakiś produkt sprzedawany na rynku to bym zrobił atrybuty, bo będzie bardziej elastycznie i łatwiej będzie dostosować do konkretnego zamówienia.

+1

Dodanie 5 nowych kolumn to troche nie jest znormalizowana baza danych. Po co tworzyc 5 kolumn, ktore beda w 75% null? Ja mysle jednak nad 1-n tabela. I pozniej juz zrobie LEFT JOIN LATERAL.