[GreeenOne]

#laravel #programowanie #bazadanych #sql #php

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

[janek_]

@GreeenOne: A czy pracownik może być przypisany do więcej niż jednej firmy/sklepu na raz?

[a.....1]

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"

[GreeenOne]

@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ę)

@janek_ @antagonista1111 Bardzo dziękuję wam za pomoc :)

[eternalmarcos]

@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ą

[n.....i]

@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ć.

[Turbojurek]

@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

[Krolik]

@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?

[K.....o]

@GreeenOne: tabele pośrednie trzeba porobić która przechowa id sklepu i id usera

[n.....i]

Taa, skalowalne a potem w bazie 1 tys. rekordów xD

@Krolik: i co z tego?

[Krolik]

@nowiutki: To, że macie tendencje do komplikowania rozwiązań pod pretekstem takich rzeczy jak "skalowalność", która potem często wcale nie jest potrzebna.

[n.....i]

@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