Tworzenie trzeciej tabeli - opłacalność

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ć?

1

Ogólnie można użyć po prostu @ManyToMany (https://vladmihalcea.com/the-best-way-to-use-the-manytomany-annotation-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

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

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