Diagram ER do oceny

0

Witam pisze aplikacje do układania diety oraz treningu i w związku z tym tworze bazę danych. Chciałbym aby można było dodawać produkty wraz z wartościami odżywczymi, te produkty wrzucać do poszczególnych posilkow(np. Śniadanie) i następnie wrzucać gotowe posiłki do dni jedzenia. Zależy mi na tym żeby produkt, posiłek oraz dzień posiadały podliczone wartości odżywcze. Mógłby ktoś zerknąć czy idę w dobrym kierunku.

IMG_7362.jpg

0
macfal napisał(a):

IMG_7362.jpg

jak dla mnie to:

  1. "nutricion values" trzymałbym w tabeli "product" - chyba że masz jakiś konkretny powód dla którego ma to być w oddzielnej tabeli? Dla mnie miałoby to sens chyba tylko w sytuacji gdybyś na przykład w tabeli "product" miał ten sam produkt ale w innym opakowaniu (chociaż i to można byłoby zrobić inaczej)
  2. z "meal product" usunąłbym gramaturę i kalorie i przeniósł do "product" - też nie jestem przekonany czy ta tabela jest CI potrzebna. Jeśli będziesz potrzebował informację o gramaturze i kaloriach możesz to finalnie załatwić kwerendę na poziomie posiłku. Jak dla mnie finalnie z tych 3 tabel mógłbyś zrobić jedną słownikową.
  3. Z kolei "day of eating" i "day of eating meal" też można zrobić jedną transakcyjną, chyba nie ma potrzeby komplikowania.
0

Jeśli chodzi o nutritionalvalue stworzyłem osobno bo chce podliczać także kaloryczność np z całego dnia albo z danego posiłki tylko nie zaznaczyłem relacji pomiędzy nimi. Czyli finalnie powinienem zrezygnować z tabeli dayofeating_meal oraz meal_produkt?

Chciałem zrobić relacje wiele do wielu pomiędzy tabela meal oraz produkt ponieważ jeden posiłek może składać się z wielu różnych produktów a jednocześnie ten sam produkt może być używany w różnych posiłkach. Dlatego stworzyłem tabele łączącą i podobnie myślałem o meal oraz dayofmeal

0

Nie zaczynaj pisania aplikacji od schematu baz danych. Zacznij od podstawowych funkcji.

macfal napisał(a):

Chciałbym aby można było dodawać produkty wraz z wartościami odżywczymi, te produkty wrzucać do poszczególnych posilkow(np. Śniadanie) i następnie wrzucać gotowe posiłki do dni jedzenia. Zależy mi na tym żeby produkt, posiłek oraz dzień posiadały podliczone wartości odżywcze.

Czytam sobie ten opis, i widzę takie funkcje:

  1. Chciałbym dodać produkty z wartościami odżywczymi
    • Ergo - muszę najpierw muszę stworzyć samo dodawanie produktów (np samą nazwę)
  2. Chciałbym dodawać produkty do poszczególnych posiłków
    • No to z kolei to znaczy, że muszę najpierw dodać posiłek
  3. Chciałbym Dodawać posiłki do dni jedzenia
    • A to z kolei oznacza że najpierw muszę zrobić dni jedzenia
  4. Chciałbym, żeby produkt, dzień oraz posiłek miały podliczone wartości odżywcze:
    • Czyli produkt musi mieć podliczone wartości odżywcze
    • Posiłek musi mieć je podliczone
    • I dzień musi mieć je podliczone

Masz tutaj 10 rzeczy które trzeba zrobić, jeśli chciałbyś zrobić taką aplikację. Należałoby je wykonać po kolei, jedna po drugiej, zaczynając od najprostszej.

0
macfal napisał(a):

Jeśli chodzi o nutritionalvalue stworzyłem osobno bo chce podliczać także kaloryczność np z całego dnia albo z danego posiłki tylko nie zaznaczyłem relacji pomiędzy nimi.

jeśli produkt będzie miał kaloryczność, będzie przyporządkowany do posiłku, a posiłek będzie konsumowany pod datą - tak więc nie będziesz miał problemu żeby finalnie podsumować
dla dnia czy posiłku bo masz informację jakie produktu zjadłeś 1. podczas danego posiłku 2. podczas danej daty

Czyli finalnie powinienem zrezygnować z tabeli dayofeating_meal oraz meal_produkt?

ja zrobiłbym z 3 tabel: "nutricion values" "product" :meal product" jedną tabelę: "product" bo nie widzę generalnie wartości która byłąby dodana przy proponowanej strukturze.

z kolei z 2 tabel: "dayofeaintg" i "dayofeatingmeal" zrobił jedną "dayofeatoing" bo to tabela transakcyjna. Dany posiłek będziesz składał z produktów i jadł go o określonej porze dnia (np. śniadanie) i pod okresłoną datą.

0
TytusRomek napisał(a):
macfal napisał(a):

Jeśli chodzi o nutritionalvalue stworzyłem osobno bo chce podliczać także kaloryczność np z całego dnia albo z danego posiłki tylko nie zaznaczyłem relacji pomiędzy nimi.

jeśli produkt będzie miał kaloryczność, będzie przyporządkowany do posiłku, a posiłek będzie konsumowany pod datą - tak więc nie będziesz miał problemu żeby finalnie podsumować
dla dnia czy posiłku bo masz informację jakie produktu zjadłeś 1. podczas danego posiłku 2. podczas danej daty

Czyli finalnie powinienem zrezygnować z tabeli dayofeating_meal oraz meal_produkt?

ja zrobiłbym z 3 tabel: "nutricion values" "product" :meal product" jedną tabelę: "product" bo nie widzę generalnie wartości która byłąby dodana przy proponowanej strukturze.

z kolei z 2 tabel: "dayofeaintg" i "dayofeatingmeal" zrobił jedną "dayofeatoing" bo to tabela transakcyjna. Dany posiłek będziesz składał z produktów i jadł go o określonej porze dnia (np. śniadanie) i pod okresłoną datą.

Ale czemu wy rozmawiacie o tej aplikacji z punktu widzenia bazy danych? :| Przeciez nie tak się robi aplikacje.

O tym trzeba rozmawiać z punktu widzenia użytkownika tej aplikacji - co może zrobić, co może dodać, i jakie wartości potem zobaczy.

0

z punktu widzenia użytkownika ma to działać na zasadzie jak np fitatu. Użytkownik dodaje produkty do posiłków aplikacja mu wszystko podsumowuje

0

Ale czemu wy rozmawiacie o tej aplikacji z punktu widzenia bazy danych? :| Przeciez nie tak się robi aplikacje.

O tym trzeba rozmawiać z punktu widzenia użytkownika tej aplikacji - co może zrobić, co może dodać, i jakie wartości potem zobaczy.

Pełna zgoda,
ale pytanie brzmiało bardzo konkretnie, tak więc od razu podjąłem dyskusję:)

0

Rozumiem ze funkcjonalność muszę określić ale na początku chce stworzyć entity i określić relacje pomiędzy niby następnie zacznę tworzyć funkcje/metody

0
macfal napisał(a):

z punktu widzenia użytkownika ma to działać na zasadzie jak np fitatu. Użytkownik dodaje produkty do posiłków aplikacja mu wszystko podsumowuje

"wszystko podsumowuje" to nie jest dobry opis tego jak wykonać tą aplikację. Takim opisem mogłoby np być to co napisałem w poście poprzednim:

Riddle napisał(a):
  1. Chciałbym dodać produkty z wartościami odżywczymi
    • 1.1 Ergo - muszę najpierw muszę stworzyć samo dodawanie produktów (np samą nazwę)
  2. Chciałbym dodawać produkty do poszczególnych posiłków
    • 2.1 No to z kolei to znaczy, że muszę najpierw dodać posiłek
  3. Chciałbym Dodawać posiłki do dni jedzenia
    • 3.1 A to z kolei oznacza że najpierw muszę zrobić dni jedzenia
  4. Chciałbym, żeby produkt, dzień oraz posiłek miały podliczone wartości odżywcze:
    • 4.1 Czyli produkt musi mieć podliczone wartości odżywcze
    • 4.2 Posiłek musi mieć je podliczone
    • 4.3 I dzień musi mieć je podliczone

Wybierz najprostszą rzecz do zrobienia z tego, czyli chyba 1.1 albo 3.1 byłoby najprostsze. Jak zaczniesz od 1.1, to po prostu pokaż userowi prostą formę do podania nazwy produktu, i potem pokaż dodane produkty (żeby to zaimplementować, to wystarczy Ci jedna tabelka, która ma jedno pole - "nazwa posiłku"). To byłby pierwszy krok. Ewentualnie możesz zaczać od 3.1, i pokazać userowi dni tygodnia.

Jak już masz posiłek który ma tylko nazwę, to możesz pójść w 2.0, czyli dodać wartość odżywczą - pokaż userowi formularz do ustalenia wartości odżywczej, i pokaż tą wartość. To możesz łatwo zaimplementować, po prostu dodając kolumnę do tabelki z produktami.

Potem możesz zrobić 2.1, czyli żeby dało się dodać wartość odżywczą już w momencie dodawania produktu - teraz ta zmiana jest trywialna do dodania.

Mając to, możesz zrobić 4.1, czyli pokazać wartośc odżywczą produktu użytkownikowi.

I tak dalej.

macfal napisał(a):

Rozumiem ze funkcjonalność muszę określić ale na początku chce stworzyć entity i określić relacje pomiędzy niby następnie zacznę tworzyć funkcje/metody

Właściwie to nawet nie musisz nic określać. Wystarczy że zrobisz jedną, najprostszą rzecz jaką możesz dodać - np dodawanie produktu, z samej tylko nazwy. Resztę zostaw na później. Implementacja takiego dodawania produktu powinna być szybka, więc będzie z głowy.

Pytałeś czy idziesz w dobrym kierunku - to mówię Ci - idziesz w złym kierunku, bo nie tworzy się aplikacji zaczynając od "entity" i baz danych. Zaczyna się od funkcjonalności dostępnych dla użytkownika. Bazę danych zostawia się późniejsze/końcowe fazy.

1

Dziękuje za bardzo szczegółowe wytłumaczenie ale czy nie byłoby prościej pisać aplikacje pod gotową bazę danych?

1
macfal napisał(a):

Dziękuje za bardzo szczegółowe wytłumaczenie ale czy nie byłoby prościej pisać aplikacje pod gotową bazę danych?

No właśnie nie.

Dużo prościej jest zbudować bazę danych pod aplikację, niż aplikacje pod bazę danych.

PS: A już pomijając które jest "prostsze", to zbudowanie najpierw aplikacji skutkuje dużo lepszym designem i jakością kodu.

0

dziękuje za pomoc. Spróbuje pójść ta droga ;)

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