Projekt bazy danych |
Projekt bazy danych |
31.10.2019, 14:13:34
Post
#1
|
|
Grupa: Zarejestrowani Postów: 102 Pomógł: 0 Dołączył: 16.01.2014 Ostrzeżenie: (0%) |
Witam, pisze tutaj ponieważ nie wiem czy zrobiłem to we właściwy sposób. Wymyśliłem sobie apliakcję do genrowanie diet. Chodzi mi o problem ze strukturą tabel:
Mam takie table: users: -id -name -bmi -calories ingredients: -id -name -calories_per_100g meals: -id -name -calories_min -weight_min ingredient_meal: -id -ingredient_id -meal_id diets: -id -name -day -meal_id -user_id Czy według was struktura tabel jest ok? Np chciałbym generować diety na 30 dni dla jednego usera. Będe bardzo wdzięczny za podpowiedzi:) |
|
|
3.11.2019, 19:07:47
Post
#2
|
|
Grupa: Moderatorzy Postów: 6 070 Pomógł: 860 Dołączył: 10.12.2003 Skąd: Dąbrowa Górnicza |
1. W tabeli ingredient_meal kolumn id jest zbędna - klucz główny powinien być na 2 pozostałych kolumnach (będących równocześnie kluczami obcymi).
2. Czy w tabeli ingredient_meal nie potrzebujesz również kolumn określających ilości danego składnika? 3. W odniesieniu do Cytat chciałbym generować diety na 30 dni dla jednego usera tabela diets wydaje się być niepoprawna. Jak zobaczysz ile diet miał użytkownik? Co jeśli (hipotetycznie) 1 użytkownik w jednym czasie ma N diet? Bardziej prawidłowe byłoby chyba: diets: id name user_id diet_meals: diet_id day meal_id Legenda: klucz główny, klucz obcy, klucz główny będący kluczem obcym |
|
|
3.11.2019, 19:17:18
Post
#3
|
|
Grupa: Zarejestrowani Postów: 6 365 Pomógł: 1114 Dołączył: 30.08.2006 Ostrzeżenie: (0%) |
1. W tabeli ingredient_meal kolumn id jest zbędna - klucz główny powinien być na 2 pozostałych kolumnach (będących równocześnie kluczami obcymi). Wiele ORMów bardzo nie lubi kluczy złożonych. Ogólnie też łatwiej się zarządza mając dodatkowy indeks. Ja bym też zostawił. -------------------- |
|
|
3.11.2019, 19:51:09
Post
#4
|
|
Grupa: Moderatorzy Postów: 6 070 Pomógł: 860 Dołączył: 10.12.2003 Skąd: Dąbrowa Górnicza |
To, że systemy narzucają ograniczenia nie oznacza, że trzeba się na nie ot tak godzić. Ta kolumna jest po prostu zbędna, a przy metodyce zapisu "wywal powiązania -> wstaw nowe powiązania" wartości id będą rosły w astronomicznym tempie. Poza tym kolega pytał o schemat bazy, a nie schemat pod konkretne narzędzie (ORM) więc przy takim rozpatrywaniu kolumna tym bardziej nadaje się do wywalenia.
|
|
|
3.11.2019, 20:01:32
Post
#5
|
|
Grupa: Zarejestrowani Postów: 6 365 Pomógł: 1114 Dołączył: 30.08.2006 Ostrzeżenie: (0%) |
Ogólnie się zgadzam ale... tym id może być uuid a w wielu systemach wręcz musi. Też nie ta skala ale np podczas projektowania mikroserwisów relacje wcale nie są oczywistością. W kontekście MS taka struktura może być poprawna ale wcale nie musi.
-------------------- |
|
|
Wersja Lo-Fi | Aktualny czas: 27.04.2024 - 01:47 |