Czy ta relacja ma sens?

0

Hej, ostatnio tworze projekt do zarządzania hotelem i trafiłem na problem z relacją. title

Chodzi mi o relacje Hotel -> Floor -> Room ze screenu. W swojej bazie danych nie mam bezpośredniego połączenia pomiędzy hotelem, a pokojami tzn. Mam hotel, który posiada conajmniej jeden poziom, który posiada x pokoi. Przy pobieraniu pokoi lub edycji pokoju robi się to irytutające, bo pobieram pokoje z wszystkich poziomów przynależnych do hotela, a nie bezpośrednio z hotela. Jeśli bym chciał dodać taką relacje to jak mądrze zabezpieczyć po stronie entity frameworka taką relacje, żeby nie powstawały błędy podczas pobierania danych?

0

Miałem kiedyś podobną zagwostkę w nieco innej relacji, ale problem podobny i doszedłem do wniosku, że jest to kompletny bezsens. Głównie dlatego, że floor nie ma żadnych specyficznych dla siebie właściwości. Gdyby np. miały się tam pojawić informacje typu: kolor ścian na danym piętrze, zezwolenie na palenie, wyjście na schody przeciwpożarowe, strefa vipów itd. to owszem wówczas ma to sens.

Umieściłbym floor przy pokojach jeśli nie planujesz dodawania właściwości do pięter, a nawet gdybyś to planował, wówczas w tabeli Floor powinno pojawić się ID, bo piętro 2 w hotelu X nie bedzie tym samym piętrem co piętro 2 w hotelu Y.

To tak jakbyśmy mając tabelę użytkownicy chcieli wyekstrachować wiek użytkowników do postaci 120 rekordów w osobnej tabeli (po jednym dla wieku w przedziale od 1 do 120 lat). Następuje tu redundacja, bo wiek będzie podany tak czy owak w tabeli z użytkownikami.

Jest sens podziału jednej tabeli na dwie w przypadku, gdy do tej drugiej trafiają rzadko używane dane, które dość mocno zwiększają wielkość pierwszej tabeli.

Zresztą podstawowe pytanie brzmi jaki jest cel takiej relacji? Każda struktura w bazie danych powinna mieć określoną przydatność dla zadań wykonywanych dla końcowego użytkownika.

0

Tu jeszcze w ogóle pojawia się pytanie dlaczego np. w rezerwacjach nie masz numeru id?

0

Obrazek pokazuje przykładową tabele, w swojej bazie danych mam dodaną tabele floor, która posiada też inne kolekcje i inne właściwości.

0

No to zły przykład podałeś :), bo w podanym przykładzie tabel floor to tylko numery pięter.

Jeśli masz w tabeli Floors właściwości specyficzne wyłącznie dla konkretnego piętra, to nie tylko ma sens, ale jest wręcz wymaganym rozwiązaniem :)

0
webkam napisał(a):

No to zły przykład podałeś :), bo w podanym przykładzie tabel floor to tylko numery pięter.

Jeśli masz w tabeli Floors właściwości specyficzne wyłącznie dla konkretnego piętra, to nie tylko ma sens, ale jest wręcz wymaganym rozwiązaniem :)

Głównie chodzi mi o to że tutaj mam przykład bazy w której hotel posiada relacje pomiędzy pokojami i piętrami, jednocześnie piętra posiadają też wiele pokoi. W moim projekcie by mi to uprościło pobieranie obiektów. Ten obrazek pochodzi z jakiegoś kursu programowania gdzieś z jakiegoś uniwerku i miał taką relacje, dlatego się pytam czy jest sens i jak można taki utworzyć w entity frameworku bez tworzenia błedów

1

Po kiego grzyba Ci ten Floor w modelu? Jaką wartość biznesową ma umieszczanie piętra w modelu?

1 użytkowników online, w tym zalogowanych: 0, gości: 1