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:)

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

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

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ł.

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.

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.