Ako navrhnut univerzalnu DB pre dynamicke polozky? rubrika: Programování: .Net

13 xxar3s
položil/-a 3.9. 12:29

Ide napriklad o produkty v eshope. Trebars taka alza ma monitory u nich ma zaujima rozlisenie, typ (IPS, PLS atd) velkost ale nezaujima ma trvanlivost.

U zemiakov bananov ma zaujima zase hmotnost, trvanlivost atd.

Zvykol som to robievat tak ze som pri kazdom eshope navrhol extra strukturu tabulky podla produktov ktore budu v tom eshope predavane. Ale to neni moc flexibilne riesenie okrem toho ked budem chcet predavat nieco ine tak budem musiet rozsirit tabulky a nepotrebne stlpce nevyuzijem. A pri systeme ktory by spravoval viacero roznych eshopov by to bolo mrhanie kapacitou. Dalsia moznost je urobit extra tabulku props a extra tabulku prop values a v nej bude id produktu nazov idpropsu a jeho hodnota. Ale s tym sa zase nerobi az tak elegantne. A pri zlozitejsich operaciach bude treba robit X joijnov atd.

Teraz rozmyslam ze by som to navrhol tak ze budem pouzivat dve databazy jednu RDBMS a jednu NoSQL (dokumentovu alebo OODBMS). Do tabulky Products budem ukladat zakladne veci ako id nazov ean cena popis pocet kusov ci je skladom (proste vsetko co ma zaujima u vsetkych produktov) ale doplnim tam stlpec typ produktu.

A podla typu produktu budem do NoSQL databazy ukladat specialne extra objekty kazdy ojekt bude mat ID a ten bude rovnaky ako id produktu v relacnej databaze. Kazdy typ produktu bude mat objekt inej triedy.

Je to dobry navrh podla vas? Podla mna by to mohlo byt super. Ktora NoSQL databaza by bola na nieco take najvhodnejsia?

odkaz
13 pavel.stehule
odpověděl/-a 3.9. 15:46

Podle mne moderní SQL databáze umožňují pracovat s JSON, XML typy, takže byste si mohl vystačit s SQL RDBMS.

Budu psát o Postgresu, ale podobně můžete fungovat s MySQL. V PostgreSQL můžete docela dobře napsat hybridní řešení - ty důležité fixní sloupce budou uložené relačně (ve sloupcích) - každý produkt má 3 dimenze, hmotnost, různá id, a ostatní data můžete uložit do JSONu, XML, HStore - a v nich pak fulltextově vyhledávat. Případne v projekci převádět na sloupce. Limit na JSON, JSONb je 1GB .. desítky kb až MB na jednu hodnotu nejsou problém.

NoSQL databáze bych použil, tam kde potřebuji horizontálně škálovat, a preferuji CAP před ACID. Ale na to abych uložil JSON určitě nepotřebuji NoSQL databázi. S dvěma různými systémy už musíte řešit synchronizace. NoSQL db typicky nepodporují 2PC commit, takže nemůžete rozjet globální transakce a bez nich je každý synchronizace vachrlatá.

Komentáře

  • podhy : navíc se pak dost komplikují u dvou systému zálohy a hlavně případné obnovy 3.9. 16:22
  • siq : Suhlasim. A rozhodne odporucam PostgreSQL na storovanie JSONu oproti inym databazam. PG ma JSON podporu ovela dlhsie nez MySQL a podporuje napriklad aj JSONB format, ktory je priamo indexovatelny. Rozhodne neodporucam MongoDB, alebo ine NoSQL. Postavili sme nad tym startup a teraz to pekne cele prepisujeme do Postgre. 5.9. 12:19
  • podhy : Jinak pokud někdo v postgresu pracuje s JSON trochu intenzivněji a nestačili základní nástrajo tak se dá ještě použít: https://github.com/postgrespro/jsquery 5.9. 14:55
  • mkoula : My jsme něco podobného měli i na ecommerce rešení, kdy frontend měl cache v Elasticsearchi a backend pracoval v Postgresu a jelikož náš produkt měl několikset parametrů, tak se zvolily ty fixní jako čistě relační a zbytek byl ve sloupci attributes v jsonu. Na práci s jsonem v Postgresu je třeba si trošku zvyknout, ale kdo udělal krok od MySQL a používal třeba i pole, tak to je někde na půli cesty a základní hledání je i stejné :-) MySQL js JSONem začíná a pořád přijde mi, že je stále pro práci s ním trochu omezená... 7.9. 15:45

Pro zobrazení všech 8 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.