Denormalizacia dat, vyhnutie sa zlozitym SQL rubrika: Programování: Ruby

2 mamatoto
položil/-a 12.10.2015

Ahojte,

momentalne riesim zlozitejsi problem, mam nieco ako inzertny server, kde zorbazujem inzeraty, tie sa vsak ziskavaju relativne zlozitymi dotazmi s vela joinami atd... - inzerat totiz pozostava z 1 .. n poloziek, dalej z entit, ktora urcuje jeho typ a platnost, dajel to pozera na fakturu a jej stav su tam napojene dalsie atributy a dokopy sa jedna asi o 7 - 9 tabuliek (zalezi aj na type inzeratu...), pri zlozitejsich filtorch a sortoch sa to uz zacina celkom komplikovat a mam nutkanie to nekym posobom davat do inej tabulky, denormalizovane, kde sa to len nacita a bude v nej vsetko potrebne.
Mate s tym nejake skusenosti? Co pouzit a ako sa k tomu postavit? Spravit view v db? Alebo nova tabulka? Alebo nerelacna db? Pouzit elasticsearch?

Diky

odkaz
12 pavel.stehule
odpověděl/-a 12.10.2015
 
upravil/-a 12.10.2015

Denormalizace je past. Co se ušetří na dotazu, to se ztratí na výrazně složitějším INSERTu, UPDATEu (a nakonec i SELECTu). Logickou denormalizací je používání pohledů - určitě doporučuji používat pohledy. Jsou to v jistém slova smyslu MAKRA, co dokážou ušetřit práci a ve většině případů mají nulovou režii. Materializované pohledy mají smysl jen při větším objemu nebo když nesedí odhady a optimizer se ztrácí. Občas může být za nečitelnými nebo překomplikovanými dotazy špatný návrh - špatná úroveň abstrakce, špatný návrh entit - nevhodná architektura. To 100% denormalizace nevyřeší.

Vyjímkou jsou analytické databáze OLAP - star schema, snow flake schéma - tam se denormalizuje maximálně - pracuje se s několika málo faktovými tabulkami - ale jedná se o úplně jiný model, do kterého se většinou přelévají data vygenerovaná z klasické normalizované OLTP databáze.

Komentáře

  • Augi : U inzertního serveru bych očekával, že manipulací s daty bude zanedbatelné množství (oproti čtení dat), proto bych to viděl jako ideální use-case pro denormalizaci. 13.10.2015
  • pavel.stehule : @Augi: denormalizací se ale tak znepřehlední databáze, že je pak neskutečný opruz s takovou databází pracovat. Pokud neumím nebo nejsem schopný navrhnout schéma se kterým by se dobře pracovalo, tak už je pak jednodušší použít NoSQL databázi. Dost záleží na návrhu, jak vyšší NF (nad 5NF), tak pokus o OOP v db mohou vést k nepřehlednému schématu, se kterým se pak hrozně špatně dělá. To už je opravdu lepší použít NoSQL. 13.10.2015
  • Taco : @Augi: No, tak ale je spousty dalších věcí, které může zvážit před tím, než půjde do denormalizace, ne? 13.10.2015
  • Augi : @Taco: Však kdo říká, že nemůže? :-) Dokonce to navrhuju ve vlastní odpovědi :-) 13.10.2015

Pro zobrazení všech 5 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.