Názory k článku
Úvaha ohledně zneužívání LIKE v databázích

Ne jen to, ale autor, dle svých slov profesionál, zřejmě nechápe plně význam operátoru LIKE a tento skvělý a výkonný operátor zatracuje kvůli jedné nevhodné implementaci.

1. autor je odbornik na postgresql
2. ano, existuji legalni pripady, kdy je vhodne pouzit like, ale neni jich mnoho
3. clanek je vyborny a diky za nej

Tak o tom slově "výkonný" by se myslím dalo s úspěchem polemizovat ;-)

Ne že bych LIKE zatracoval, to rozhodně ne, ale je to jedna z prvních věcí které v aplikaci zkoumám pokud jsem povolán k nějakým výkonnostním problémům. Fulltextové vyhledávání implementované přes LIKE, to je celkem oblíbený zabiják výkonu.

Taky si myslím. Když někdo programuje prasácky, není to třeba stavět tak, že je problém v programovacím jazyku (asi je to nadsázka, ale s podobným přístupem se setkávám ve spoustě článků).

+1

Jj. Bohužel tak to je - a nejen u Databází. Většinou je mnohem jednoduší za chyby a nevhodný přístup, či návrch zatratit programovací jazyk a ne lidi, kteří to spáchali.

No zrovna v případě SQL je docela na místě prohlásit, že za spoustu věcí může jazyk. Nebýt SQL, mohli bychom dnes místo SQL databází mít *pravé* Coddovy relační databáze, třeba s nějakou tou implementací Industrial D (viz Chris Date).

Dobry den.
Pracujem ako profesionalny programator cez 12 rokov. S SQL asi 5 rokov (MySQL a ORACLE) aktivne, z toho 2 na ORACLE 9i.
Autor clanku urcite vie o com hovori. No aj to, co napisal, je zbytocne prehnane a kopmplikovane riesenie. Jednoznacne aj ja preferujem normalizaciu a jasne prepojene relacne vztahy na primarne indexy!
Ako tu uz napisal nejeden prispievatel, vela zalezi len na programatorovi ako navrhne databazu a potom ci chape vnutorne procesy, ktore sa v db deju, aby na zaklade toho mohol vytvarat optimalizovane prikazy.
No prikaz LIKE by som nezavrhoval v ziadnom pripade!
Ak si niekto vyfiltruje tabulku aj s x relaciami na niekolko desiatok alebo stoviek zaznamov a na ne aplikuje v klauzule WHERE prikaz LIKE, nevidim v tom ziadny problem.
Mimochodom tieto zalezitosti odporucam diskutovat s expertmi napr. p. Branislav Valny (z ORACLE) a jeho kolegovia.

jo, oraclisti jsou spicka, mohu potvrdit, ze jsem to uz take slysel od znameho, ktery sice nedela do databazi ale jeho manzelka pracuje ve firme, co taky nasazujou oracle a ta se bavila s jednim spoluzamestnancem a ten to taky potvrdil, ze jsou jako spicka.

Použití LIKE je v některých případech zcela v pořádku. Pokud potřebuji vyhledávat ve firemním telefonním seznamu, dotaz SELECT * FROM PEOPLE WHERE NAME LIKE 'NOVA%' je v pohodě. U normalizace samozřejmě naprostý souhlas.

Popsaný případ s příšerným návrhm DB bohužel není až tak výjimečný :(. Přitom k rozumnému návrhu DB člověk dojde i bez vzdělání nebo znalosti NF, chce to jen použít mozek.

Ovsem zname i pripady, kdy je treba provest denormalizaci, ze?

ve většině těch případů si vystačíme s pohledem, že?

Cha cha cha, s pohledem, to jsem se pobavil.

Nebudu se vyjadřovat k obsahu, ale způsob napsání je dost arogantní a vyznívá že "já jsem správný programátor, podívejte se ostatní co jste za voly, uživatelé jsou taky pitomci, jen já vím, co je pro ně správné".

No, autore bez profilu; neoslnil jsi mne, zatím nedostatečná. Naučte se to ještě jednou a přijďte znovu ...

Pokud by se kodéři aspoň zamysleli, po přečtení článků, tak pak tento článek má smysl.

napiste taky clanek o tom ze lidi maji pouzivat transakce. Dost jich to totiz porad nedela.

Jsou mista, kde transakce potreba nejsou (ale dost lidi ani nerozumi tomu kde potreba jsou a kde ne), ale to je podruhe ve velmi kratke dobe co s vami temer souhlasim. Zajimave.

jak jsem ukazoval jinde. Bez transakci nemohou byt ani jednotlive SQL prikazy atomicke, coz vyzaduje norma.

The other non-transactional storage engines in MySQL Server (such as MyISAM) follow a different paradigm for data integrity called “atomic operations.” In transactional terms, MyISAM tables effectively always operate in autocommit = 1 mode. Atomic operations often offer comparable integrity with higher performance.
(z dokumentace MySQL)

…tak nevím. :-)

testnul jsem to. jednak to poskodilo tabulku musel jsem pustit ten repair, pak po nem nejake radky (asi 1000) dokonce z tabulky zmizely.

A presne jak jsem predpokladal pulka byla aktualizovana, pulka ne. Nad tabulkou jsem nemel index, ten by byl asi taky v haji a musel by se rebuildnout.

me se na techto prikladech nelibi, ze nejsou realne. Me se to jeste nikdy nestalo, aby se server restartoval prave v tu chvili, kdy se provadi nejaky velky update. To ja pak mohu jit, zabudovat do masiny vadny hw-raid controler, nechat oracle-db bezet a pote, kdy uzivatel zjisti, ze ma misto dat salat rici, ze Oracle je na prd.

Nahoda je blbec ale statistika je ocelova, transakce jsou monstrance dnesni IT doby a plni zejmena tu ulohu, aby mohl management klidne spat.

Pokud se něco podobného stane u velkého updatu, pak je to pořád ještě ten lepší případ. A ne, nestalo se mi. Horší je to u malého updatu, kde je poškozeno jen pár záznamů a kolikrát na to nepřijdete. A to se mi už stalo. Troufám si říci, že pokud máte rozumně vytíženou databázi, tak při každém násilném restartu (já onehdá zakopl o napájecí kabel) se vám poškodí nějaká data. A teď jak z toho ven? Jedna cesta je používat stabilní OS, stabilní verzi databázového SW, pravidelně aktualizovat, UPS atd. Druhá cesta je použít transakční databázi. V každém případě je to však "vlastnost", o které by měl správce vědět a nějak ji řešit. Strčit hlavu do písku a tvářit se, že problém neexistuje... no to není dobré :-)

Tak vzdy mozte rollbacknut z pravidelnej zalohy, dolezite je, aku mate infrastrukturu. Pokial sa vo firme setri na vsetkom vratane HW, tak nech sa potom nedivi.

Vy snad zalohujete kontinualne?
A zakon schvalnosti funguje spolehlive: Prevazna vetsina poruch je tesne pred denni zalohou. Je snad lepsi ztratit cely den prace nez pouzivat transakce?

Ale kdepak, převážná většina poruch je právě ve chvíli, kdy zálohujete (je to i logicky zdůvodnitelné: disky prostě dostanou zabrat), takže i záloha je poškozená :)

Firmy naštěstí nepoužívají MySQL. Mají serverový HW (ne shit postavený v garáži), UPS, používají transakční DB engine a transakce na úrovni aplikačních serverů, zálohují DB i transakční logy, a drží vždy více záloh. "Webové aplikace" běžící na garážovém HW, LAMP a bez zálohování jsou z trochu jiné kategorie.

...s výjimkou Googlu... :o)

No, to je trochu jiný případ ... Google používá masivní distribuované systémy kde se data ukládají redundantně na velkém počtu strojů. Nehledě na to že to nejsou data naprosto kritická (dají se znovu načíst z netu).

To je otazka, co povazujes za firmu?

heh, nedávno jsem byl v jednom datacentru a většina serverů tam byla normální PCčka. A nemyslím si, že by to byly všechno osobní servery jednotlivců :-D S dostatečnou redundancí se totiž dá úspěšně používat i ten „garážový hardware“.

To se ovšem typicky týká služeb typu Google. Když taková služba ztratí kus indexu, nic se neděje, za nějaký čas ho získá zpátky. Když ale firma ztratí faktury, tak se už samy neobjeví.

Pokud jste ale byl v serverově nějakého hostingu, tak tam v klecích ležely počítače různých garážových firem, co mají své projekty na inetu. A to je přesně ta kategorie "splácám to v garáži, ono to něco udělá, a jestli se ta data ztratí, je mi to jedno".

jedno jim to neni, ale jsou lini zalohovat. Kdyz ztrati data pokladaji to za nevyhnutelne zlo.

Ony to nemusí být vyloženě zbastlené servery pro garážové firmy - nemá cenu zastírat že i servery v racku sem tam odejdou do věčných lovišť. Ne každý server má redundantní napájení zdroje, větráček na CPU taky občas doslouží, kondenzátory na MB taky nevydrží všechno, ne každé datacentrum má dobře dimenzovanou (nebo chlazenou) UPS apod. A taková nevhodně umístěná klimatizace která začne téct, to taky umí svoje ...

Firmy naštěstí nepoužívají MySQL

No jó, ani Google ani Seznam nejsou firmy, to jsou zájmová sdružení :)

To byste se divil kolik firem (bohužel) používá MySQL i na celkem kritické aplikace. To jak je daná aplikace důležitá pro jejich business bohužel začínají zjišťovat až ve chvíli kdy to spadne.

Tak chtěl bych vás vidět jak "rollbackujete z pravidelné zálohy" například v případě většího e-shopu, kde:

(a) může být velmi mnoho dat (řádově GB)

(b) záleží zejména na naposledy vytvořených datech (čert vem rok staré již vyřízené objednávky - výdělek závisí na těch právě odeslaných)

(c) záleží na dostupnosti - uživatelé nepočkají a přímé ztráty za hodinu výpadku v nevhodnou dobu mohou jít klidně do desetitisíců Kč obratu (o nepřímých ztrátách na image apod. ani nemluvě)

To že se šetří na HW ještě neznamená že se na něm nedá provozovat pořádná databáze.

Řeč byla o MySQL, a tam myslím není co řešit. Firebird neznám, nebudu tedy vynášet soudy.

SQL Server nebo Oracle vám dají minimálně to, že můžete začíst s verzí zdarma (SQL Server Express Edition), a poté jen za cenu licence přejít na větší DB server (SQL Server Standard Edition). Nemusíte u toho přepisovat aplikaci. Naopak když začnete na MySQL a budete chtít víc, budete aplikaci přepisovat, což je velký problém.

no treba kdyz mate oracle data guard nebo db2 hadr tak pri havarii neztratite ani jednu transakci a failover na backup server je za nekolik sekund. To je dost dobra vec pro online e=shop, nemyslite?

Dalsi vec je mit db ktera je odzkousena a ne kterou dela par zoufalcu po vecerech.

Dalsi hezka vec je ze profi databaze umi workload manager - nektere dotazy umi vyrizovat prednostne. Takze pak reporty nebrzdi OLTP a nemusite delat reporty nad historickymi daty, ale nad aktualnimy. Aktualni informace maji cenu zlata. Kdyz treba zakaznik zavola nasi reklamce a chce prave aktualni stav protoze pred nekolika hodinama spustil dulezitou a drahou kampan tak muze operatorka vyrobit a poslat sestavy, ktery se nevytvari zrovna rychle tak je dulezity aby to tu databazi nebrzdilo pro normalni provoz.

Krom toho dneska se databaze daji zalohovat velmi rychle ty 2 TB co tu mame se zalohuji na pasky bez disk spoolingu neco malo pres hodinu.

Takze jak tu mistni expert tvrdil 'databaze co muze mit i nekolik GB a to je pak problem' asi nikdy nevidel poradny HW.

ODG stalo $30k na procesor, ale nekdo mi tu psal ze ho uz v 11 EE davaji zadara.

To neni zadny hrdinstvi nacpat hodne dat do db, zalezi na tom jak to je pak rychly. mysql pri 10GB db uz zacne prohravat s cloudscape.

PGSQL ne pri vice datech taky strasnej opruz protoze vacuum. I na 30 GB trva vacuum full hodne dlouho (po 8 hodinach jsem to killnul) pokud je ta db rozfragmentovana treba 3 rocnim provozem.

vacuum full zamyka tablice, takze je zadouci aby to dobehlo co nejrychleji. Krom toho to byla miniaturni db 20-30GB. Od te ocekavam, ze se zreogranizuje na x86 komodity hw s levnym ide diskem za maximalne 30 minut.

db2 9.7 ma taky mvcc a nemusi delat ani stupidni vacuum (pg, firebird) ani pouzivat rollback segmenty (oracle). Nacita starsi verze radek z transakcniho logu. Oracle kopiruje kazdou zmenenou stranku do rollback segmentu, to generuje znacne mnozstvi IO operaci i kdyz ji nikdo nebude cist. DB2 se s tim zacne zabyvat az v pripade ze nekdo chce stary snapshot dat cist.

Taky je zajimave jak i5/os db2 dela recovery z journalu. to je velmi creativni zpusob recovery aniz by se muselo cekat na dokonceni operace. Najdete si k tomu nejake prezentace na webu. z/OS verze DB2 se to naucila casem taky (defered restart), ale i5/os verze to umi porad jeste lepe. unix verze db2 to pravdepodobne nebude umet nikdy pokud nebudou zakaznici dupat at to tam preportuji.

Mne se libi pristup ibm - poslou vam papiry kam si muzete napsat co byste v db2 radi videli a kolik si koupite novych licenci, kdyz to tam dodelaji. tomu rikam spravna orientace na zakaznika. Obvolaval jsem lidi at jim napisou ze chceme preportovat schema evolution z Z/OS do unix verze. i5/OS verze db2 ma zase naprosto suprovej fulltext se semantickou analyzou textu (kterej se normalne prodava zvlast za $30k na procesor) a vybornou podporu pro narodni jazyky. Holt si to i5/os zakaznici umeli vydupat. Ja uz jsem si taky uspesne vydupal u IBM radu featur v jejich softu - u jinych ISV prakticky nemam moc sanci aby mi do krabicove verze dodelali to co chci.

max_fsm_pages je opruz. nastavovat velikost db? to jsme snad jeste v praveku?

jak se ma nastavit vacuum_cost_* aby to jelo rychle?

A všechny ty tunitelný věci na z/OSDB2 nejsou pravěk? :-)

db2 9.7 ma taky mvcc a nemusi delat ani stupidni vacuum (pg, firebird) ani pouzivat rollback segmenty (oracle). Nacita starsi verze radek z transakcniho logu. Oracle kopiruje kazdou zmenenou stranku do rollback segmentu, to generuje znacne mnozstvi IO operaci i kdyz ji nikdo nebude cist. DB2 se s tim zacne zabyvat az v pripade ze nekdo chce stary snapshot dat cist.

No něco na upřesnění: Firebird většinu starých řádků odstraňuje průběžně na pozadí společně s běžným přístupem ke stránkám. Jakmile je zapotřebí provést "sweep", je to příznak, že se něco "podělalo". Pro starší verze řádku nemusí sahat do protokolu - nejenže transakční protokol nemá, ale proč sahat pro nejnovější verzi řádku do jedné (datové) stránky a pro dvě starší verze do dvou různých dalších stránek (protokolu), když je jednodušší a rychlejší všechno shrábnout z jediné diskové stránky? Opravdu "stupidní" řešení. :-)

Obvolaval jsem lidi at jim napisou ze chceme preportovat schema evolution z Z/OS do unix verze.

Schema evolution? To jako tohle?

DB2 UDB for z/OS now provides the ability to change the definitions of tables and indexes without dropping and re-creating the object. This capability significantly enhances both the availability of your database and the performance of data access.

Přidat sloupec do existující tabulky je "pokročílá fíčura"? Nejen že tohle Firebird umí, ale umí to už dvacet let, za plného chodu, je to transakčně opouzdřené a provádí se to lazy updatem dat (verzovaná metadata), takže se databáze nezasekne na půl hodiny, když přidám sloupec do desetigigabajtové tabulky.

precetl jsem si dokumentaci a firebird uklada vice verzi radek do stejneho bloku. kdyz zjisti ze je tam nejaka stara co se uz nepotrebuje (nevim zda i pri cteni bloku nebo jen pri zapisu) tak ji vygumuje. Nektere stare radky to ale nemusi timpadem vygumovat kdyz pak delsi cas k nim nikdo nepristupuje. pokud je takhle cisti i pri cteni bloku tak generuje zbytecne zapisove operace, ktere jsou pomale.

bez transakcniho logu nemuzete delat rollforward recovery, umi tohle firebird?

Pokud mate v logu starou i novou verzi radku jako mela db2 vzdycky tak se za delat i rollbackward recovery coz je velmi zajimava vec. Do logu se musi stara verze zapsat u db2 vzdy takze mvcc neni zadne io navic jako u oraclu a vetsinou se stara verze potrebovat nacist nebude, v pripade ze ano je tu jeste pravdepodobnost ze bude v log bufferu. Mne to nepripada jako nestastne reseni, je to asi to nejlepsi co se da zaridit. Vacuum i rollback segment free a navic setri misto na disku i v bufferpoolu.

no schema evolution umi i zajimavejsi veci: zmenit index podle ktereho se tablice clusteruje, pridat sloupecek do indexu. zbytek uz je docela nuda: pridavani sloupecku, prejmenovani sloupecku, zruseni sloupecku, zmena poradi sloupcu a zmena data typu. Nejzajimavejsi je ze je to provedeno okamzite bez cekani, fyzicky se ta tabulka presoupe casem. Pro data warehousing k nezaplaceni. podporovano je soucasne max. 255 verzi tabulky a 16 versi indexu.

adminovat db2 na zOS je narocnejsi nez Oracle, ma to hodne ruznych prepinacu. naopak db2 na unixu je velmi jednoducha a kazda dalsi verze je snadnejsi. Na zOS panuje opacny trend.

no kolik mela nejrychlejsi masina co jste kdy videl? Mame tu treba db server co dela 1.1M TPC-C. Konzolidujeme na nem databaze a stal necely $3 mega.

mysql nema rollforward recovery, umi jen prehravat SQL prikazy (to je znacne pomale) a jeste v tom ma zname races, takze je mozne dostat po prehrani SQL logu jina data.

S bastlem mysql se vubec nema cenu zabyvat.

Pokud jste nekdy varil v restauraci tak budete prekvapen ze i kdyz doma varit umite, tak se v restouraci vari uplne jinym zpusobem. Protoze postupy ktere pouzivame pri vareni doma nejsou moc skalovatelne.

V databazich je to stejne. OSS db funguji prijatelne maximalne v rozmezich desitky GB dat.

2950 Dell - 2 sockety. 8x15K disky bratru za $9.6k. Ten hw je dnes prakticky zdarma. licence pro db by staly tak $120k. Proto se prave konzoliduji databaze na jednu velkou masinu - znacne setrite na SW licencich, uspora muze byt i 10:1 pri vhodne pouzite virtualizaci.

express edice se daji pouzit na netrivialni produkcni aplikace bez problemu. Jsou to totiz plnohodnotne databaze, ktera maji nejaka technicka nebo jen licencni omezeni. Je to stejne vyspely kod, ktery pohani velke databaze. Neni to nejaky zmetek zbastleny v garazi. Navic mate k dispozici vsechny vyvojove nastroje a knowhow z velkych systemu.

Pokud trvate na tom ze chcete databazi s nulovymi pocatecnimy naklady tak jsou to prave. Zejmena mssql express je velmi dobra vec pro zacatecniky. Mrknete co vsechno ta databaze umi http://www.microsoft.com/express/sql/default.aspx a jake hezke tooly k tomu muzete mit. Vy to nevidite ze se vam v tom bude delat snadneji a rychleji? Lidska prace totiz stoji nemale prostredky.

My treba mame pgsql nasazeny v jedne aplikaci kterou jsme koupili i ze serverem. Ma to pro nas nevyhody:

* opruz s vacuum
* nutnosti porad nastavovat free space map velikost protoze db porad roste. uz se to asi zvetsovalo 3x. Vrchol demence nastavovat cosi podle velikosti db, jak to mame vedet jak rychle poroste?
* replikace slony1 se opravdu velmi spatne adminuje a je nespolehliva, krome toho ze je jeste dost pomala a ma overhead i na strane master db.
* aplikace v 8.3+ nechodi. Zpetna kompatibilita pgsql zjevne neni nic moc. Jak dlouho bude jeste podporovana 8.2, kdo vi.
* pri upgradu na vyssi verzi se musi udelat import/export dat coz je dost opruz pac se jedna o 24/7 aplikaci. Pgsql navic importuje data pomalu jako lemra.
* knowhow o administraci pgsql se spatne shani.
* administrativni nastroje nejsou - vse se dela z command lajny
* monitorovaci nastroje taky nejsou
a to jeste nemluvime o takovych vlastnostech jako HA a recovery

Takze databaze sice stala toho kdo tu aplikaci psal $0, ale TCO co nas to stoji je mnohem vyssi nez kdyby to bezelo na komercni databazi. Kdyby ji napsal pro express edici velke db, tak si normalne misto srani s pgsql koupime standardni edici a mame klid. Ted budete muset jeste nechat nekoho to aplikaci prepsat do jine db, coz jsou zase nemale naklady.

Kde jsme podle vas usetrili pouzitim pgsql? Ja tu inzerovanou usporu nikde nevidim.

Poradím:

Divím se, že takový borci neumí používat google.

free_space_map stačí nastavit jednou a pořádně - případně nasadit autovacuum. Čím déle neprovedete vacuum, tím větší musíte mít free_space_map.

migrace do 8.3, buďto opravit chyby nebo použít http://www.postgres.cz/index.php/Migrace_dat

něco o administraci http://www.postgres.cz/index.php/Desatero , http://www.postgres.cz/skoleni/skoleni_administrace_web.pdf


Administrace http://sqlmanager.net/products/postgresql/manager

Monitoring: http://pgfoundry.org/projects/nagiosplugins http://pgfouine.projects.postgresql.org/

INFO: vacuuming "alexa.resultcache"
INFO: scanned index "resultcache1" to remove 91 row versions
DETAIL: CPU 3.66s/6.46u sec elapsed 131.09 sec.
INFO: "resultcache": removed 91 row versions in 7 pages
DETAIL: CPU 0.00s/0.00u sec elapsed 0.12 sec.
INFO: index "resultcache1" now contains 143751986 row versions in 497612 pages
DETAIL: 91 index row versions were removed.
74 index pages have been deleted, 74 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.01 sec.
INFO: "resultcache": found 91 removable, 143751986 nonremovable row versions in 1647055 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 7503 unused item pointers.
73 pages contain useful free space.
0 pages are entirely empty.
CPU 14.72s/11.47u sec elapsed 361.19 sec.

autovacuum | on
autovacuum_analyze_scale_factor | 0.1
autovacuum_analyze_threshold | 250
autovacuum_freeze_max_age | 200000000
autovacuum_naptime | 60
autovacuum_vacuum_cost_delay | -1
autovacuum_vacuum_cost_limit | -1
autovacuum_vacuum_scale_factor | 0.2
autovacuum_vacuum_threshold | 500

na 8.3 migrovat nebudeme, k nicemu by nam to nebylo. db roste asi o 1 GB denne. Mame autovacuum + 1x denne vacuum. REINDEX ani VACUUM FULL delat nemuzeme, to by trvalo desitky hodin.

Ten /postmaster.pid to je taky opruz, mame tu napsano v poznamkach ze kdyz server spadne tak pgsql kvuli nemu nenastartuje. musi se rucne smazat. Boze to je spolehlivost. Ta pitoma databaze neumi ani spolehlive zjistit zda bezi?

pokud hroz´ı pˇreteˇcen´ı ˇc´ıtaˇce transakc´ı (varov´an´ı v logu) VACUUM FREEZE (1x za nˇekolik let). Neda se to zjistit nejakym selectem? ja nemam zajem se hrabat ve /var/log/messages - zaukoloval jsem admina.

Kdyby ta aplikace nebyla zbastlena v pythonu, nemela 6mb zdrojaku a nepouzivala modul import pg ktery je db neprenositelny tak uz by davno sel pg i se svym vacuum do haje. delat mvcc pres disk je pitomost.

Ne ze by se ten pgsql nejak vyrazne predrel pokud jde o odmazavani dat z velkych tablic. Pravda je tam DELETE CASCADE v relaci tak 1:80 ale stejne je to pomaly jak prase.
crawler=# DELETE FROM alexa.querycache where cached < '2009-03-17';
DELETE 67155
Time: 228892.404 ms

ted mne bezi DELETE + aktivni autovacuum cisti tabulky a dulezita query od klientu co bezi normalne tak 0.3sec normalne ted jede tak 7 sekund. To je radosti na starym belidle s db co nemaj workload manager a neumi poustet dulezite dotazy prioritne. Doufam ze neprijdou stiznosti.

Kdyz bezi autovacuum tak je to tedy znatelne pomalejsi:
crawler=# DELETE FROM alexa.querycache where cached < '2009-03-19';
DELETE 147471
Time: 1331750.621 ms

To vacuum je fakt za trest. Nerikal jsem vam ze je dulezite umet garantovat worst case? Takhle to moc nejde, napere se tam jedno automaticke vacuum a vykon jde do kytek.

taky by mne zajimalo proc se to vacuum chova takto, delam to na jedne tabulce a porad to cisteni restartuje. Proc tu tabulku a index musel cistit 3x? To to nezvladl v jednom pruchodu? To ale generuje strasnyho i/o.

crawler=# VACUUM verbose alexa.resultcache ;
INFO: vacuuming "alexa.resultcache"
INFO: scanned index "resultcache1" to remove 5592194 row versions
DETAIL: CPU 4.69s/18.03u sec elapsed 227.78 sec.
INFO: "resultcache": removed 5592194 row versions in 67423 pages
DETAIL: CPU 2.13s/0.45u sec elapsed 141.74 sec.
INFO: scanned index "resultcache1" to remove 5592205 row versions
DETAIL: CPU 4.69s/17.31u sec elapsed 170.26 sec.
INFO: "resultcache": removed 5592205 row versions in 63695 pages
DETAIL: CPU 1.85s/0.50u sec elapsed 80.27 sec.
INFO: scanned index "resultcache1" to remove 5005436 row versions
DETAIL: CPU 4.39s/32.36u sec elapsed 225.78 sec.
INFO: "resultcache": removed 5005436 row versions in 57313 pages
DETAIL: CPU 1.70s/0.46u sec elapsed 91.58 sec.
INFO: index "resultcache1" now contains 118633367 row versions in 498388 pages
DETAIL: 16189835 index row versions were removed.
87911 index pages have been deleted, 31703 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "resultcache": found 16189835 removable, 118633367 nonremovable row versions in 1649104 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 9117033 unused item pointers.
289416 pages contain useful free space.
0 pages are entirely empty.
CPU 31.78s/74.51u sec elapsed 1226.20 sec.

Teda zajimalo by mne ciste teoreticky zda firebird s tim vacuum taky takhle blbne. jo recovery.conf to je od autoru pgsql opravdu kanadsky zertik. Pripadam si jak roce 1987.

A to se tu bavime o pididatabazi 30GB. Co budeme delat az db naroste na 200GB? To uz abychom to zacali prepisovat pro ten Oraakl. Tady vidite ze pgsql ma pri nasazeni v realne netrivialni aplikaci dost vazne problemy. A to nechavam stranou jeho narocnou administraci na lidskou praci.

Vy si porad myslite ze se nam to vyplati? Kdyby jsme tam meli neco z trojky db2, mssql, oracle tak tyhle db zadne z vyse uvedenych problemu (vacuum normal/full/freeze migrace verzi) nemaji. Administrace pomoci klikacich nastroju, zalohovani do TSM bez problemu, rollforward recovery se dela 1 - slovy jednim prikazem. Ten pgsql ma strasne velky TCO.

V něčem by ti možná pomohla 8.4. VACUUM projíždí pouze změněné datové stránky - neprovádí FULL SCAN tabulky. Jinak:

INFO: vacuuming "alexa.resultcache"
INFO: scanned index "resultcache1" to remove 91 row versions
DETAIL: CPU 3.66s/6.46u sec elapsed 131.09 sec.

V contribu je modul pg_stattuple, skrz který je možné se dostat k údajům jako fragmentace datových stránek, hloubka indexů a podobně. Pokud je nad tabulkou zavěšené hodně indexů, je důležité zvětšit maintanaince_work_mem - např. 3-4 GB.

Nevidím do aplikace, ale předpokládám ať už z názvu nebo z výsledků VACCUA, že tabulka result cache je použitá jako cache. Na to je lepší použít MyISAM nebo memcache - případně vysadit tuto tabulku z autovacuua, a na konec dávek - např. toho masivního deletu přidat VACUUM tabulky. Další možností je použít partitioning a dropovat celé partišny - v pg je partitioning v základu, nikoliv v enterprise edicích, takže není důvod proč se mu vyhýbat.

Proč VACUUM prochází opakovaně, fakt netuším. Musel bych se podívat do zdrojáků nebo se zeptat v konferenci. U mne to nedělá, ale používám 8.4

Vytvořil jsem tabulku s 1mil řádků a zrušil každý třetí.

INFO: vacuuming "public.e"
INFO: scanned index "e_pkey" to remove 333333 row versions
DETAIL: CPU 0.03s/0.44u sec elapsed 0.66 sec.
INFO: "e": removed 333333 row versions in 3922 pages
DETAIL: CPU 0.02s/0.09u sec elapsed 0.14 sec.
INFO: index "e_pkey" now contains 666667 row versions in 2192 pages
DETAIL: 333333 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "e": found 333333 removable, 666667 nonremovable row versions in 3922 out of 3922 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.10s/0.75u sec elapsed 1.36 sec.

hlavně pak další průchod, pokud se nic nedělá je "rychlý". Samozřejmě, protože to už nic nedělá:

NFO: vacuuming "public.e"
INFO: index "e_pkey" now contains 666667 row versions in 2192 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "e": found 0 removable, 666667 nonremovable row versions in 3922 out of 3922 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 333333 unused item pointers.
0 pages are entirely empty.
CPU 0.01s/0.06u sec elapsed 0.08 sec.

O postmaster.pid se většinou nemusíte starat (v nových verzích). Editace recovery.conf je asi jeden z mála úkonů administrace, kdy si připadám, že sedím u Oracle. Srovnávat administraci Oraclu a pg je vtip ne? To může zafungovat na tvoje ťuňtoidní zákazníky, kterým nacpeš předražený Indy. DB2, mssql, oracle sice nemají VACUUM, zase mají svoje jiné šperky dané buďto technologií nebo administrací - patchování Oraclu je taky dobrodružná záležitost, u db2 jsme před týdnem přišli o data a museli číst zálohu. Ukaž mi databázi, která je bez chyb. U pg by VACUUM už neměl být problém - v 8.3 je HOT update, v 8.4 se vacuují už jen modifikované stránky.

Fakt je, že migrace na vyšší verzi by mohla být pořešená líp - na online migraci dělal Zdeněk Kotala - je otázkou, na čem bude dělat pod Oraclem. Zatím můžeš použít pg_migrátor nebo si vyzkoušet pg_restore, který v 8.4 už dokáže běžet paralelně.

Pokud chceš klikat - pořiď si ems admina. Všechno je tam zabalené do klikátek.

ad 8.4 migrace:
* aplikace nefunguje ani s 8.3 - musela by se upravit, asi nejak moc vyrazne ale:
* dump z 8.2 se do 8.3 nenacte kvuli fulltext indexum

ad myisam/memcache:
potrebuju persistentni data, vyroba tech sestav trva znacne dlouho. Tak si nemuzu dovolit po pripadnem restartu stroje dropnout cache. To je pak ta aplikace nepouzitelne pomala.

table partitioning nemam moc rad, driv se to muselo pouzivat ponevadz db2 umela na unixu/windows max. velikost tablespace 64GB coz byl ale desnej opruz. Osobne ho pouzivam jako nutne zlo jen kdyz se tablice nevejdou do tablespace. Nastesti s db2 9 uz tento opruz konci pac minimalni maximalni velikost tablespace je 2TB.

Ale uznavam ze to bude asi nejlepsi navrzene reseni. Musim rict ze je to tedy znacny administrativni opruz v pgsql:
http://www.postgresql.org/docs/8.2/static/ddl-partitioning.html
to se mi delat nechce, na to si nekoho najmeme, napsal jsem tehletem http://www.varlena.com/contactus.php
srovnejte to s db2
http://www.ibm.com/developerworks/data/library/techarticle/dm-0605ahuja2/index.html

jak vam crashla ta db2 a ktera verze to byla?

Obvykle neni duvod delat restore cele databaze, staci udelat restore jen toho tablespace ktere zarvalo. Vy nezalohujete po tablespaces? Pokud mate soft `db2 recovery expert` tak dokonce staci jen dropnout tu poskozenou tablici a udelat na ni rollforward.

Uznavam ze oracle je v tomto lepsi nez db2, ten umi delat restore na urovni db bloku (obnovi jen ty pozkozene bloky ze zalohy); je to jen ponekud administrativne narocnejsi na muj vkus. ja recovery databazi nedelam, mozna ze na to budou mit nejaky tooly.

Na ten EMS manager jsem se dival, vyzkousel jsem db2 verzi, ta mela vazny bugy (neukladala konfiguraci pripojeni k db, a taky pouzivala V8 syntax oproti V9 db) tak jsem ji smazal. Kdyz se holt setri na QA testingu tak pak nejsou sales. Na tu pgsql verzi EMS se podivam casem.

Takhle to dopadne kdyz se clovek necha premluvit na OSS databazovy soft. Je s tim jeden problem za druhym:
NOTICE: number of page slots needed (1950384) exceeds max_fsm_pages (1000000)
asi mi tim chce naznacit ze 30GB databaze potrebuje 2 mega? no dobre nastavil jsem mu je na 5 mega.

db2 určitě nebyla poslední verze - možná 7. Netuším, db2 v práci neřeším.

Doporučuji Release Notes pro 8.3 - je tam sekce věnovaná i TSearch2 aplikacím a importu z 8.2 do 8.3. Ostatně Release Notes je v každém případě, to co potřebuješ.

Partitioning v pg je lepší než žádný. A v 8.5 by se měl upravit, tj. přidat pár příkazů. Aby se člověk neupsal, tak stačí použí skript v shellu nebo uloženou proceduru.

NOTICE: number of page slots needed (1950384) exceeds max_fsm_pages (1000000). Tím to chce naznačit, aby ses podíval do dokumentace a přečetl si co max_fsm_pages znamená, a co se stane nebo nestane, když jej přešvihneš. V 8.4 už si fsm pg "jakoby" udržuje dynamicky.

Patrně uživatelé db2 nebudou tím typickým klientem EMS manageru. Verze v pg fungovala v pohodě, a už v roce 2004 měla integrovaný debugger plpgsql.

Nezlobte se, ale postupovat dle logiky "nikdy se mi to nestalo takže nebudu přemýšlet jaké by to mělo následky" je poněkud naivní. Věřte že náhlý pád serveru není nic až tak výjimečného - může vypadnout elektrika a selhat UPS, může vyhořet zdroj, může přijít blbec a vytáhnout napájecí kabel ze serveru ... fantazii se meze nekladou. A pokud databáze neustojí ani takhle základní typ výpadku, tak se nedá mluvit o spolehlivosti.

Jistě, může se pokazit i řadič (i to už jsem viděl), ale to už je zase o kus dál. On totiž úplně stačí pokažený driver pro chipset, a je to. Ne že by nestálo za úvahu jak to sledovat a jak na to reagovat (v rámci standardního recovery plánu), ale asi se shodneme že je to řádově méně pravděpodobné než prostý pád serveru.

tato "nebezpecnost" je u mysql dan za rychlost a nie stastny navrh. Ale uprimne, stalo sa nikomu v realnom nasadeni, ze by sa server restartoval(spadol) pocas vykonavania updatu? Ja si myslim, ze pri spravnej udrzbe systemu to skoro ani nieje mozne.

Stalo. Poprvé to byl idiot, který vytáhl kabel. Podruhé to byl ten samý idiot kdy pro změnu vypl natvrdo diskové pole u špatného serveru. Ale uznávám, že to není obvyklé a že to byla naše chyba, protože jsme ho neměli do servrovny pouštět. Bohužel to byl správce druhého serveru a tak jsme ho tam pustit asi museli. Pazoury bych mu tehdy nejraději urazil.

Já jednou viděl server v kanclu, kde uklízečka brzo ráno přišla, vrazila vysavač do UPS, a začala kancelář luxovat. Po půl minutě overloadu UPSky provedl server automaticky shutdown. Dali červenou nálepku s upozorněním na zásuvku co byla na UPSce, a situace se opakovala. Dali dětské zámky na zásuvky, ale uklízečka je vyndala ze zásuvky. Takové osobě urazit obě ruce.

Která firma je tak blbá, že dá uklizečce (nebo jakémukoliv jinému neškolenému zaměstnanci) bez dozoru přístup k serveru?

Spíš dali serveru bez dozoru přístup k uklízečce. :]

To byla malá firmička, a server ležel kdesi v rohu v jedné kanceláři. Samostatná serverovna pro umístění dvou třech serverů je pro malé firmy drahá a zbytečná.

Spousta malých firem má malý box pod stropem (nebo jinde, ale pod stropem to bývá často, protože to nepřekáží) se servery a UPSkou a pod zámkem. Uklizečka prostě nemá mít přístup k serveru stejně jako nemá mít přístup do trezoru.

Jistě takové firmy jsou. Také je ale hromada firem, které nemají ani tu UPS, natož server v racku. Pokladna je ve formě kasičky zamknuté v šuplíku stolu, a HR materiály zamknuté ve skříni. Prostě jim to tak stačí, protože jsou malí. Doma svůj počítač asi nezamykáte do racku, i když jsou na něm citlivá data, a své papírové dokumenty nemáte v trezoru. Občas se podobně chovají i firmy o desítkách lidí, protože rády šetří a nemají ještě špatnou zkušenost.

Nemusíte psát, jak je fyzická bezpečnost důležitá. Dobře to vím.

> Ale uprimne, stalo sa nikomu v realnom nasadeni, ze by sa server restartoval(spadol) pocas vykonavania updatu?
Veril by jste tomu ze nekdy nejake SQL prikazy bezi treba i tydny? Nebo sypete 15k updatu do serveru za sekundu. Pravda kdyz davate databazi jeden jednoradkovy update za 5 minut tak pravdepodobnost ze se havarie trefi zrovna do nej je mala. Krom toho transakce chrani take pred havarii/kilnutim aplikace.

Na linuxu s jeho demetni spravou pameti tam kdyz dojde pamet tak kernel odstreli ten oracle, pac ji ma nejvic. Ja si myslim, ze pri spravnemu navrhu memory managementu to skoro ani nieje mozne.

Na linuxu s jeho demetni spravou pameti tam kdyz dojde pamet tak kernel odstreli ten oracle, pac ji ma nejvic

Tak hloupý zase OOM killer není. Nejdřív střílí procesy, které už dlouho nepožadovaly CPU čas. Krom toho mu lze celkem snadno říct (přes /proc/$PID/oom_adj), aby Oracle nechával až na později anebo vůbec nestřílel.

To bohužel nic nemění na faktu, že taková správa paměti je dementní. Ale to je na jinou diskusi.

No, a není lepší správně nastavit procesy tak aby OOM killer nemusel ty procesy střílet? Nehledě na to že žádný program není bez chyby, a může spadnout například na SIGSEGV "sám od sebe".

To je skoda, ze je to na jinou diskusi, protoze me by treba celkem zajimalo, jake lepsi reseni byste navrhoval.

Já bych navrhoval do každé mašiny zavřít trpaslíka vycvičeného k rozhodování který proces je důležitý a který může odstřelit.

Ja myslim, ze prave o to se vyvojari jadra snazi. ;-)

Zkuste na rootu vyhledat OOM Killer v diskuzích ke článkům a zprávičkám. V krátkosti:
- nepoužívat fork/exec, ale nějakou obdobu CreateProces
- používat thready místo worker procesů
- při alokaci paměti jí opravdu vyhradit (tedy nelhat o paměti)
- když paměť není, tak se chovat dle normy jazyka C (alokace vrátí null),
- aplikace by měly být schopné správně reagovat na nedostatek paměti

Zkuste si to s Oraclem nebo MS SQL Serverem. Když selže alokace, tak zmenší nějaké buffery, nebo selže pouze provádění statementu, který paměť potřeboval. Slíbit procesům paměť, a pak je různě losovat a střílet, to je linuxové zvěrstvo.

Memory overcommit jde vypnout, ale pak brzo dojde paměť. Důvodem je nadužívání konstrukcí, které mohou spotřebovat spoustu paměti, ale většinou jí nepoužijí. Příkladem je fork a fork/exec.

Reakce na nedostatek paměti NENÍ v rukou programátora. Na Linuxi díky overcommittingu projde prakticky jakákoliv alokace, i když paměť není (malloc vrátí pointer). Když potom aplikace zkusí paměť použít, kernel zjistí, že aplikaci slíbil paměť, a teď jí nemá. Pak je čas na OOM Killer. Autor aplikace s tím moc nenadělá. Minimálně na Windows a Solarisu je situace řešená daleko lépe. O paměti se nelže, threading je dlouhá léta funkční, a příšernost fork/exec není třeba používat.

http://www.root.cz/zpravicky/steve-ballmer-linux-je-vetsi-hrozba-nez-apple/257669/

misto aby vylepsovali oom killer by mohli prestat lhat o pameti. Navic ta sama aplikace na windows kdyz se srovna s linux verzi tak linux verze zerou mnohem vic pameti.

Solaris taky neni zadny zazrak, 32 bit verze ma swap max. 2GB. 32bit solac je kupodivu vyrazne rychlejsi.

POSIX.2 z roku 1996 nezná vfork. Možná právě proto už 30 let aplikace vesele používají fork/exec. Navíc vfork má své vlastní problémy:
http://linux.die.net/man/2/vfork

Které konkrétní možnosti máte na mysli u CreateProcess?

dokavad nedefinujete 'netrivialni', tak se jedna bohuzel o kecy

jenomze mysql/isam neumi provest atomicky ani jeden (cely) prikaz.

mate ale nekolik problemu:

1.
V prvni rade musite umet detekovat ze vam mysql samo od sebe zbuchlo nebo ze vam spadnul OS. Havarie OS ty dejme tomu budeme umet spolehlive detekovat, ale mysql je udelane tak ze kdyz crashne tak se samo restartne - jak vlastne zjistit ze padlo?.

2.
Budete muset detekovat v aplikaci chybove stavy jako treba UPDATE vice nez 1 radky zarvalo protoze doslo misto na disku.

3.
Takze detekce zda se vam vubec podelali nejaka data neni zrovna trivialni. Vetsina mysql aplikaci ignoruje nejake navratove kody, proste tam jen vali sql statementy.

4. Fajn takze i kdyz sance ze zjistime potencionalni poskozeni dat je velmi mala rekneme ze to na 100% zvladame. Kdyz se to zjisti tak se musi zashutdownovat databaze co mozna nejdrive abychom zabranili dalsi ztrate dat - uzivatele vkladaji data do poskozene databaze. Ma na to vubec nami pripojena aplikace prava?

5. Pak je potreba udelat restore ze zalohy, vybrat spravne binarni logy od posledni zalohy a prehrat je. Zrejmne dost rucni prace admina.

6. neuvazujeme pro jednoduchost zname pripady races, kdy mysql zapisuje prikazy do binarniho logu v nespravnem poradi a tedy jejich prehranim dostaneme odlisna data od puvodnich. Tyto bugy jsou dlouhou dobu neresene.

Jak vidite atomicita sql statementu je pro mysql/isam prakticky nedosazitelny highend.

Nejake dalsi otazky?

Aneb krásný příklad jak si marketing dokáže chytrou formulací udělat z průseru skvělou featuru ;-) Sice vám nezaručíme integritu dat, ale zato je to strašně rychlé!

Já samozřejmě chápu myšlenku toho článku (zhruba "Nezneužívejte LIKE operátor k dotazům nad nedostatečně normalizovaným schématem!") ale trochu mi tam chybí nějaké jasné shrnutí kdy je použití LIKE operátoru v pořádku a kdy to zavání čuňárnou.

Totiž vyjdeme-li z toho že článek je určen hlavně těm kdo si popisované problémy neuvědomují, hrozí že to buď vůbec nepochopí a nebo přejdou k opačnému extrému (LIKE je absolutně fuj a kdo ho použije není skutečný programátor!) zhruba ve stylu příkazu GOTO. Na školách se učí že je to fuj, tak si spousta programátorů myslí že je to fuj ... a přitom v některých případech je jeho použití zcela korektní (viz. například http://kerneltrap.org/node/553)

No ale hlavně se bojím že obávám že ti kteří by si tento článek měli přečíst především (tj. ti kdo zvěrstva s LIKE páchají) si ho nepřečtou protože si myslí kdoví jak to není fikané - vím o čem mluvím, několik takových individuí která sebe sama nazývají programátory znám.

Napadat zde timto zpusobem cloveka, ktery denne prispiva vyvoji pgSQL, zhruba co mesic vydava clanky zde na rootu, obstarava pgsql.cz, je vzdy ochotny poradit a na rozdil od ostatnich v hlave ma hodne, mi prijde ubohe, zvlast od neregistrovaneho NOT LIKE(AUTORa). Jsi ubohy chlapce.

mozna ubohy, ale ma pravdu. na zacatku autor nadava na LIKE, pak predvede priklad, na kterem se snazi chybne pouziti LIKE predvest, ale predvadi pouze app. s chybnym navrhem... atd.

velmi slaby clanek.

a je mi uplne jedno, kolik domen autor provozuje, co na ne pise a kam prispiva. hodnotim clanek, nikoli barvu autorovych oci.

Je to tak. V principu by šlo se článkem souhlasit, kdyby ovšem byl formulovaný ve stylu "LIKE je často použit chybně, lepší je nahradit ho tak a tak". Ale tady je stavěný do pozice "existuje špatné použití operátoru LIKE, tudíž je operátor LIKE špatný a kdo ho používá je blbec", a to je prostě jednoznačně špatně.

Je to možná malinko přesazené, ale všichni se tady prsíte jako že tenhle problém neexistuje a on existuje a je to skutečně problém který není jen technický jak je z článku, kterému je vytýkána omáčka, patrné. Samozřejmě root čtou samý technicky uvažující lidé, kterým je hned všechno jasné :-D ale mě příjde forma i rozsah článku absolutně ok a dobře se mi to četlo. Asi proto, že s tím občas v práci taky bojuju ;-)

Ale přece o tom ten článek je -- o tom, že je potřeba se 2x zamyslet, než použijete LIKE.
A na reálném příkladu ukazuje, že to co se na první pohled může zdát jednodušší (tj. držet si data pohromadě a použít LIKE) v důsledcích vede jen k problémům. Bohužel spousta lidí nemá dostatečné znalosti o fungování relačních databází a vůbec tak nedokáže posoudit, co je správné řešení (chybná úvaha "musel bych k tomu připojovat další tabulku -- bylo by to pomalé") -- tady si tito lidé můžou přečíst a na příkladech vyzkoušet co opravdu funguje lépe.

Ne že bych k článku neměl výhrady, ale o demonstraci nevhodného použití operátoru LIKE snad šlo, ne? A to že někdo použije operátor LIKE namísto toho aby data správně normalizoval a použil standardní porovnání je celkem častým problémem (věřte nebo ne).

Samozřejmě, LIKE operátor má spoustu dalších problémů (například výkonnostních - osobně jsem řešil výkonnostní problémy u jednoho e-shopu který LIKE používal pro fulltextové vyhledávání v popisech výrobků a i při minimální zátěži 100% vytěžoval SCSI disky protože generoval soustaný datový tok přes 80 MB/s), ale to nebylo tématem tohoto článku, ne?

Souhlasim s tim, ze takovy clanek nepatri na root, ale na zive nebo lupu, kde se takovi koderi, co jsou schopni spachat vyse popisovane spis vyskytnou. Predpokladam, ze na root lamy moc nechodi. Clanek by taky klidne moh zabrat tak tretinu objemu, ja jsem se po precteni par odstavcu priserne nudil... napriklad rozdil mezi normalizovanou a nenormalizovanou databazi by pokryl jeden odstavec, neni nutne omilat deset prikladu. A podle meho nazoru operator LIKE muze byt za urcitych podminek celkem uzitecny, stejne jako treba regularni vyrazy.

takove clanky prave na root patri, i kdyz by mozna mohl byt malinko kratsi. Celkove ale skvela prace, za kterou patri velky dik!

jinak LIKE je v urcitych pripadech OK, napriklad pokud ma formu napriklad 'hledaneslovo%'. Ovsem forma '%hledaneslovo%' je opravdu silenost nejvetsi

A to je ta databáze tak blbá, že nedokáže „LIKE '%asdf%'“ optimalizovat na „= 'asdf'“? (Když už stejně provádí tuny dalších optimalizací?)

A jak byste si takovou optimalizaci představoval? :-))) Dejme tomu, že bych měl tabulku knih se sloupcem Obsah, kde by byla hodnota třeba
"Výskyt střevlíků v Krkonoších."
Jak by databáze měla optimalizovat "select * from tab where obsah LIKE %střevl%" na "select * from tab where obsah = 'střevl' ??

Otázka je co znamená sama, třeba v téhle (placené rozšíření) to stačí nastavit.

http://sql602.sourceforge.net/helpdir-cs/xml/html/fulltext.html

Ono to ani nejde - like %neco% může najít něco jiného než fulltextový operátor. Like porovnává znak po znaku, kdežto fulltext po tokenech (dalo bz se to přirovnat, ke slovům). K tomu se ještě tokeny převádí na lexémy - fulltext dohledá žlutý, žluté, žlutá - to může být (podle nastavení) jeden token.

Existuje metoda, jak připravit index, který by dokázal akcelerovat vyhledání podřetězců v řetězci. Má jen jednu dost velkou vadu. Výsledný index je řádově větší než indexovaná data.

ju, souhlas

Tak existují samozřejmě databáze které fulltext přímo obsahují, ale dává to pochopitelně obecně jiné výsledky než LIKE operátor. Otázkou je čeho chcete dosáhnout - většina problematických použití LIKE se kterými jsem se setkal byla triviálním pokusem o fulltext.

A k tomu už existují vhodnější projekty - ať už tsearch2, nebo například Lucene (osobně dávám přednost Lucene, ačkoliv jsem velký příznivec PostgreSQL).

Autor příspěvku se možná snažil říci, že pokud hledáte '%střevl%', tak výsledek musí obsahovat i výsledek hledání 'střevl%' a '%střevl'. DB může tyhle věci vracet na prvním místě, protože se k nim díky indexu dostane výrazně rychleji, než k '%střevl%'. Kdo si počká, dočká se nakonec i výsledků hledání '%střevl%'.

V praxi to samozřejmě nemá moc význam, datový model musí být slušně navržený.

Což je ovšem úplně k ničemu pokud ty výsledky chcete třídit podle daného sloupce (například podle ID). V tom případě musí databáze stejně načíst všechny výsledky, setřídit a až potom může vracet uživateli.

Nehledě na to že problematická použití LIKE operátoru se většinou týkají větších textů (například popisy výrobků v e-shopu), zhusta HTML formátovaných, takže pravděpodobnost že najdete dané slovo hned na začátku textu je mizivá (už proto že tam nejspíš bude nějaká HTML značka).

Jak jsem říkal, v praxi mnou popsaný efekt nemá velký význam.

Používat LIKE jako náhradu fulltextu je samozřejmě hrubě špatně.

Ano, ta databáze je tak "blbá" že vám tuto nesmyslnou optimalizaci neprovede. Ono totiž ty dvě podmínky nejsou ekvivalentní.

Některé LIKE dotazy optimalizovat lze (například postfixové dotazy, tj. dotazy "retezec%" lze optimalizovat pomocí indexů), ale většina je bohužel "neoptimalizovatelná" :-(

Ovsem forma '%hledaneslovo%' je opravdu silenost nejvetsi

Co třeba když hledáte Karlovo náměstí (náměstí Karlovo, nám. Karlovo, Karlovo nám. ap.)?

WHERE `ulice` LIKE '%Karlovo%'

Mno, nechci se dotknout pana autora, ktery je urcite znalec, ale 1NF vznikla jako historicky prehmat E. Codda koncem 60. let a od te doby se o ni siri dost bludy. V te dobe to mozna nekomu prislo primocare, ze data jsou pouze integery a retezce (viz Codduv paper), ale prece jen, doba pokrocila a v dnesni dobe neni zasadni problem (technicky ani logicky) mit jako data cokoliv, na cem lze definovat usporadani, coz jde klidne i na serializovanych objektech, mimochodem. Souhlasim s tim, ze LIKE je v podstate na pytel a pro lamy, ale argumentovat pri zduvodneni takovymi brontosaury jako je 1NF je mimo misu.

Ne tak úplně rozumím Vašemu příspěvku. Data klidně mohu mít serializovaná, ale musím mít bokem další informaci, kde mi co začíná (a případně končí). A teď záleží na tom, zpracovávaná data jsou ro nebo rw. Pokud mám strukturovaná data a odpovídající prostředky, tak jsem vždy schopný snadno vytahnou požadovanou podmnožinu dat a jsem schopný stejně tak snadno provést aktualizaci. Toto je praktický důsledek 1NF. Jde o to, aby se výpočetní síla neztrácela v zbytečném a opakovaném parsování. Pokud jsem schopný těchto činností, pak 1NF neporušují ani "nové" datové typy v SQL jako jsou struktury nebo pole. Vždy jsem tam schopný snadno pracovat jednotlivě (a to ať už s prvkem pole nebo položkou struktury).

1NF je zásadní z pohledu aplikačního vývojáře. Co je hlouběji, je už jiná oblast. Tam dochází k serializaci - a např. u PostgreSQL se serializuje celý záznam, nikoliv jednotlivé položky záznamu. Ale to už je pro programátora transparentní, a stará se o to systém.

Určitě si nemyslím, že by 1NF byla historický nesmysl. Zdaleka ne a nevidím jediný důvod, proč by 1NF měla v dohledné (nebo nějaké) době zaniknout¨¨¨¨¨

Naprosto s vámi souhlasím. Jenže v posledních letech se vyskytla potřeba ukládat do DB například XML. To se dnes řeší tak, že se do jednoho "stringového" pole uloží celé XML. To XML potom indexujete zvlášť. Jde svým způsobem o porušení první normální formy. Ovšem předchozí řečník to zcela nesprávně interpertuje tak, že 1NF je přežitý nesmysl. Taková interpertace nejspíš plyne z nepochopení problematiky.

Experti vědí, "experti" se učí, neschopní se nepoučí, a idioti se ani neučí.

Pocitace by meli slouzit cloveku a ne naopak. Pokud je pozadavek, ze ma byt volne-textova poznamka a v te se ma dat vyhledavat (nebo i vyhledavat napr. podle casti jmena), tak je LIKE zcela na miste.

Popsany priklad je samozrejme prasarna, o tom zadna.

A na konec poznamka: LIKE '%jmeno.prijmeni@firma.cz%' je i tak spatne. Pak to na dotaz na dokumenty uzivatele anna.novakova@firma.cz najde i dokumenty patrici marianna.novakova@firma.cz. To chce mit to ulozene ve forme ;email1@firma.cz;email2@firma.cz;email3@firma.cz; a nasledne hledat '%;jmeno.prijmeni@firma.cz;' :-)

„tak je LIKE zcela na miste“
Spíš to vypadá, že selhal analytik dané aplikace a nedokázal objevit uživatelem požadovanou funkcionalitu – uživatel na to pak rezignoval a řeší tím, že si píše poznámky a následně v nich vyhledává (to je ten IS uvnitř IS, o kterém se píše v článku).

V některých případech, kdy přebíráte data z jedné strany a dotazy z druhé strany a vy jste uprostřed a nemůžete ovlivnit ani jednu stranu, tak vám často nic jiného nezbývá. Samozřejmě pokud děláte IS pro konkrétního uživatele, tak je potřeba to zvážit v návrhu.

Nehledě na to že uživatelé často nejsou schopni specifikovat co všechno chtějí, a když zjistí že jim tam něco chybí tak si přiohýbají aplikaci za pochodu namísto korektního rozšiřování pomocí change requestů (například právě tím že poznámku zneužívají pro ukládání dalších informací, a úspěšně tak sabotují 1. NF).

Ale pochopitelně existují i aplikace (ať už historické nebo nové) kde to rádobyanalytik takto navrhnul a rádobyvývojář zbastlil.

Nj, když uživatel pořádně neví co chce, tak to analytik moc nezachrání. :-D

To chce mit to ulozene ve forme ;email1@firma.cz;email2@firma.cz;email3@firma.cz; a nasledne hledat '%;jmeno.prijmeni@firma.cz;' :-)

To je samozřejmě také blbě, správně to chce mít další tabulku s e-maily propojenou s uživatelskou přes cizí klíč.

O tom je cely clanek. Mne jen zaujalo, ze reseni, ktere prezentuje, je nespravne nejen pouzivanim LIKE kde se nema, ale celkove. :-)

dávám jak jsem dostal.

Článek je sice jasný a řeší dobré téma, to je fakt, ale způsob jakým problém prezentuje je hrozný. Jak už tu bylo řečeno článek je zbytečně dlouhý a pocitu arogantniho vyznění článku se taky nemohu ubránít. Jsem ale přesvedčený, že to nebylo cílem. Ale věta "Věřte nebo nevěřte, tento komplikovanější příkaz bude rychlejší (při objemu dat větším než malém)" na mě působí dojmem, wow teďka jsem vám řekl informaci co jste určitě netušili a vyrazí vám dech.

Zajímalo by mě komu je článek prmárně určen? Předpokládám, že v každém kurzu databází ať již na střední nebo na vysoké škole se normální formy, užití spojovací tabulky při vazbě m:n a vhodnost uváženého užití LIKE učí. Já si to prošel na střední i na vysoké a pokaždé to tam bylo. Předpokládám, že to bude i v každé knížce věnované databázím.

V žádném případě to není útok na autora, evidentně ví o čem píše, ani na obsah, ale na formu článku. Nešlo by prostě napsat méně rozsáhlý článek o tom, že takové a takové špatné navržení databáze, dotoho ještě neuvážené použítí LIKE je výpočetně náročná prasárna a přpojit výsledky měření při různých situacích a objemu dat?

To je právě to, všude se to učí, všude to píší, ale pořád je to prd platný. Jeden článek na tohle téma navíc přeci nemůže uškodit, spíše naopak. A tím stylem psaní se aspoň přes negativní asociaci víc vryje do hlavy :-D

Ono se to sice všude učí, ale do praxe se pak dostanou i zcela nepoznamenaní samouci podle kterých je samozřejmě jakákoli VŠ ztráta času :-D

Problém je, že učit není totéž co naučit. Pokud takovou věc provede absolvent, měl by spálit diplom, a jeho popel si sypat na hlavu.

Mne se naopak rozsahlost clanku libi a libi se mi na nem i ty detailni priklady, ktere si hned clovek muze odzkouset aniz by to vymejslel cely sam. A navic pro nekoho mene znaleho to znamena i priklady na ne zrovna caste veci (generovani dat).

V praxi je dulezite se od neceho odpichnout. Ano, ja vim, ze dokumentace k PSQL je opravdu rozsahla a kvalitni, ale kdyz vim, co potrebuju, ale nevim nazvy funkci, tak se to blbe hleda. Tady je funkcni priklad v kontextu jednoducheho testu a to je ten zaklad, ktery je potreba. Pak uz se da v pohode pouzit dokumentace, protoze byl nalezen "vstupni bod" :)

Jiste. Stacilo napsat: Mrknete se na normalni formy, mnohym by to asi pomohlo. Dekuji a naschle.

Jenze to by si Pan Autor pripadal nejspis malo zajimavy. Cele je to jen zbytece a nesmyslne protazeny bezny zaklad databazovych znalosti a ze dneska kdektery programatora neni dabatabazista snad vsichni vime.

To je dobrý nápad...některé knihy o programování v Javě by pak mohli vypadat následovně: "Spring, Hibernate.".

To, ze se obcas LIKE pouziva vyznacne blbe, jeste neznamena, ze je na tri veci. Pri vhodnem pouziti je IMHO nenahraditelny. Jen to chce take trosku premyslet ...

Takze ani z ankety jsem si nevybral - spravna odpoved by IMHO mela byt: Podle okolnosti.

Obdobnym zpusobem (jako v clanku) by se daly najit priklady udesneho pouziti takrka na cokoli, vcetne operatoru =. Kuprikladu index case sensitive a vyhledavani case-insensitive SELECT * FROM TBL WHERE UPPER(NAME)=UPPER(jmeno)
Neco podobneho jsem uz videl na vlastni OKi :-(

jasně :)

to že je blbě návrh DB ještě neznamená že je nějaký SQL příkaz na prd .)

a jak bys to napsal jinak? Uznavam, jsem DB ignorant, ale s tim upper mi to prijde koser, i kdyz se samozrejme rozhodi indexy, o tom zadna (ale kdyz je takovy pozadavek...).

Např.
materializovaný pohled s indexem
počítaný sloupec s indexem
funkční index

Záleží na tom, co podporuje DB. V nejhorším případě je možné přidat nový indexovaný sloupec s hodnotou UPPER(NAME) a aktualizovat ho manuálně.

Nebo (nejjednodussi cesta) dalsi index podle UPPER(NAME)

Omluva za slepotu - jeste jsem nemel ranni kafe ...

Prohlasil Rudolf Kryl.

clock@duke:~/links-current$ fgrep goto *.[ch] | wc -l
1038

Tyhle dogmata osrat.

Ale jo, goto ma sve pouziti, zejmena v jazycich, ktere nemaji vyjimky a jen omezene moznosti vyskoku ze smycek (jasne, myslim ted cecko). Ono vlastne to goto v cecku tak hrozne neni, je dost omezene, kam se da skakat (narozdil od basicu, kde se da klidne skocit doprostred subrutiny nebo radku s DATA), to takovy longjmp() je zajimavejsi :-)

Jiste, puriste namitnou, ze se goto da nahradit strukturovanym programovanim. Da, ale brano do dusledku by nam dostacoval jen nejaky rekurzivne vycislovany jazyk (bez smycek) nebo simulator Turingova stroje (v podstate se jedna Brainf*ck), tam taky goto neni :-)))

Skuteční puristé namítnou, že goto se dá nahradit tail cally...

Chtel bych videt, jak byste psal stavovy automat pres tail cally. Nerikam, ze to nejde, ale otazka je, zda je to citelnejsi.

Proc bych ho psal zrovna pres tail cally? Jednak ho nemusim psat vubec, protoze na matchovani retezcu regularnim vyrazem jsou knihovny a i kdyby mi to z duvodu optimalizace nevyhovovalo, tak tipuju, ze v RDBMS jsou podstatne obtiznejsi ulohy, nez prevod regularniho vyrazu na konecny automat ;-)

Jednoduše. Každý stav je jedna funkce a každý přechod mezi stavy je jeden tail call. Stavy jsou pěkně pojmenované (jako funkce) a při přechodu z jednoho stavu do druhého se snadno předávají případné parametry (pokud je potřebuju).

Vy byste radši měl smyčku se switchem a měnil stavovou proměnnou, nebo dokonce používal goto? Neříkám, že to nejde, ale otázka je, zda je to čitelnější.

Takhle udělaný stavový automat přes tail cally ti bude konzumovat množství zásobníku lineárně závislé na množství projitých stavů. Gcc sice ty tail cally umí optimalizovat na skoky, ale nedělá to vždy (tato optimalizace nejde dělat, pokud se ve funkci vyskytuje pointer na proměnnou zásobníku a není možné dokázat, že ten pointer "neutekl" mimo tu funkci) a navíc to uživatel nemusí kompilovat pomocí gcc nebo nemusí zapnout optimalizace.

Tady není otázka, zda to je nebo není lépe čitelné, tady je problém, že takhle napsaný stavový automat nebude při dostatečně dlouhém vstupu fungovat.

Taky jsem si to myslel, ale nebyl jsem si jisty. Diky.

Nemyslim, ze by se to dalo takhle kategorizovat, jestli je Links hodny nebo nehodny nasledovani. Links ma urcite dobre a spatne vlastnosti. Pro nekoho jsou dulezitejsi ty dobre vlastnosti pro nekoho zas ty spatne. Nasledovanihodnost tak zavisi na pozorovateli.

Vsak zkompilovany jazyk je nemetodicky. Proto je treba pouzivat interpretovane jazyky.

Prikaz GOTO bych prirovnal k airbagum.
Za jistych okolnosti je nutne a nenahraditelne, ale rozhodne bych ho nepouzival denne.

Jestli je links splácaný tak strašným způsobem, jako je splácaná elektronika Ronji, tak se ani nedivím :)

to Vám na rootu emigrovali všichni autoři, že pouštíte i toto? Tvrdit, že like je špatný a kdo ho používá je blb mi příjde hodně arogantní, pokud má autor - expert největší - jinou metodu, jak v databázi najdu slova obsahující slovo bobr, rád si ji poslechnu.

no vsak je to v clanku popsano ne? Pokud je pozadavek na extremne rychle vyhledavani, musi se puvodne nestrukturovany text rozsekat do navazbenych tabulek. Predpokladam, ze napriklad takovou adresu mas v databazi rozsekanou na ulici, mesto, PSC ne? Nebo se snad ma vyhledavat stylem select * from address where addr like '%110 00%', kdyz hledam vse s PSC 110 00? Samozrejme jeste lepsi je mit ulice a mesta zase v dalsich tabulkach.

Ok, svůj předchozí příspěvek jsem trochu přehnal, autorovi se omlouvám, v mnoha ohledech je článek velmi použný a dobře napsaný, ale tvrdit, že kdo používá LIKE je principiálně lempl, což z článku tak trochu vyplývá, to mi nepříjde OK...

Clanek preci nerika, ze LIKE je spatny? Já bych řekl, že říká.

...tvrdím, že programátor, který použije LIKE, si koleduje o to nebýt programátorem...
Z mého pohledu operátor LIKE podporuje šlendrián v programování...
...SQL tomu jakoby samo nahrává - obsahuje datový typ varchar (případně text) a operátor LIKE...
Dovolím si předpokládat, že bez operátoru LIKE by se o toto uživatel nesnažil....

Clanek jsme tedy asi stejny cetli. Ted jeste ho stejne pochopit a nehledat v tom za kazdou cenu neco, co v nem neni.

Tak ja tedy nevim, ale i na mnoho dalsich clenek zapusobil dojmem, ze autor zcela a uplne odmita operator LIKE a kazdeho, kdo ho pouzije, dava do klatby :-)

Rád bych se Vás zeptal na řešení následujícího problému: Na serveru je databáze popisů výrobků, hezky zindexovaná, hodnota ft_min_word_len nastavena na klasickou 4... Správce je trochu paranoidní a tak máte SQL účet s právy, které Vám nedovolí úpravy databáze. Vy jakožto programátor máte udělat jednoduché vyhledávání v textu těch popisů, fulltext se pro to krásně hodí, stačí jeden match .... against dotaz a je vymalováno. Ale co když příjdu já a začnu hledat výrazy OKI, LG, AEG, RAM, pošlete mě do jiného e-shopu? Netvrdím, že like není nadužíváno, rozhodně je, ale ne vždy je jiné elegantní řešení a to že ho občas někdo použije neznamená, že neumí programovat nebo kašle na to, co dělá. Nebo byste toto nějak vyřešil bez like? Pokud ano, tak jste borec. :-)

kde nic není ani smrt nebere. Pak Vám nic jiného nezbyde.

Co bych udělal? Použil třeba tsearch2? ;-)

No, paranoia je v případě adminů spíš dobrá vlastnost ;-) A na příliš paranoidní adminy kteří si myslí že kolem nich se svět točí většinou platí management, tj. jděte za businessákem, prezentujte mu problém (Strašný průser! Když budu hledat "LG" tak mi to vůbec nic nenajde! Miliónové ztráty! Nebude na nové Porsche! Ale věděl bych jak to opravit!)

No a pak buď můžete nasadit tsearch2 s lepšími parametry, vytvořit nějaký alternativní fulltext (sám jsem jeden takový dělal, včetně podpory pro skloňování/časování apod. a není to až tak hrozné), a nebo použít něco mimo DB (například Lucene).

Prozradil by pan autor, mistr databáze, mně, pouhému šlendriánskému neprogramátorovi, říci, co je špatné na tom, když uživatel chce např. přes webový formulář najít v tabulce článků o programování všechny, které obsahují třeba slovo 'volatile' nebo třeba podřetězec 'like je na', a co je špatné na tom, když se na to použije LIKE, a jak by to bez LIKE napsal mistr databáze?

fulltext search? nevim, ale pokud by treba Root skutecne vyhledaval ve vsech clancich pomoci operatoru LIKE, asi bysme se vysledku nedobrali :-(

A propo: treba by nam to mohli prozradil sami tvurci Roota, jak je resene vyhledavani

ale dobrali. Root ma pocet clanku limutujicich k nule, to by projelo LIKE jedna dve. Krom toho taky lidi tu moc casto asi nevyhledavaji ja tu nevyhledavam ani 1x za mesic.

Přesně od toho je fulltext. Zkuste např. v 3G databázi mailů včetně attachmentů vyhledávat LIKEm. Uživatel může jít na kafe, a skoro totéž mohou udělat všichni ostatní uživatelé daného systému. A to i v express databázi jako je MySQL. Špatné je na tom to, že se sekvenčně čte velká tabulka, což má za následek zahlcení IO, druhak přepíše Vám to obsah cache, a do třetice - pokud se nepoužije sofistikovanější algoritmus a prohledávají se delší texty, tak to utluče i procesor.

v inteligentnich db vam to cache nezahlti ponevadz pokud je velikost tabulky vyrazne vetsi nez velikost buffer cache, tak se jede tablescan nocache prefetch. Podivejte se na execution plan co leze z Oracle nebo db2.

A co kdyz vim, ze v tabulce bude maximalne nekolik desitek zaznamu a text bude dlouhy maximalne nekolik set znaku. To mi taky zahlti IO a utluce procesor? ;-)

tam pak výsledek bude stejný - planner použije sekvenční čtení. Rozdíly začnou být nad 1000 řádků, markantní pak nad 10000 řádků. Pokud mám malý úzký číselník, tak pak bez problémů (pokud nepoužijete ilike).

Ale ja se neptal, jestli se pouzije sekvencni cteni, ale jestli se zahlti IO a CPU.

Takze chcete rict, ze i kdyz mam maly uzky ciselnik (viz moje specifikace vyse), ze pouziti LIKE zahlti IO a CPU??? Nebo je v tomto pripade jeho pouziti bezproblemove?

Odpověděl jsem Vám - planner zvolí sekvenční čtení - z toho plyne stejná zátěž IO a +/- stejná zátěž CPU. Na krátkém řetězci LIKE nebude ani v nejhorším případě extrémně náročný, nicméně porovnávají se řetězce, na druhé straně fulltext bude mít určitou režii s tokenizací, převodem na lexémy, ale pak se porovnávají pouze celá čísla.

PostgreSQL 8.4 umí fultext i na prefixech. Což má pak ještě jednu výhodu. Nevím jestli sledujete stanici Leonardo. Jeden z jejich autorů má příjmení Hora Hořejší. Pak Like 'Hoř%' by Vám nepomohl - uznávám, že se jedná o výjimku. Spíš to uvádím jako ukázku rozvijejících se možností fulltextu, který LIKE částečně eliminuje.

Občas je nutné kombinovat fulltext a LIKE. Fulltext má vyšší selektivitu a pak na vybranou množinu se jako filtr aplikuje LIKE. Pak je to košer.

Vzpomněl jsem si ještě na jeden odstrašující případ. V případě, že máte dohledat například kombinaci tří slov - X, Y, Z .. uživatel do vyhledávacího políčka napíše Praha Soukenicka Smlouva. Takové ty univerzální vyhledávací generující dialogy vyrobí dotaz typu

WHERE
subject ILIKE '%Praha%' AND subject ILIKE '%Soukenicka%' AND subject ILIKE '%Smlouva%' AND body ILIKE '%Praha%' AND body ILIKE '%Soukenicka%' AND body ILIKE '%Smlouva%'

Vidíte problém?

Taky poslouchám Leonardo, je to príma rádio!
:)

zajimalo by me (ze statistickych duvodu) jak velka firma, co dela a jake je to tabulka, co ma 20 M zaznamu.

cca 300 lidí cca 10 let archiv, poradenství

beru zpět, odpověď na otázku někomu jinému.

„Zkuste např. v 3G databázi mailů včetně attachmentů vyhledávat LIKEm. Uživatel může jít na kafe“
Soudě podle rychlosti, toto řešení použili v MS Outlooku :-D A to ta schránka měla nějakých ubohých pár set mega, žádné gigabajty :-)

...a napsat špatné program...

Zato články píše kvalitné. A nebo je z Moravé :-)

Článek je psán z pohledu kodéra. (To, že se kodér považuje za mistra světa a všechny ostatní považuje za blbce, to je konstanta. To není potřeba vyzdvihovat, takoví jsou všichni.) Kodér neuvažuje nad potřebami uživatele. Kodér neuvažuje nad ekonomií projektu. Kodér neuvažuje nad skutečným fungováním velké firmy, jak dodavatelské tak zákaznické.

Zazlívat systému, že si v něm uživatel udělá víc, nežli bylo původně navrženo ... je krátkozraké. Uživatel potřebuje víc. Udělat to "správně" znamená: vytvořit požadavek; obhájit business case pro přidělení rozpočtu; vyžádat si od dodavatele cenovou nabídku; znovu obhájit business case; zadat dodavateli; počkat na příští řádné doručení. Tohle trvá asi tak rok. A stojí to hodně peněz.

Pokud uživatel na druhou stranu může "zneužít" systém a udělat si tam, co potřebuje, bývá to výhodnější. Stojí to jen nový hardware, at to jen v nejhorším případě (a navíc nákup hardware bývá snadnější - problém výkonnosti je viditelnější a investice se snadněji schvaluje).

presne z takovych duvodu existuji cela ucetnictvi v excelu. Na prvni pohled je to vyhodnejsi. Z dlouhodobeho hlediska je to nesmysl. Ale mate zcela presne pravdu, ty procedury pro to, aby se to udelalo spravne se tahnou.

Ulohou managementu je hledat cesty, jak to udelat spravne. Tim, ze se orazitkuje pan Stehule jako koder, ktery ma svuj uzky zorny uhel se nic nevyresi. Uvaha pana Stehuleho je tu prave take pro ten management, aby si tito zodpovedni dali 2 a 2 dohromady a zeptali se, jestli je koupe hardware skutecne levnejsi.

Pan Werich se v jednom ze svých velkolepých filmů (Byl jednou jeden král) vyjádřil takto: "Teď už vím,co jsem dříve nevěděl. Že totiž na odbornou práci musí být odborníci."

Článek není psán z pohledu kodéra, protože návrh vhodných datových struktur (o který jde především) je záležitostí analytickou, nikoliv kodérskou. Wirthovo tvrzení, že program=datové struktury+algoritmy platí stále. Databáze značnou část algoritmů sice řeší za nás ale na správném návrhu datových struktur záleží o to více. Pokud dodržíme doporučení autora na správnou atomizaci a normální formy, pak není problém splnit dostatečně efektivně i takové požadavky zákazníků, se kterými původně počítáno nebylo a navíc lze databázi snadno rozvíjet. (O tom jsem se přesvědčil mnohokrát).

Problém nastává, když zákazník začne do sloupců ukládat jiné informace než tam patří, protože je to "levnější", než jeden sloupec přidat. Takový zákazník JE blbec! Znám případ, kdy do čísla střediska (které nevím proč mělo rozsah až 16 míst) zamontoval zákazník jakýsi typ materiálu a číslo odpovědné osoby a pak si ztěžoval na nečitelnost sestav. Jistě, bylo to levnější, než požádat o přidání dvou slouců ale současně velmi krátkozraké.

A pokud případné změny prosazujete tak, jak píšete, pak musíte být velice těžkopádnou organizací. (Přitom se vsadím, že nakoupit řediteli repre bourák za x melounů je u vás záležitostí pěti minut).

No, pokud zakaznik ke konci vyvoje prijde se zmenou arity vztahu, tak to byva problem :-) Ale jinak souhlasim, kvalitne provedena analyza - dobre zobrazena realita v datovem modelu hodne pomaha.

Takovy postup zmen je bezny v kazde vetsi / velke organizaci. A ono by to asi i jinak neslo. Ani nakup bouraku pro reditele tam neni zalezitosti peti minut :-)

Ja to znam z druhe stranu a pro zmenu obcas dostanu chutovku - nacenit nejakou zmenu, u ktere 80% pracnosti predstavuje analyza problemu, ale bez analyzy neni mozne rict, jak dlouho to bude trvat :-D