Struktura databáze?

17. 9. 2012 21:08:38

Ahoj,

řeším dilema, jakou strukturu databáze zvolit.

Data jsou takového rázu, že se každý rok před sezónou nějaké nasypou a v průběhu roku se mění. A tak každý rok dokola. Plus jsou v databázi nějaké data, která se mění jenom zřídka nebo s tímto koloběhem vůbec nesouvisí.

Nejjednodušší řešení na implementaci by asi bylo pro každý rok vytvořit samostatnou databázi a víc to neřešit. Jenomže bych nad těmi daty zpětně chtěl dělat statistiky a asi by se mi to docela vymstilo.

Podobně ohavné řešení by bylo prefixovat názvy tabulek.

Jako nejlepší řešení se mi zdá: vytvořit tabulku sezón a v každé tabulce vytvořit sloupec id_sezóny.

Nebo by to šlo udělat ještě nějak líp?

17. 9. 2012 21:08:38

https://webtrh.cz/diskuse/struktura-databaze#reply808956

Ing. Josef Vrba

(7 hodnocení)

17. 9. 2012 21:23:15

určitě řešit formou sloupce sezona_id, který bude odkazovat do tabulky sezona.

Nová DB, nové tabulky nebrat pokud se s daty bude kdykoliv v budoucnu znovu pracovat.

Jinak aby tabulky nebyly tak velké, tak je možné pak vytvořit pohled pro aktuální sezónu a tím odlehčit serveru a zlehčit práci i sobě ;)

17. 9. 2012 21:23:15

https://webtrh.cz/diskuse/struktura-databaze#reply808955

init.22

(7 hodnocení)

17. 9. 2012 21:59:19

pokud tech dat je hodne, tak muzes vyuzit principu datovyho skladu .. po celou aktualni sezonu pojedes na OLTP databazi, tj. s nejakou vyssi mirou normalizace (co nejmin duplicitnich dat a co nejvic tabulek :)) idealne bez indexace a kazdej rok to "nalejt" do databaze s jinou strukturou - vhodnejsi pro analyticky dotazy (min tabulek), klidne s duplicitnima hodnotama v urcitych sloupcich, s indexama a pohledama .. protoze pokud jich bude skutecne hodne, tak indexace na OLTP bude databazi brzdit .. btw. zpetne pohledy moc serveru neulehci praci

17. 9. 2012 21:59:19

https://webtrh.cz/diskuse/struktura-databaze#reply808954

okolodokola

17. 9. 2012 23:18:05

Napsal init.22;845427
pokud tech dat je hodne, tak muzes vyuzit principu datovyho skladu .. po celou aktualni sezonu pojedes na OLTP databazi, tj. s nejakou vyssi mirou normalizace (co nejmin duplicitnich dat a co nejvic tabulek :)) idealne bez indexace a kazdej rok to "nalejt" do databaze s jinou strukturou - vhodnejsi pro analyticky dotazy (min tabulek), klidne s duplicitnima hodnotama v urcitych sloupcich, s indexama a pohledama .. protoze pokud jich bude skutecne hodne, tak indexace na OLTP bude databazi brzdit .. btw. zpetne pohledy moc serveru neulehci praci

Co znamená "skutečně hodně"? A jak moc to bude db brzdit?

17. 9. 2012 23:18:05

https://webtrh.cz/diskuse/struktura-databaze#reply808953

Ondřej Švec

18. 9. 2012 08:35:50

Napsal jvic;845414
Jinak aby tabulky nebyly tak velké, tak je možné pak vytvořit pohled pro aktuální sezónu a tím odlehčit serveru a zlehčit práci i sobě ;)

Úplně jsem zapomněl, že něco takového existuje. Četl jsem teď pár článků a vypadá to slibně. Nějaké rady, čemu se vyhnout? Abych to nepřehnal.

Napsal init.22;845427
pokud tech dat je hodne, tak muzes vyuzit principu datovyho skladu .. po celou aktualni sezonu pojedes na OLTP databazi, tj. s nejakou vyssi mirou normalizace (co nejmin duplicitnich dat a co nejvic tabulek :)) idealne bez indexace a kazdej rok to "nalejt" do databaze s jinou strukturou - vhodnejsi pro analyticky dotazy (min tabulek), klidne s duplicitnima hodnotama v urcitych sloupcich, s indexama a pohledama .. protoze pokud jich bude skutecne hodne, tak indexace na OLTP bude databazi brzdit .. btw. zpetne pohledy moc serveru neulehci praci

Můžeš trochu rozvést, jak se ta OLTP databáze vytváří? Našel jsem jenom nějaké velmi obecné informace a zatím si neumím představit, jak taková databáze vypadá.

18. 9. 2012 08:35:50

https://webtrh.cz/diskuse/struktura-databaze#reply808952

Jiří Adámek

(20 hodnocení)

18. 9. 2012 08:51:54

Databaze se v zasade daji rozdelit na dve casti. Bezne databaze (OLTP) jsou ty, ktere se kazdodenne pouzivaji. Maji vysoce normalizovanou formu (udaje se neopakuji). Diky teto normalizaci je sice jejich efektivita vysoka a poskytuji velice podrobne udaje, nicmene jakekoliv statisticke veci se musi primo na serveru dopocitavat, protoze v db primo ulozene nejsou. (Napr kolik se prodalo televizi samsung za poslednich 24 mesicu). Pri mensich velikostech, radove jednotky az desitky GB (ale generalizovat to nelze, zalezi na konkretni aplikaci) se daji pouzit i pro statisticke ucely, protoze server tyto udaje proste dopocita.

Jakmile velikost vsak prekroci urcitou mez, coz se velice casto stava pri castych a pomerne slozitych statistickych dotazech (napr. Kolik se prodalo televizi samsung typu XY a zaroven bylo reklamovano v obdobi A az B), pak jsou bezne db neefektivni a pouzivaji se tzv. OLAP databaze. To jsou z technickeho hlediska take bezne db, ale zasadni rozdil je ten, ze udaje jsou mnohdy agregovane a vetsinou ulozene v nenormalizovane forme (to z toho duvodu, aby se nemusel provadet JOIN nad tabulkama a nezatezoval se tak zbytecne server a vysledky ziskaval uzivatel/analytik rychleji).

Hezky je to v tabulce srovnano zde: http://datamining.xf.cz/view.php?cisloclanku=2002102808

18. 9. 2012 08:51:54

https://webtrh.cz/diskuse/struktura-databaze#reply808951

init.22

(7 hodnocení)

18. 9. 2012 20:14:27

Napsal mytrix;845508
Databaze se v zasade daji rozdelit na dve casti. Bezne databaze (OLTP) jsou ty, ktere se kazdodenne pouzivaji. Maji vysoce normalizovanou formu (udaje se neopakuji). Diky teto normalizaci je sice jejich efektivita vysoka a poskytuji velice podrobne udaje, nicmene jakekoliv statisticke veci se musi primo na serveru dopocitavat, protoze v db primo ulozene nejsou. (Napr kolik se prodalo televizi samsung za poslednich 24 mesicu). Pri mensich velikostech, radove jednotky az desitky GB (ale generalizovat to nelze, zalezi na konkretni aplikaci) se daji pouzit i pro statisticke ucely, protoze server tyto udaje proste dopocita.
Jakmile velikost vsak prekroci urcitou mez, coz se velice casto stava pri castych a pomerne slozitych statistickych dotazech (napr. Kolik se prodalo televizi samsung typu XY a zaroven bylo reklamovano v obdobi A az B), pak jsou bezne db neefektivni a pouzivaji se tzv. OLAP databaze. To jsou z technickeho hlediska take bezne db, ale zasadni rozdil je ten, ze udaje jsou mnohdy agregovane a vetsinou ulozene v nenormalizovane forme (to z toho duvodu, aby se nemusel provadet JOIN nad tabulkama a nezatezoval se tak zbytecne server a vysledky ziskaval uzivatel/analytik rychleji).
Hezky je to v tabulce srovnano zde: http://datamining.xf.cz/view.php?cisloclanku=2002102808

pěkně napsáno .. jen bych doplnil, že pokud to nemá být nějaké enterprise řešení, tak v podstatě může jeden databázový systém posloužit jak pro OLAP, tak OLTP - akorát bude záležet na té struktuře tabulek a použití dalších pomůcek (indexy, pohledy atp.) .. výkonové rozdíly jsou znát už při tisícovkách záznamů (řádově v sekundách, ale pokud se dělají výpočty často, tak to je moc) .. vhodnou strukturou lze dotaz, který na struktuře typu OLTP běží 10 sekund, spočítat na OLAP za 100-200ms (taky jen orientačně)

18. 9. 2012 20:14:27

https://webtrh.cz/diskuse/struktura-databaze#reply808950

Ondřej Švec

18. 9. 2012 21:50:27

Takže jestli jsem to správně pochopil, tak pro rychlý přístup se používá malá OTLP, která je normalizovaná, bez duplicit a nemá indexy. (Proč nemá indexy? V řádu tisících záznamů se ještě indexy nevyplatí vytvářet?)

Potom, když už teda skončí sezóna, tak se data z OTLP databáze přemapují a vloží do databáze OLAP, což funguje jako archiv a struktura je přízpůsobená statistickým dotazům.

Začínají mě ty databáze lákat víc a víc. Vůbec si nedokážu představit, jak bych měl tu OLAP databázi navrhnout, když ještě nevím, jaké dotazy nad ní budu provádět. Naopak si troufám říct, že normalizovanou databázi není složité vymyslet.

18. 9. 2012 21:50:27

https://webtrh.cz/diskuse/struktura-databaze#reply808949

init.22

(7 hodnocení)

18. 9. 2012 22:12:19

s těmi indexy jsem to možná trochu přehnal - vyplatí se samozřejmě vytvářet i u OLTP databází, jen je s nimi potřeba šetřit, protože je potřeba uvážit, že se v případě přidání dat do tabulky nebo jejich změny musí indexy celé tabulky přepočítat, což trochu brzdí tu akci - ale není to tak znát. indexy bych použil pouze na místa, která se z databáze volají nejčastěji, např. si chci vytáhnout všechny články, které mají dnešní datum a to zobrazit na úvodní stránce (takže to bude nejčastější dotaz celé aplikace):

SELECT xxx FROM clanky WHERE datum = '1.1.2012' .. protože datum zde nebude součástí primárního klíče (tj. jednoznačného identifikátoru záznamu v rámci tabulky) a není tím pádem automaticky index (primární klíč je typu clustered index), tak by se hodilo vytvořit non-clustered index nad sloupcem datum .. tím databázový engine nebude skenovat všechny hodnoty v tabulce (resp. nepojede řádek po řádku a nebude hledat shodu s tím datem), ale předpřipraví si při změně obsahu tabulky určitý rozhodovací strom, pomocí kterého dokáže najít výskyty nepoměrně rychleji

kdežto v OLAP databázích se běžně vyskytují násobné indexy na několika sloupcích s překrýváním - zde se totiž nic už nepřepočítává a nějaká kapacita navíc potřebná k uchování předpočítaných výsledků zde nevadí

snad je to pochopitelné :)

18. 9. 2012 22:12:19

https://webtrh.cz/diskuse/struktura-databaze#reply808948

Jiří Adámek

(20 hodnocení)

19. 9. 2012 02:51:16

Napsal ondrej.svec;845888
Začínají mě ty databáze lákat víc a víc. Vůbec si nedokážu představit, jak bych měl tu OLAP databázi navrhnout, když ještě nevím, jaké dotazy nad ní budu provádět. Naopak si troufám říct, že normalizovanou databázi není složité vymyslet.

To je právě to Fň. OLAP db se většinou v segmentu jednotlivců a malých firem/aplikací nepoužívají, je to spíše záležitost větších podniků (nebo datově náročných aplikacích). Tam, kde jsou potřeba, existuje většinou celé specializované oddělení, kde si stanoví, jaká data potřebují mít k dispozici a na základě těchto požadavku je datový sklad vytvořen. Pokud nevíš, jaké data by jsi z něj chtěl získat, pak jej s největší pravděpodobností nepotřebuješ ;)

19. 9. 2012 02:51:16

https://webtrh.cz/diskuse/struktura-databaze#reply808947

Pro odpověď se přihlašte.

Přihlásit