Projekt Kalkulator żywnościowy

0

Witam

Chciałbym zrobić kalkulator żywnościowy (jako projekt na uczelnię), ale natrafiłem na małą przeszkodę. Otóż ma to wyglądać mniej więcej tak:
user image
lub tak:
user image

Nie wiem którą wersję lepiej wybrać - ta pierwsza kazałaby użytkownikowi ręcznie wpisywać każdy typ węglowodanów/białek/etc., ta druga miałaby je natomiast od razu określone, wystarczyłoby wpisać ilość.
Kolejna rzecz - nie bardzo wiem w jaki sposób sprawnie połączyć produkty z osobami (tak, żeby było wiadomo jakie produkty wybrała dana osoba).
Chciałbym również w jakiś sposób obliczać BMI osoby, jej dzienne zapotrzebowanie na wartości odżywcze oraz pokrycie dziennego zapotrzebowania przez dany produkt dla danej osoby.
Jestem trochę newbie w tym, więc wszelkie wskazówki będą przydatne. Z góry dziękuję za pomoc. :)

0

oba są niepoprawne. Jak już to jedna tabela z polami id, id_produktu, element i ilosc oraz ew. 'typ', gdzie było by napisane co to jest (minerał, witamina, ...) zamiast tych czterech dodatkowych, a już drugi wariant to totalna pomyłka, bo równie dobrze możesz to wszystko wsadzić do tabeli produkt

0

No tak, tylko że mam wymóg min. 5 relacji. Myślałem nad czymś takim, nie wiem czy mogłoby to tak wyglądać:

user image

0

To tylko taki przykład roboczy, w każdym razie dziękuję za odpowiedzi. Dlatego bardziej skłaniam się do tego pomysłu, który został określony jako "pomyłka" :) W takim wypadku z każdym produktem powiązane byłyby 4 zestawy - zestaw białek, witamin, minerałów i węglowodanów. Niektóre wartości mogłyby zostać puste, inne nie, ale wszystko byłoby widać jak na dłoni - nie trzeba by wpisywać za każdym razem nazwy. Dla każdego produktu istniałby wtedy osobny "zestaw" wartości odżywczych (określany przez id). Wtedy też produkty mogłyby być identyfikowane przez nazwę, no bo po co im ID (istnieje tylko jeden produkt posiadający konkretny zestaw mineralow, witamin itp). Dobrze myślę, czy nie bardzo?

0

nie bardzo. Jeśli to jest na studia to pewnie musi to być zgodnie ze sztuką, a takie tabele nie są i nie będą. Wystarczy, że cię wykładowca zapyta "a jak zapisać że produkt X ma 12mg witaminy K i już cały ten schemat w pizdu. Zrozum, że to że masz mieć min 5 tabel to wcale nie oznacza, że masz upchnąć do 5 tabel coś co powinno być w dwóch! Masz mieć 1..n produkt...składnik lub m..n 'produkt'..produkt_składnik..składnik, gdzie produkt_składnik będzie miał trzy pola - produkt_id, składnik_id, ilość. Baza ma być tak zaprojektowana, w szczególności taka na studia, żeby się dało w niej zapisać wszystko to, do czego jest projektowana. Tutaj przy sztywnych nazwach poszczególnych składników, w szczególności bez możliwości dodawania nowych, nie jest to dobrze zrobione

0

Tak dla prostego przykładu niech zostaną te tablice białka, witaminy, węglowodany etc.
Tabela produkt niech wygląda tak: Produkt(id, nazwa, cena).
Zrób teraz tabelę Specyfikacja_produktu(id_specyfikacji, id_produktu, id_witaminy, id_białka, id_węglowodanu, etc.)

Teraz jak chcesz mieć produkt o id 1 zawierający witaminę A w ilości 10 oraz B w ilości 20 to:
Dodajesz kolejno wpisy do tabel:
Produkt (1, 'produkt 1', 10.0)
Witamina (1, 'A', 10)
Witamina (2, 'B', 20)
Specyfikacja_produktu(1, 1, 1, null, null) // produkt + witamina A
Specyfikacja_produktu(2, 1, 2 , null, null)// produkt + witamina B

Dzięki temu możesz zrobić zapytanie do tabeli Specyfikacja_produktu i wyciągać po ID produktu.

To tylko taki przykład, bo oczywiście można to na wiele sposobów rozplanować ale metodologia będzie chyba podobna.
Nie wiem co inni myślą ale przynajmniej mnie tak uczono, że tak się postępuje w takich przypadkach.

0

No okej, ale to teoretycznie może spowodować zamianę tabeli w śmietnik, bo co jeśli dojdzie do momentu, kiedy będzie:
Witamina (1, 'A', 20)
Witamina (2, 'A', 10)
...
Witamina(674, 'A' 40)

Trochę to takie nieładne.
Poza tym, tak jeszcze a propos argumentacji abrakadabera co do tej witaminy K - załóżmy że mój projekt dotyczyłby muzyków i miałbym tabelę:
Muzycy (imie, nazwisko debiut)

No i gdybym chciał tam wpisać informacje odnośnie wieku muzyka, to co wtedy? Takie przypadki można mnożyć.

1

nie rozumiesz tego - wiek to jest coś co posiada KAŻDY, człowiek, pies, kot, nawet drzewo. To są rzeczy OCZYWISTE przy projektowaniu bazy. Tak samo jak projektujesz tabelę z adresem to wiesz, że musisz tam zawrzeć kraj, miasto, ulicę, kod pocztowy. Nikt ci nagle nie wynajdzie nowej "części" adresu. Tak samo, nie będzie osoby, która nie będzie miała np. miasta ale będzie miała kraj i ulicę (darujcie sobie żarty o bezdomnych). Z elementami (nie wiem jak to nazwać) jedzenie jest tak, że po pierwsze nie każdy produkt ma je wszystkie a po drugie nikt nie da gwarancji, że np. za 3 miesiące nie trzeba będzie dopisać nowego. To jest właśnie sedno projektowania dobrej bazy danych - trzeba umieć określić co będzie stałe i niezmienne a co trzeba zaprojektować w taki sposób aby można było dynamicznie dodawać nowe elementy (chociaż ci co mają na co dzień styczność z BD wiedzą, że to nigdy nie jest takie idealne). Sam napisałeś, że to na studia - zrób to "po bożemu" a na pewno zaplusujesz u profesora. BTW wiesz co to są postacie normalne?

0

Ja polecam wersje 1 czyli bez wyszczegolnionych nazw. Dodaj jedynie słownik w któym te wszystkei specjalistyczne nazwe tłuszczów, weglowodanow przechowujesz. W tabeli weglowodany masz id, klucz obcy na slownik z rodzajami weglowodanow i wartosc. wiec uzytkownik wypenia baze dowolnie ale wybor nazw zawezasz mu do okreslonego zbioru. Gdy dojdzie nowy typ weglowodanu to nie musisz przebudowywac bazy tylko dodajesz pozycje do slownika

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