Patrzac z punku widzenia osoby ktora nie wie do czego ta baza ma sluzyc imo opcja B, nie musisz potem w przyszłości martwic sie o podpiecie pracownika do firmy i sklepu jednoczesnie, ulatwi to pisanie zapytan. tylko stawialbym raczej na opcje dwukolumnowa employeesid, jobid, a potem to cz to jest firma czy nie to juz powinna wiedziec tablica docelowa tj "Firma" i "Sklep"
@janek_: Nie, albo do firmy albo do sklepu. Natomiast sklepy mogą być przypisany do firmy.
Musze mieć możliwość pobrania pracowników przypisanych do firmy oraz drugą opcję pobrania wszystkich pracowników (przypisanych do firmy oraz przypisanych do sklepów które podlegają pod firmę)
@GreeenOne: Rozwiązanie A jest najprostszym podejściem i może być wystarczające, jeśli jesteś pewien, że struktura twojego systemu się nie zmieni. Jednak w praktyce, systemy często ewoluują i co za tym idzie, pojawia się potrzeba większej elastyczności. W takim przypadku, rozwiązanie C (polimorficzna relacja) oferuje większą skalowalność i elastyczność, pozwalając na łatwe rozszerzenie modelu o nowe typy przypisań bez konieczności modyfikacji schematu bazy danych.
Jeśli jednak zdecydujesz się na rozwiązanie A, kluczową
@GreeenOne: ja zawsze staram się to planować tak, żeby było skalowalne, więc wybrałbym opcję C.
Tabela "employees" zawiera pracowników Tabela "shops" zawiera sklepy Tabela "companies" zawiera firmy Tabela "employables" jako polimorficzny pivot zawiera employees_id z odwołaniem do "employees" oraz employable_id, employable_type z odwołaniem do sklepu, firmy czy cokolwiek innego co jeszcze kiedyś trzeba będzie dodać.
@GreeenOne: Problem wydaje się bardzo prosty. Tu są 2 możliwe relacje:
- 1:N - na przykład kiedy sklep należy do jednej firmy, ale firma może mieć wiele sklepów, wystarczą 2 tabele: tabela firmy i tabela sklepów z referencją do firmy - N:N - na przykład kiedy różni pracownicy mogą być delegowani do różnych sklepów, wtedy 3 tabele: tabela pracowników, tabela sklepów i tabela łącząca pracowników ze sklepami
@nowiutki: Taa, skalowalne a potem w bazie 1 tys. rekordów xD
Rozwiązanie A - dwie kolumny z id firm / sklepów. Jeśli pojawi się potrzeba zrobienia powiązania 1:N to zawsze można później dodać tabele albo lepiej zmienić typ kolumny na listę bo w ilu sklepach / firmach może pracować pracownik? W trzech?
@nowiutki: To, że macie tendencje do komplikowania rozwiązań pod pretekstem takich rzeczy jak "skalowalność", która potem często wcale nie jest potrzebna.
@Krolik: z doświadczenia wiem, że znacznie większą "komplikacją" jest potem migracja danych jak klient zmieni zdanie.
U mnie klasykiem jest zawsze multijęzyczność. Klient zarzeka się, że aplikacja ma być prosta, dane przechowywane w jednym języku, a po roku pisze, że właściwie to chciałby jeszcze po angielsku i niemiecku. I cała struktura bazy danych do przewalenia, bo przecież "skalowalność" to "komplikacja".
Także nie wiem czy bawisz się we freelancerkę, czy masz ten
Przypominam, że Iran to ruskie pachołki. Izrael jest jaki jest, ale jest naszym sojusznikiem i sojusznikiem USA. Kibicowanie w tym sporze Iranowi jest zdradą stanu i byciem pożytecznym idiotą xDDDD
Mam pewien problem ponieważ nie wiem jak poprawnie zaplanować tabelki, relacje i nazwę.
Dajmy na to mam "Firma", "Sklep" i "Pracownicy". Pracownicy mogą być przypisani do firmy lub danego sklepu. I teraz jak to ogarnąć?
Rozwiązanie A
Stworzyć tabelkę w której Pracownicy mają relację belongTo i kolumny firmid - shopid
Rozwiązanie B
Stworzyć dodatkową tabelkę która będzie zawierać: employeesid, firmid, shopid
Rozwiązanie C
Zrobić polymorphic relationship gdzie będzie:
modelid oraz modelname
Wydaje mi się, że rozwiązanie A jest najlepsze, bo na razie nie planuję poszerzania tego.
Jeśli rozwiązanie A, to jak nazwać tabelkę? Employees - Shopemployees - Firmshopemployees
employeesid, jobid, a potem to cz to jest firma czy nie to juz powinna wiedziec tablica docelowa tj "Firma" i "Sklep"
Musze mieć możliwość pobrania pracowników przypisanych do firmy oraz drugą opcję pobrania wszystkich pracowników (przypisanych do firmy oraz przypisanych do sklepów które podlegają pod firmę)
@janek_ @antagonista1111 Bardzo dziękuję wam za pomoc :)
Jeśli jednak zdecydujesz się na rozwiązanie A, kluczową
Tabela "employees" zawiera pracowników
Tabela "shops" zawiera sklepy
Tabela "companies" zawiera firmy
Tabela "employables" jako polimorficzny pivot zawiera
employees_idz odwołaniem do "employees" orazemployable_id,employable_typez odwołaniem do sklepu, firmy czy cokolwiek innego co jeszcze kiedyś trzeba będzie dodać.- 1:N - na przykład kiedy sklep należy do jednej firmy, ale firma może mieć wiele sklepów, wystarczą 2 tabele: tabela firmy i tabela sklepów z referencją do firmy
- N:N - na przykład kiedy różni pracownicy mogą być delegowani do różnych sklepów, wtedy 3 tabele: tabela pracowników, tabela sklepów i tabela łącząca pracowników ze sklepami
Rozwiązanie A - dwie kolumny z id firm / sklepów. Jeśli pojawi się potrzeba zrobienia powiązania 1:N to zawsze można później dodać tabele albo lepiej zmienić typ kolumny na listę bo w ilu sklepach / firmach może pracować pracownik? W trzech?
@Krolik: i co z tego?
U mnie klasykiem jest zawsze multijęzyczność. Klient zarzeka się, że aplikacja ma być prosta, dane przechowywane w jednym języku, a po roku pisze, że właściwie to chciałby jeszcze po angielsku i niemiecku. I cała struktura bazy danych do przewalenia, bo przecież "skalowalność" to "komplikacja".
Także nie wiem czy bawisz się we freelancerkę, czy masz ten