Návrh relační databáze

Re:Návrh relační databáze
« Odpověď #15 kdy: 25. 04. 2019, 20:20:01 »

Pokud to dobře chápu, máte tam Entity–attribute–value model (EAV)? Pokud ano, bylo by dobré zmínit, že to ledaskdo považuje za antipattern. Což samozřejmě neznamená, že to nemůže fungovat, otázkou je pracnost a vlastnosti.

Přiznám se, že teoretické antipatterny neřeším, zajímají mě praktické požadavky. Snadná rozšiřitelnost do všech stran, podpora spolehlivého dlouhodobého vývoje (žádná reflexe apod, vše typově hlídané) a v neposlední řadě rozumný výkon. Ale ten lze dnes nahonit HW, který je velice levný. Repas server DL580 s 512GB DDR3 12800, 40 jádry a spoustou PCI-e v.3 slotů pro NVMe disky jsme nedávno kupovali za 30k Kč s dopravou. Tichá pracovní stanice Precision T7600 2x octa e-5 xeon 128GB RAM + spoustu PCI-e v.3 vyjde na 21k Kč, s 256GB RAM něco přes 30k. Kolik je to proti měsíčním nákladům na jednoho vývojáře...

Narozdíl od nákladů na vývoj, které jen porostou. Požadavky na změny a nové funkce chodí od byznysu každý den, zatímco ruční zásah do struktury DB jsme nedělali už hodně let. Tabulky atributů si samozřejmě vyrábí ORM samo.

To ale není moc dobrá reklama - když něco člověk dělá, měl by vědět jak tomu ostatní říkají, ostatně potřebuje komunikovat s ostatními vývojáři apod. Zasazení vlastní praxe do odborného kontextu by byl bod pro vás (ostatně ona to není ani nějaká akademická terorie).

Každopádně mě zajímalo jen to, zda to odpovídá tomu EAV patternu (odkaz jsem připojil).


Re:Návrh relační databáze
« Odpověď #16 kdy: 25. 04. 2019, 21:16:17 »
Deset minut smolím odpověď a mezitím mě zdejší geniální systém odhlásí a odpověď zahodí.

Je to normální selský rozum, jak pokud možno trochu efektivně uložit objekty s atributy a vazbami. Název mě až tak nepálí, s kolegy si to umím vysvětlit i bez teoretických pouček od akademiků.

* tabulka objektů - klíč obj_id. Objekty jsou různých typů - class_id

* tabulka druhů/názvů atributů - klíč attrib_id

* každý typ atributu má vlastní tabulku attrib_XXX, kde XXX je jeho attrib_id. Řádky jsou hodnoty pro objekty, tedy cizí klíč obj_id na objekt. Sloupec value je textový, číslo, datum, json atd., dle konkrétního typu atributu . Atributů/tabulek jsme zatím nadefinovali cca tisíc.

* tabulka vazeb s obj_from_id, obj_to_id a opět class_id - třída vazby. Vazby mají privátní číselnou položku, která určuje např. pořadí podtémat ve výpisu jedné úrovně stromu, snadno se podle toho stromy zpracovávají.

* další tabulky pro práva, fulltext nad stringovými atributy atd.

Samozřejmě to vyžaduje ORM vrstvu v javě, přes kterou se dělají všechny změny. Ta kešuje načtené objekty, atributy, vazby. Klidně úplně všechny, od toho paměť je. Změna nejdříve transakčně zapisuje do DB, když se podaří, změní i nakešovaná data, takže to samozřejmě drží synchronizované.

Jak říkám, je to selský rozum. Ale docela se to osvědčilo a zatím moc změn nevidím potřeba. Chybí atributy u vazeb, to bude potřeba pořešit. A samozřejmě to chce nativní fulltext, klasický problém spousty projektů.

Re:Návrh relační databáze
« Odpověď #17 kdy: 25. 04. 2019, 22:23:36 »
Deset minut smolím odpověď a mezitím mě zdejší geniální systém odhlásí a odpověď zahodí.

Je to normální selský rozum, jak pokud možno trochu efektivně uložit objekty s atributy a vazbami. Název mě až tak nepálí, s kolegy si to umím vysvětlit i bez teoretických pouček od akademiků.

(...)

No bez těch akademiků byste neměl ani SQL ani SQL databázi, takže byste se pak neměl o čem s kolegy bavit.

Ale jinak děkuji za popis. Bylo by určitě zajímavé, jak dlouho a v kolika lidech jste to řešení vyvíjeli, aby to bylo možné porovnat s alternativami.

Re:Návrh relační databáze
« Odpověď #18 kdy: 25. 04. 2019, 23:04:21 »
Umím ocenit teorii, když má opravdu hodnotu. Třeba o jejím významu pro SQL ani o DB nijak nepochybuji. Nicméně dle mého názoru je celá řada návrhových vzorů úplně normální řešení, které každý slušnější vývojář použije, protože mu přijde správné a samozřejmé a vůbec nemusí ani tušit, že to má nějaký odborný název. Taková teorie jde mimo mě. Zrovna tenhle princip EAV je jedno z těch úplně normálních řešení.

V roce 2003 moc hotových ORM v javě nebylo, obzvláště ne s výkonově optimalizovanou podporou ACL pro read/write/delete/link/grant na úrovni jednotlivých objektů a z nich poskládaných stromových struktur. Defakto adresářová struktura s ACL, původně to sloužilo jako DMS pro přímé propojení se sambou - přístup přes file manager i přes prohlížeč. Dneska už práva na objektech tolik neřešíme, je to spíš na byznys vrstvě, ale občas jsou potřeba.

Design/vývoj javovského ORM 1 hodně šikovný člověk cca půl roku, způsob uložení dat do DB jsme měli již ověřený z dřívějšího projektu ještě v PHP (od r. 2000).

Dneska bych se podíval po něčem hotovém, ale osobně bych opět volil nějaké efektivní mapování ORM do klasického SQL, s pořádnou podporou kešování. Líbí se mi grafové databáze, ale ty principy se pomalu dostávají do SQL, což je IMO správná a užitečná cesta.

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:Návrh relační databáze
« Odpověď #19 kdy: 25. 04. 2019, 23:22:17 »
Filip, Kit:
Grafové a jiné nosql databáze jsou sice dobré, ale do té doby, než s nima chce člověk pracovat v součinnosti s věcma, které má v SQL databázi. Např. proto se prosazují "in-databaze" fulltexty, protože fulltext mimo databázi může být nakrásně rychlejší, lepší a nevím co, ale když chceš kromě fulltextu filtrovat ještě podle dalších X kritérií, tak je to na palici. Navíc rozdělení dat do dvou databází musíš řešit takové lahůdky, jako synchronizace transakcí atd. atd....
A protože se na většinu věcí SQL hodí hodně dobře, zpravidla je lepší cesta používat nosql rozšíření SQL databází - např. ten json sloupec - než data dělit do dvou různých databází, anebo se zcela zbavovat možností SQL (a ukládat vše do noSQL databáze).

Pokud někdo chce prznit relační databázi nějakým EAV a ORM, tak mu rovnou doporučím NoSQL, kde tyhle dva nesmysly nebude potřebovat. Takový vývojář si relační databázi ani nezaslouží.


SB

  • ****
  • 347
    • Zobrazit profil
    • E-mail
Re:Návrh relační databáze
« Odpověď #20 kdy: 26. 04. 2019, 14:27:49 »
Pokud někdo chce prznit relační databázi nějakým EAV a ORM, tak mu rovnou doporučím NoSQL, kde tyhle dva nesmysly nebude potřebovat. Takový vývojář si relační databázi ani nezaslouží.

Já bych se zeptal jinak: Jak je možné, že u tolika projektů je problémem č. 1, jak dostat data do a z relační databáze. To nedává smysl - buďto je formát dat projektu vhodný na RDB, nebo se na ni vy*eru a použiju něco, kde nebudu potřebovat rovnáky na ohýbáky.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Návrh relační databáze
« Odpověď #21 kdy: 26. 04. 2019, 15:17:58 »
Já bych se zeptal jinak: Jak je možné, že u tolika projektů je problémem č. 1, jak dostat data do a z relační databáze. To nedává smysl - buďto je formát dat projektu vhodný na RDB, nebo se na ni vy*eru a použiju něco, kde nebudu potřebovat rovnáky na ohýbáky.

Protože relační databáze jsou dlouhodobě nejvymazlenější nástroj co se manipulace s daty týče. Samozřejmě bychom mohli prohlásit, že tak ať se lidé seznamují s novinkami, a ono by se nakonec něco vytvořilo, jenže znáš to.

Re:Návrh relační databáze
« Odpověď #22 kdy: 26. 04. 2019, 19:58:52 »
Pokud někdo chce prznit relační databázi nějakým EAV a ORM, tak mu rovnou doporučím NoSQL, kde tyhle dva nesmysly nebude potřebovat. Takový vývojář si relační databázi ani nezaslouží.

Já bych se zeptal jinak: Jak je možné, že u tolika projektů je problémem č. 1, jak dostat data do a z relační databáze. To nedává smysl - buďto je formát dat projektu vhodný na RDB, nebo se na ni vy*eru a použiju něco, kde nebudu potřebovat rovnáky na ohýbáky.

O jakych projektech mluvis?...

Re:Návrh relační databáze
« Odpověď #23 kdy: 26. 04. 2019, 20:21:07 »
Jinak k navrhu reseni mam par poznamek, ktere by mozna pomohly:
1. Prestat veci mazat, spis se na data koukat jako na bankovni transakce, tj. time series data, a podle toho navrhout model. Neco jako star kvazi-star schema s identifikatory(klici) v centralni tabulce, kde by bylo take jejich linkovani. Slo by implementovat na nejakem key/value storu (Redis, nebo Hbase)
2. Specificke typy budou mit kazdy svou tabulku, pokud jich mate hodne tech typu, tak bych to radsi rval nekam zase do nejakyho K/V storu.
3. Oddelit ingestion(write) a query(read) modely. Prvni je vice normalizovany, druhy muze byt denormalizovany pro fast query. Nelze dosahnout obojiho v jednom modelu. Nevim detaily architektury, ale doporucoval bych se kouknout na patterny jako CQRS, SAGA, resp. Event Sourcing, napr. pomoci Confluent, Axon nebo Eventuate na Springu(by famous Richardson)

Q; mate nejake ETL/integracni pumpy, nebo jak se tam ty data dostavaj, to si vubec nepopsal?
Q: Jaky je volume (GB,TB,PB..) a pocet zaznamu napr. za 1 rok?

Re:Návrh relační databáze
« Odpověď #24 kdy: 27. 04. 2019, 12:38:52 »
Dobry den,

pridam moji odpoved, ktera sice nebude primo pro Vas(nepouziva SQL), ale nekomu se muze v budoucnu hodit.
Zkusil bych se podivat na tripplestore, RDF, a veci kolem semantickeho webu : https://en.wikipedia.org/wiki/Triplestore

Pomoci jazyka OWL jde definova neco jako "schema", nazyva se to Ontology, kde si pro kazdy objek vytvorite "tridu". Techto trid muzete mit tisice. Daji se taky ulozit do databaze. Nasledne do databaze ulozite "instance" trid, ktere mohou odkazovat jedna na druhou, delat stromove struktury, pouzivat vicenasobnou dedicnost. Navic databaze vas nijak neomezuje co kde smite ukladat. Act se to myslim da zapnout.

V programu nasledne muzete generovat rozhrani na zaklade "tridy" a jejich datovych typu. Jazyk OWL je mocny, nekdy az moc, ale zase se v nem daji definovat pravidla ktere vylucuji napriklad aby jedna "instance" nemohla byt jak auto, tak letadlo. Nasledne muzete pomoci jazyka SPARQL generovat dotazy do databaze. Jako dej mi vsechny instance tridy Auto vcetne jejich potomku (Nakladak, tahac, sportak).

https://jena.apache.org/documentation/ontology/
https://jena.apache.org/documentation/fuseki2/index.html
https://en.wikipedia.org/wiki/SPARQL

Radek

Re:Návrh relační databáze
« Odpověď #25 kdy: 27. 04. 2019, 13:25:52 »
OWL - zajímavé, díky.

Tohle stále ještě platí (citace z wiki)?

Limitations
No direct language support for n-ary relationships. For example, modelers may wish to describe the qualities of a relation, to relate more than 2 individuals or to relate an individual to a list. This cannot be done within OWL. They may need to adopt a pattern instead which encodes the meaning outside the formal semantics.