Tworzenie trzeciej tabeli - opłacalność

Odpowiedz Nowy wątek
2019-03-28 10:53
0

Cześć. Tworze coś na miarę aplikacji treningowej i jestem na etapie wyliczania węgli,białka,tłuszczy z przesłanego w JSONIE produktu.
Metody, które wyliczają konkretną ilość są już zrobione.
Ogólny zamysł jaki miałem, to żeby móc wyświetlić także w postaci JSONA (nie robie żadnego frontu) ilość właśnie wszystkich węgli, tłuszczy etc. spożytych w danym dniu - coś na miarę historii.
Czyli zwraca mi JSONA z ID użytkownika czy tam nickiem i wypisane po kolei 28-03-2019: 20w,20b,20t i teraz nie wiem jak to rozegrać logicznie, aby połączyć konto i produkty, które były wysyłane w postaci:

{
name: "Apple",
gram:50,
id: 2
}

Czy powinienem stworzyć kolejną encję np. UsersProduct, w której znajdowały by się relacje jeden do wielu dla konta i produktów, czyli:

public class UsersProduct{

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private int id;
    @OneToMany
    Product product;
    @ManyToOne
    User user;

z tym, że teraz każdy produkt dodany to by była nowa krotka.
Czy jest to dobry pomysł czy w jaki inny można to rozegrać?

edytowany 1x, ostatnio: must, 2019-03-28 10:54

Pozostało 580 znaków

2019-03-28 11:10

Ogólnie można użyć po prostu @ManyToMany (https://vladmihalcea.com/the-[...]ation-with-jpa-and-hibernate/)
Ale kierunek, w którym idziesz jest moim zdaniem lepszy - posiadając klasę UserProduct jawnie mówisz o tym, że istnieje taki biznesowy byt, a to że zapisujesz to w relacyjnej bazie za pomocą relacji many to many to tylko szczegół implementacyjny. Poza tym posiadając taką klasę, możesz w łatwy sposób dodać nową właściwość - np. datę i czas kiedy użytkownik nabył produkt

Czyli mówisz, że jest to dobry sposób, a sama nazwa? Bo nie wiem szczerze powiedziawszy czy jest ona dobra. - must 2019-03-28 11:17
Jezeli chodzi o nazwę klasy to ja bym użył formy pojedynczej - UserProduct - reprezentuje połączenie jednego usera z jednym produktem. Można do tego podejść też bardziej domenowo - czym to połączenie użytkownika i produktu u Ciebie jest w sensie logicznym? Tak jak np. użytkownik i lista artykułów to może być jego koszyk w sklepie internetowym jak i również zamówienie, dane te same, a kontekst inny - pustypawel 2019-03-28 11:21
Słowo relacyjna w określeniu relacyjna baza danych nie odnosi się do kluczy obcych, a schematu bazy (https://pl.wikipedia.org/wiki/Model_relacyjny). MySQL jest bazą relacyjną, ponieważ każda tabela ma z góry znany, określony schemat - MongoDB jest bazą nierelacyjną, ponieważ przyjmie (plus minus) każdy dokument. - Patryk27 2019-03-28 11:33

Pozostało 580 znaków

2019-03-28 14:24
1

UserProduct nie jest pustą klasą techniczną. Tu powinny być odwzorowane parametry czasowe posiłku (data, może godzina).

Wtedy nazwa się zmienia na adekwatną.

dodam LocalDateTime przez co każda krotka będzie miała datę, później dodam metodę która będzie filtrowała wszystkie krotki zwracając dla danego ID ilość spożytych wegli,bialka etc. Mysle, ze taki sposob jest najleposzy. - must 2019-03-28 14:26

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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