Mají tabulkové databáze v dnešní době smysl?

[Pavel Stěhule]

A proto to spousta vsemoznych patlalu nedela. Moh bych ukazat desitky funci v ruznych aplikacich ktery nastavujou nejaky parametr na zaznamech, a delaji to ... po jednom zaznamu. A kdyz to nekdo stopne, tak to pekne po jednom rollbackuji. Takze to trva a trva a trva. Typicky to pak vypada zhruba tak, ze zamestnanci chodi za administratorem na tema "uz zas potrebuju spustit tuhle pitomost" a admin ma napsany nejaky query, ktery udela totez, jen za desetitisicinu casu.

Jeden priklad za vsechny, karta zbozi ma jako jeden z parametru novou cenu s platnosti od. System ma funkci na prepsani tyhle ceny (pokud uz plati) do aktualni ceny produktu. Ta funce je schopna pri desitkach tisic produktu bezet i nekolik hodin. Nacte si totiz vzdy jeden zaznam, ten aktualizuje a tak porad dokola. Update na vse do databaze dobehne v radu nekolika sekund.

Pláčete hezky, ale na špatném hrobě . To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM. Taková je realita - můžete mít sebelepší technologii, a lidi si to stejně budou dělat po svém. A když se zjistí, že je to špatně, tak už je pozdě něco měnit. Prostě lidi. Ty korporátní aplikace kolikrát ještě mají kořeny v COBOLu (nebo lidi, co je píší).

[Reklama]

[agent]

Toho, kdo pro práci s relační DB používá kurzory místo hromadných operací, protože je zvyklý tak programovat, bych věšel za k...e do průvanu 

[JardaMira]

Vysledne dojmy?  : Uz bych nemenil.

• Zalozeni nove tabulky (tady collection) nevyzaduje zadnou specialni akci
• V pythonu je pymongo: ovladani se neda s mysql srovnavat, vsechno je jako DICT 
•   Pouzivam 100x intenzivneji nez kdysi mysql, takze mam kolem milionu zaznamu, zapisuji kazdych 10 sec. a nevidim latenci 
•   Menim tabulku za behu, proste zacnu pridavat dalsi parametr. 
•   Mam dost ridkou tabulku, vetsina parametru je Nan, navazujici pymongo a pyplot jsou v pohode. 
•   Clovek muze nechat bezet stejne MongoDB na vice strojich najednou, cimz ma duplicitu a pojisteni proti vypadku (ale nezkousel jsem) 
•   ... a nakonec - MongoDB neni ta nejrychlejsi a nejlepsi NoSQL databaze na trhu.....   

Takze tak. Minusy? Nenasel jsem zadnej skvelej program na udrzbu (jako mysql-workbench apod). Ale nechybi mi, na vsechno mam jeden skript.

Přiznám se, že nevím co si z tohohle příspěvku odnést. Jak se ta databáze vůbec používá? Jestli na veškerou údržbu stačí jeden script tak to IMO nezní moc komplikovaně.
- O MySQL se běžně povídá, že je to spíš parodie na databázi. Rozhodně to není dobrý reprezentant toho, co SQL databáze umí.
- Jeden zápis za 10s (zápis čeho?) nemusí znamenat nic. 10 milionů záznamů taky nemusí být nic (pokud jsem to pochopil jako 10M záznamů celkem).
- A ty zásadní problémy s převodem dat zní jako hodně velké minus.

1/ Pro vyjasneni - postavil jsem si vlastni skript, kterym ctu/pisu v ramci nektere definovane databaze do tabulky (collection). Vystup si davam  do dataframu, kreslim matplotlibem pokud chci. Neni to skript na udrzbu, ale vkladani a kresleni.
2/ nejvetsi databaze tabulka collection ma mereni teplot (+cas). To je tech 1M zaznamu celkem. Je to overkill, ale tak to dopadlo a s timhle mam zkusenost.
3/ POZOR - zasadni problemy vznikly tim, ze jsem kdysi nainstaloval starou verzi MongoDB a ta jela ve starem formatu dat. NEUDELAL jsem dump pred reinstalaci pocitace, takze mi zustal v ruce adresar s kompletni databazi a novy mongodb, ktery ji uz nerozumel. Takze jsem splasil stare ubuntu, starou verzi mongodb, pripojil adresar, dumpnul.  V momentu, kdy jsem mel dump, uz to slo az prilis snadno. Takze moje chyba.

[Olda]

Toho, kdo pro práci s relační DB používá kurzory místo hromadných operací, protože je zvyklý tak programovat, bych věšel za k...e do průvanu 

jak vypada ten update-statement, ktery soucasne pro kazdy zmeneny zaznam pise fprintf do nejakeho logfilu?

[JSH]

Toho, kdo pro práci s relační DB používá kurzory místo hromadných operací, protože je zvyklý tak programovat, bych věšel za k...e do průvanu 

jak vypada ten update-statement, ktery soucasne pro kazdy zmeneny zaznam pise fprintf do nejakeho logfilu?

IMO to vypadá jako hodně blbý nápad. Pokud nutně potřebuješ zaplnit log mraky záznamů, tak si ty upravené záznamy můžeš vytáhnout selectem. Ale fakt si nejsem jistý, co se dá z takového logu vykoukat, pokud je těch upravených záznamů víc než pár desítek.

[Reklama]

[dustin]

IMO to vypadá jako hodně blbý nápad. Pokud nutně potřebuješ zaplnit log mraky záznamů, tak si ty upravené záznamy můžeš vytáhnout selectem. Ale fakt si nejsem jistý, co se dá z takového logu vykoukat, pokud je těch upravených záznamů víc než pár desítek.

Např. se může udržovat historický log změn konkrétního "byznys" objektu. Kdo co kdy jak změnil. A nemusí to být do souboru, ale třeba do úplně jiné DB (např. zrovna to mongo).

[Pavel Stěhule]

Toho, kdo pro práci s relační DB používá kurzory místo hromadných operací, protože je zvyklý tak programovat, bych věšel za k...e do průvanu 

jak vypada ten update-statement, ktery soucasne pro kazdy zmeneny zaznam pise fprintf do nejakeho logfilu?

Můžete zatrigrovat a plnit si tabulku, db log, případně nějaký jiný log. V některých db se o to může postarat audit. Tahat data na klienta, abyste udělal fprintf do logu může být dost drahé.

[Pavel Stěhule]

Toho, kdo pro práci s relační DB používá kurzory místo hromadných operací, protože je zvyklý tak programovat, bych věšel za k...e do průvanu 

jak vypada ten update-statement, ktery soucasne pro kazdy zmeneny zaznam pise fprintf do nejakeho logfilu?

Je to legrace - v praxi bych to delal jinak - ale jde to, napr, pokud chcete zmeny pred, po.

with x as (select * from foo where a between 7 and 10), 
  y as (update foo set b = foo.a + 10 from x where foo.a = x.a returning foo.*) 
  select 'before', x.* from x union all select 'after', y.* from y;

pokud by vam stacily jen zmeny po, tak je to jednoduche:

update ... returning *;

[SB]

...ctu/pisu v ramci nektere definovane databaze do tabulky (collection)...
2/ nejvetsi databaze tabulka collection ...

Jardo Míro, píšete skvěle, ale když už jste si dal tu práci a použil něco jiného než RDB, odbourejte prosím tu relační terminologii - tabulky se v dokumentové databázi NEVYSKYTUJÍ (koneckonců proto vznikla). Collections (kolekce?) a v nich dokumenty. Jasné?

[BoneFlute]

IMO to vypadá jako hodně blbý nápad. Pokud nutně potřebuješ zaplnit log mraky záznamů, tak si ty upravené záznamy můžeš vytáhnout selectem. Ale fakt si nejsem jistý, co se dá z takového logu vykoukat, pokud je těch upravených záznamů víc než pár desítek.

Např. se může udržovat historický log změn konkrétního "byznys" objektu. Kdo co kdy jak změnil. A nemusí to být do souboru, ale třeba do úplně jiné DB (např. zrovna to mongo).

Dělám to - mám na to něco jako verzování.

V prvé řadě bych to plnil do spešl tabulky na stejné databázi.

Nevím, proč by to měla být jiná databáze, ale pokud opravdu je ten důvod jinej než jen "třeba", tak postgre umí spousta věcí. Napsal jsem si v něm Python funkci, která mi při insertu ověřovala, zda IČO existuje dotazem do ARESu. Bylo to pomalý jak prase, ale pro danný případ dostačující. Takže nevidím důvod, proč bych se podobným, nebo lepším způsobem nemohl napojit na cokoliv. Třeba i Filesystem.

[Filip Jirsák]

Nevím, proč by to měla být jiná databáze

Např. proto, že pro ukládání nějakých logů nepotřebujete plýtvat prostorem na rychlých drahých malých discích, případně na to nepotřebujete vůbec plýtvat drahým výkonem relační databáze.

[BoneFlute]

To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.

Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.

[Filip Jirsák]

Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.

Nejde jen o optimální SQL, jde také o strukturu dat. Jinak budete reálný svět modelovat pomocí grafu objektů a jinak pomocí relací.

[Pavel Stěhule]

To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.

Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.

[MartinBeran]

To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.

Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.

Připadá mi, že ORM svádí k programování ve stylu:

Kód: [Vybrat]

sum = 0
foreach a = collection_of_a()
  if test(a) then
    b = collection_of_b(a.b_id)
    if test(b) then
      sum += b.val
return sum
Není mi jasné, jak tohle dobré ORM zoptimalizuje, i když je jasné, že se to dá přepsat do jednoho SELECTu s JOINem dvou tabulek.