Spojovat frontendové objekty do grafu nebo ponechat stromovou strukturu?

Zdravím,

narazil jsem teď na takový princiápní problém. Mám frontend a tuto doménu:

Kód: [Vybrat]
Food(id, name, calories)
Entry(id, food_id, amount, day_id)
Day(id, date)

Day 1-N Entry, mapped by Entry
Entry 1-1 Food, mapped by Entry

Na backendu mám toto API:

Kód: [Vybrat]
GET /days
GET /foods

Momentálně mám relační DB, data jsou grafová. Ale když je načtu do frontendu přes Rest, a uložím je do modelu (globalni store), tak data přítomná v modelu už nejsou grafová, ale stromová.

Tedy např. když uživatel upraví na page Jídlo entitu Food, tak tato změna se neprojeví do objektu Day->Entry->Food, protože nemám propojeny objekty v listu Food s objekty v Day->Entry->Food.

No a tak přemýšlím. Říkám si:

1. Buďto ty objekty v modelu propojím, ale přidělám si tím práci - na backendu to za me samo propojuje Hibernate, na frontendu ale nic takového není.
2. Nebo to nepropojím, ale pak si říkám, jestli má smysl použití Relační databáze. Protože to je sice hezké, že na backendu mi to udržuje grafovou strukturu mezi objekty, ale k čemu mi to je, když na frontendu se grafová struktur stejně ztratí a změní se na stromovou.

Na jednu stranu, backend mi teď zařídí, že když se změní Food na frontendu, tak sice změna se přirozeně neprojeví do Entry->Food, ale projeví se alespoň po refreshi stránky. Na stranu drouhou použití stromové struktury i na backendu mi umožní přidat zajímavou funkci pro uživatele, jestli si po modifikaci Food přeje tuto změnu promítnout to již existujících Entry.

Prostě, svrbí mě prst zahodit relační DB a dám tam NoSQL.


Já jsem hloupej a nechápu to, můžeš to ještě trochu rozvést? Když říkáš "grafová struktura" a "stromová struktura", co tím myslíš? Strom je speciální podtyp grafu...
Z popisu mi spíš přijde, že řešíš to, že na frontendu máš ve "stromové struktuře" víc instancí Food se stejnýma hodnotama, takže když změníš jednu, tak se nezmění ostatní. To je ale vlastnost toho, jak máš napsanej frontend, to s backendem nijak nesouvisí?

Hlavně asi jde o to, jak chceš, aby se ti to chovalo, a to ti nejspíš nikdo cizí neporadí. Čekal bych, že u něčeho budeš chtít, aby se změna projevila všude (u záznamu snědenýho jídla by změna jeho kalorií asi už neměla změnit snědený kalorický příjem), a u něčeho zase ne (když to jídlo přejmenuje, tak to asi bude chtít vidět všude - anebo taky ne :-) )

alex6bbc

  • *****
  • 1 630
    • Zobrazit profil
    • E-mail
no ja jsem backendak a vsecko zpracovani dat a generovani dat pro frontend bych delal
na backendu, takze na backendu muzu mit cokoliv a do frontendu uz posilam hotova data na zobrazeni.

L..

  • ****
  • 310
    • Zobrazit profil
    • E-mail
Best practice je ukládat taková data normalizovaně. Tady je o tom článek v kontextu Reduxu, ale v principu to platí i pro jakékoli jiné uložení: https://redux.js.org/usage/structuring-reducers/normalizing-state-shape

Best practice je ukládat taková data normalizovaně. Tady je o tom článek v kontextu Reduxu, ale v principu to platí i pro jakékoli jiné uložení: https://redux.js.org/usage/structuring-reducers/normalizing-state-shape

No tvl to je zase dalsi level komplikovanosti. V podstate s takovym modelem to znamena, ze nepotrebuju ani sqlalchemy. Fakt zajimave. Ja v podstate 1:1 muzu ozrcadlit data z relacni databaze do frontendu. Ale dava to smysl no.