Aktywne Wpisy
TSR44 +297
damianooo8 +9
#zwiazki #kiciochpyta #rozowepaski #niebieskiepaski #malzenstwo
Czy własną żonę można zgwałcić? W sensie czy prawnie jest to tak zaklasyfikowane? Jeśli mam żonę a ona odmówi współżycia, wtedy ja ją do niego przymuszę siłą, to czy to jest prawnie uznane jako gwałt?
Pytam serio. Bo mi ta kwestia kompletnie umknęła ze świadomości. Jak jeszcze chodziłem do kościoła to pamiętam że kościół katolicki zabraniał kobietom odmawiania współżycia.
Czy własną żonę można zgwałcić? W sensie czy prawnie jest to tak zaklasyfikowane? Jeśli mam żonę a ona odmówi współżycia, wtedy ja ją do niego przymuszę siłą, to czy to jest prawnie uznane jako gwałt?
Pytam serio. Bo mi ta kwestia kompletnie umknęła ze świadomości. Jak jeszcze chodziłem do kościoła to pamiętam że kościół katolicki zabraniał kobietom odmawiania współżycia.
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_id
z odwołaniem do "employees" orazemployable_id
,employable_type
z 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