Názory k článku Využití databázových indexů
-
Článek je starý, nové názory již nelze přidávat.
-
Abraxis (neregistrovaný)
Ukladam log ze squidu do PostgreSQL a za mesic ma tabulka 200 000 zaznamu (firma s 10 aktivnimi pocitaci)... Jeste nemam napsanou aplikaci na vyhodnoceni dat (kolik uzivatel stravil denne na internetu a na cem nejvic casu apod.), ale jsem zvedavy, jak to bude rychle - nemate nekdo podobne zkusenosti, jak resit takovehle udesne tabulky? (za rok to bude 1.5 milionu zaznamu - to nemuze preci SQL zvladnout v tom rozumne(!) vyhledavat - nebo se mylim?)
-
Vita (neregistrovaný)
No ten komentar nebyl treba, pri jedne tabulce bych na oracle nevsadil ani petnik ze to dokazes projit rychleji nez mysql. Jo, u slozitejsich spojeni by oracle jednoznacne vyhral ale s takovymi jednoduchymi malickostmi jako je tohle je mysql bezkonkurencni.
To je jen zazite ze si clovek rika ze milion je velke cislo - pritom to neni prakticky nic. -
puk (neregistrovaný)
no zalezi od konkretneho pouzita.
ale viem ti dat priklad tabulky, ktora bude v mysql nepouzitelne pomala (vzdy to bude full table scan aj keby si spravil akykolvek index) a v oracle bude bleskova - pri pouziti rovnakeho SELECTu
staci vhodne zvolit IOT a mysql, postgres, mssql a hocico co nema IOT sa moze strcit ;) - z praxe som videl to zrychlenie ked oracle 8.0.5 IOT nemal a potom v 9.2.0 kde je IOU full supported -
binary_runner (neregistrovaný)
Polozil bych si otazku, jestli opravdu vsechny ty zaznamy potrebuju nebo jestli je alespon potrebuju v jedne databazi/tabulce. Pozadovane sumacni udaje bych jednou za mesic z dat vytahnul, ulozil do separatni databaze a podrobna data odsunul pryc.
Sumacni udaje lze vytvaret i prubezne pomoci aplikacni logiky v databazi (ulozene procedury, triggery,...). -
Martin (neregistrovaný)
Aplikaci na zpracovani logu SQUIDU jsme vyvijeli. Pravda dela spoustu jinych veci nez jen off-line
prehledy (ex-post), ale ze zkusenosti lze jen doporucit pouziti neceho jineho nez PostgreSQL. Vzhledem k tomu, ze se uz z principu nejedna o transakcni zpracovani, tak zkuste treba MYSQL (bez transakci) je radove rychlejsi pro ucel, na ktery to potrebujete.
Jinak pro SQL jako jazyk to neni zadny problem.
Jen na okraj - jsem velkym priznivcem PostgreSQL a
MYSQL s nim nelze srovnavat, ale pro tento ucel se
MYSQL hodi opravdu lepe. -
bigsam (neregistrovaný)
Nezalezi ani tak na "objemu dat" ale na optimalizaci ulozeni dat a na spravnem chovani k SQL engine. Muzu vas ubezpecit ze 1.5mil zaznamu je prd do stromovky. Zalezi tez na zeleze na kterem to honite (SMP system,RAM, Disky ?). Chce to vyuzit vlastnosti DB jako cluster index, bitmap indexy apod. Ne kazda SQL DB toto umi. Clovek dosahne nejlepsiho vykonu pokud nejde proti srsti SQL enginu. Nejlepe je si neco nacist o fungovani toho ci onoho engine a pak k nemu podle toho pristupovat. Napr. Oracle versus hinty a dobre napsany SQL statement muze udelat vysledek kde rozdil je v stovkach sekund. I na tabulkach kde je ulozeno cca 60 milionu zaznamu lze pres index dosahhnout radove nekolika ms pro pristup pres index. Jinak diky autorovi clanek je lehce napsan a pro lidi kteri nevedi o cem je rec je dosti ctivy.
-
Michal Kara (neregistrovaný)
Jak to vypada tak uz nic dalsiho na toto tema nebude nasledovat :-) Takze doplnim jeste jednu vec, kterou povazuji za podstatnou:
MySQL umoznuje u textovych poli udelat index pouze na cast retecze - priklad z manualu:
CREATE INDEX part_of_name ON customer (name(10));
Vytvori index na prvnich deset znaku jmena zakaznika. To by se mohlo hodit pri zpracovavani logu squida vyse. Index pak nebude tak velky a nebudete v problemech, ze mate datovy soubor par set mega a indexovy nekolik giga :-)
Ale jinak ladeni vykonu MySQL je take docela veda, protoze je tam docela dost parametru, ktere ho mohou v ruzne mire ovlivnovat. Pokud by byl zajem, muzu o tom casem neco napsat. Nebo nekdo jiny... -
Matouš Červenka (neregistrovaný)
omlouvam se za dotaz "mimo misu" ale potreboval bych poradit.... Potrebuji nejaky free databzovy system, ktery obsahuje SQL-92 paletu prikazu. Zatim jsem zkousel mysql ale to je strasny smejd, ktery neumi napr. create view a celou radu jinych standardu. idealni by bylo, kdyby to bylo free, slo to nainstalit pod windows NT a melo to i nejake GUI.....
-
Plysak (neregistrovaný)
Ad 1) MySQL neni smejd, je to lehky SQL engine, ktery je pravdepodobne urcen k jinym ucelum nez potrebujete ale rozhodne kvuli tomu neni smejd. Ma chyby, ma slabiny, ale ktery SW je nema.
Ad 2) Prima databazi pod NT s GUI dela M$ a urcite je to clickaci a barevny, tak jak potrebujete... Akorat to neni zadara a to je dobre, jen at si Widlaci priplatej...:) -
borgman (neregistrovaný)
ad mysql souhlasim
ad bod 2), je to zase jednostrane zamerena reakce, ale co cekat. proc lidi musi byt natolik ubozi, aby nedokazali priznat kazdemu co jeho jest, nebo alespon nekecat o vecech o kterych nic nevi.
pod nt je k dispozici odlehcena verze sql serveru, zvana msde, ke stazeni ruzne po netu. zbezne vim ze se treba nesmi pouzit k vyrobe neceho co by bylo konkureceschopne accesu (protoze novej access bude bezet nad msde), ale myslim ze je jinak volne k pouziti (precist licenci).
bohuzel k tomu nejsou pridany gui ovladaci nastroje, jinak dostupny k ms sql serveru (mimochodem podle me celkem dost dobry), nicmene pokud nekde mate sql server, tak ty nastroje funguji i na msde. taky se na netu vali free aplikace pro spravu MS SQL/MSDE databazi psany v asp.net.
jinak samosrejme postgres bezi pod nt taky, svyho casu SAP (eeeeee) uvolnil nejaky svuj DB stroj volne k dispozici (verze 7.neco).
ale jinak je to v pohode, hlawne ze widlaci i lidi co pouzivaji oba systemy platit nemusi !!!
PS: jeste jsem nevidel pouzitelny free/oss gui k mysql/postgres. nelze se tedy divit, ze nekteri jedinci radsi gui zatrati, protoze se jim nevyplati s nim delat, a kdyz neni kvaliti free/OSS gui, pak ty komercni prece musi byt shity taky, proc na ne teda nehazet spinu, ze panove ? pokud nekdo o dobrem gui manageru treba pro mysql/postgres slysel, rad si to prohlednu. -
Miloslav Ponkrác (neregistrovaný)
Free GUI k MySQL je několik. Nejdříve jsem používal MysqlWinAdmin, dnes používám SQLyog a ten je opravdu perfektní. A jeho funkce jsou tak vyspělé, že je o dost víc, než jen manažer. A někdy taky pro jednoduché sázení a editace výsledků SQL dotazů používám IMySQL. Samozřejmě existují i weboví správci, jako phpMyAdmin, ale já ho nepoužívám, nemusím-li. Binárka je pro mě vždy lepší.
Nutno říci, že výrobce MySQL propaguje na svém webu takové hnusné shity, co vydává za perfektní grafické rozhraní pro MySQL, že se ani nedivím povzdechu toho člověka nade mnou. Někdy mám pocit, že u některých grafických programů standardně propagovaných přímo výrobcem MySQL ten člověk se právě učí programovat. Ale nic, alespoň jsem si ulevil. -
Michal Kara (neregistrovaný)
<sarkasmus>On existuje nejaky DB system, ktery PLNE implementuje SQL 92? :-)))</sarkasmus>
Pokud potrebujete tyto vychytavky, zkuste Postgres. MySQL je spis vhodne jako "sklad dat s prvky SQL databaze" nez jako platforma ktera by mohla konkurovat moznostem napr Oracle. Neimplementuje spoustu veci (treba subselecty jsou teprve az v alfa verzi 4.1 :-( ), ale zato je hodne rychla. -
Jerry (bez trojky) (neregistrovaný)
Pro web to použít jde, např. na W2K3 Server Web Edition nic jinéno než MSDE nenarvete. :-(
Co se týče omezení - není to 5 connection, nýbrž 5 paralelně zpracovávaných úloh (ostatní čekají ve frontě), max. velikost jedné databáze je tuším že 2GB, není tam možnost fulltext indexů a nemá to GUI (čili ovládání jedině přes SQL dotazy, nebo přes nástroj třetí strany, popř. použít administrační konzoli z plného SQL serveru - samozřejmě o tom nesmí vědět ochránci autorských práv ;-)... Ale třeba právě pro malý webový (pokud nepotřebujete ten fulltext) je MSDE pod Win32 platformou výborná. Plný výčet vlastností by měl být někde na webu MS, stáhnout se nechá např. z http://www.asp.net/webmatrix/download.aspx?tabindex=4 -
PaJaSoft (neregistrovaný)
Dovolil bych si jen poznamenat, ze zadny ANSI SQL/95 neexistuje, zrejme mate na mysli neco ala SQL3, ANSI SQL/97 (take neexistujici, protoze se to nestihlo) apod., jedine co se stihlo jsou ruzne mezi-veci (treba v roce 1996)...
Jinak koukam, ze lidi maji docela hokej v tom, co ktere ANSI SQL obsahuje, ze treba existuje Entry level apod... vzhledem k tomu, ze to bylo soucasti me diplomky a v podstate na toto tema jsem mel pripraveny clanek pro Roota (asi tak pred 2 lety) - nakonec jsem to nedokoncil - mozna by stalo za to to dopsat, pripadne prijit s kuzi na trh a ostatni by mohli mit pripominky, takze bychom se nakonec dobrali pravdy.
Roote mas zajem?
PS: Vyvoj by vsak byl tak do roku 1998/9, novejsi veci jsem prestal sledovat, prakticky je nikdo stejne nema implementovane nebo ma, ale firemne (shodou okolnosti to protlacil dal:-)) -
Michal Kubeček (neregistrovaný)
Jiný způsob řešení konfliktů mezi transakcemi. Zjednodušeně řečeno: místo zamykání záznamů (nebo celých tabulek) si od každého záznamu evidujete více "verzí" (generací), při commitu smažete ty staré (pokud už je nikdo nepotřebuje), při rollbacku tu novou. Podrobnější vysvětlení viz např. http://www.dbsvet.cz/technologie/tc011102021101.html
-
sasa (neregistrovaný)
Chtel bych doplnit informaci ohledne malohodnotovych atributu a jejich indexace. Pokud podle malohodnotoveho atributu budete vyhledavat, neprinese indexace tohoto atributu zadne zrychleni. Pro takove atributy umi nektere databaze (Oracle) vytvaret "binarni" indexy.
Dalsi poznamka se tyka pouzivani prikazu select a rychlosti odezvy. I presto, ze budete mit zvolene dobre indexy, vyhnete se pouzivani vnorenych selektu. Zpomaleni neni citelne na ucebnicovem prikladu, ale na databazi s mnoha set zaznamy obzvalste pri spojeni vice tabulek. Podobna poznamka plati pro rozsahle where podminky s operatorem "or" nad vice tabulkami.
Dalsi poznamka se tyka tabulek, kde je index nad vetsinou atributu. Napriklad tabulka obsahuje ctyri atibuty: tri ideca (cizi klice) a jednu hodnotovy atribut. Pokud se k tabulce pritupuje zaroven s omezenim na vsechny tri cizi klice, je zbytecne po nalezeni zaznamu v indexu jit pro hodnotu do tabulky. K urychleni pritupu k takovym tabulkam exituji specelni struktury (v Oracle se jmenuji "index table") uchovavajici hodnotu primo v klici.
Posledni poznamka je navrhem na problem s databazi squid logu. Prochazeni milionu zaznamu bude pochopitelne pomalejsi nez select nad desitkami zaznamu. Proto se nabizi pouziti datoveho skladu a z primaprni tabulky podle zamyslenych statistik vysumovat data do nove vytvorene tabulky (tabulek). Tato operace se da presunout na nocni hodiny a bezne denni prochazeni a statistiky jsou pak mnohonasobne rychlejsi. -
roman (neregistrovaný)
Nejedna se o binarni, ale o bitmapove indexy.
Ad "index table": Normalni tabulky se ukladaji jako heap, tj. nejsou setridene a pro urychleni vyhledavani je nutne vytvorit indexy nebo partitions. Pokud se vsak k datum v tabulce bude primarne pristupovat pres primarni klic a tabulka se prilis casto neaktualizuje, je vhodne ji rovnou reprezentovat ve forme indexu, tj. setridene podle primarniho klice. Tato representace ma vsak i dost nevyhod a osobne jsem nezjistil ze by byla nejak fantasticky rychlejsi nezli kombinace table+index. Samozrejme prinasi vyraznou usporu mista zejmena pro cross referenci mezi dvema tabulkami (mapovani n x m ).
Ad datawarehouse: S uspechem lze pouzit partitioning bez nutnosti mit specializovanou databazi. -
Jan Majlath (neregistrovaný)
Este by som doplnil moznost odporucit databazovemu serveru akym sposobom ma narabat s udajmi. Syntax je: /*+ hint */
Pricom takychto hintov su (aspon v db Oracle) desiatky.
Napr. pre odporucenie indexu pri selecte je syntax:
SELECT /*+ INDEX ( table [index [index]...] ) */
... -
mato (neregistrovaný)
1) a ako teda napisat select nad viacerymi tabulkami bez pouzitia "rozsiahlych" where podmienok a/alebo vnorenych selektov?
2) btw vsetky index(y/i?:) v oracle uchovavaju hodnotu atributu ("priamo v kluci"). index organised tables 'len' zabranuju zbytocnej duplikacii dat a s tym spojenej rezii.
3) tie indexy su bitmapove nie "binarne" -
venca trotl (neregistrovaný)
autor pise :
Databázové indexy slouží ke zrychlení přístupu k datům a měly by se používat u všech sloupců, podle kterých se vyhledává, třídí nebo podle kterých se spojují tabulky.
mysli se tim i ze by mel byt index na sloupci na nemz typicky dotaz ma selektivitu rekneme 80 % ??? To asi ne, ze pane autore... Vememe li v uvahu ze pristup na rekord pres index je 4x pomalejsi nez pristup primo (napr pri fullscanu) a dal ze indexy zpomaluji update a insert operace, zvysuji naroky na misto apod.. meli bychom rici ze indexy nemuzeme mastit bezhlave jak nas napadne ale na sloupce kde se to vyplati z hlediska dotazu ktere budeme provadet. Flaknu to vod voka rekneme kde selektivita bude do dvaceti procent
ad free SQL urcite doporucim PostgreSQL, nejenom z duvodu ze jednim z vyvojaru je Pavel Zak (napr prepared statements nemylim-li se) ale hlavne proto ze v nem najdete temer vsechno co potrebujete, zvlada poradny objemy dat a ma i nejakej svinsky hezkej gui tool jen si nemuzu vzpomenout jak se jmenuje (nepouzivam ho) napsanej nad WXWindows toolkitem takze jede na stomilionech platforem, myslim pgadmin nebo tak nejak, v mailing listech postgresu je vo nem zminka.
SQL wraperem nad souborovou databazi (cti MySQL) bych se vubec nezabejval. Hracky patri detem. -
Miloslav Ponkrác (neregistrovaný)
Ono je škoda, že autor vysvětluje napůl MySQL, místo aby šel jen po indexech. Mimochodem, nesouhlasím s názory na nezabývání se MySQL, protože má svůj účel a je velmi mnoho situací, kde slouží velmi dobře. MySQL nemusí být souborová databáze, taková je pouze, kdy tvoříte tabulky typu "MyISAM", jinak pracuje se segmenty na disku jako jiné transakční databáze. Ale jinak jsem si všiml, že zastánci Postgresu jsou vyjímečně vysazení na MySQL.
Nicméně v indexech se používá pravidlo 20%, tj. pokud index slouží k vyhledání méně, než 20% řádků tabulky, je rozhodně efektivní. U rozsáhlých tabulek je to zase trochu jinak. Osobně se ale domnívám, že prostě potřeba uvážit poměr frekvence použití indexu / zápis. A i to není dokonalé, chce to trochu citu. Zkrátka indexy zpomalují zápis a za určitých situací mohou urychlit čtení, či vyhledání subsetu dat pro úpravy.
Pokud je index používán třeba jen jednou za měsíc, u velkých databází může být výhodné ho těsně před použitím vytvořit a zase po použití dropnout. Atd.. -
Jakub Vrána (neregistrovaný)
To, že by se indexy měly používat uváženě, je dobrá připomínka a v článku by to mělo být zmíněno. Např. MySQL ale indexy nepoužívá v případě, kdy je potřeba sáhnout na víc než 30% řádek, takže ke zpomalení SELECTu nedojde (ke zpomalení INSERTu však samozřejmě ano). Věřím, že i "chytřejší" databáze budou podobné strategie používat.
Použití indexů i nad sloupci s malým rozptylem má však význam, pokud omezujeme velikost výstupu pomocí LIMIT. -
Jan Kotek (neregistrovaný)
Pouzivaji. Optimalizator databaze obecne by mel vzit do uvahy SQL dotaz, databazove schema (kde jsou jake indexy), aktualni obsah pameti (data v cache) a samozrejme take statistiky o datech (pocet radku, selekcni sila...).
A pote rozhodnout jak postupne zpracovat dotaz, ktere indexy pouzit, jak cist data (treba udelat ten table scan), jak je zamykat... -
roman (neregistrovaný)
Optimalizator dotazu je obecne straslive slozita vec. Abyste mohl dopredu rici, ze dotaz pujde po vice nez 30% radku, museli byste mit detailni histogramy. Pro velke tabulky (miliony a vice radku) je to problem, protoze distinct hodnot byva zpravidla desetitisice a vice. Navic histogramy je nutne udrzovat, coz pri vice nez jedne paralelni session pracujici s tabulkou by vyzadovalo neustale soupereni o systemove resources nebo tak jak to dela Oracle, je nutne histogramy a statistiky cas od casu refreshnout.
Dotazy, ktere jsem potreboval optimalizovat jsem vzdycky musel opatrit hinty, nebot databaze neni schopna dotaz vzdy korektne optimalizovat. Delam na Oraclu, ale jinde to bude zrejme to same, nebot princip je ten samy, pouze mnozstvi investovane prace a penez je jine. -
ben20uk (neregistrovaný)
Dobry den, mam trochu offtopic dotaz, ale neni kam se jinam obratit... Nevite prosim o robusnim fulltextu, ktery by zvladal rychle praci s asi 0.5 mil textovych souboru, booleovske op., near, vyhledavani v ruznych polich atd.. popr. vektorove prohledavani (vazeni termu)? Musi mit perfektne zvladnute vyhledavani v ceskem textu, lematizaci (truncation), popr. gramaticky slovnik na doplnovani ostatnich tvaru slov.
Nemam 100% predstavu, kolik takovz soft stoji, ale proto se ptam. Preferuji hlavne levne nabidky, ale za jakykoliv tip na komercni nabidku budu vdecny. (Pokud snad nekde existuje nejaky srovnavaci clanek, tak rovnez...) Dikz moc. -
Jan Kotek (neregistrovaný)
Napadaji mne Autonomy nebo Verity. Prvne jemnovany pouziva obsahoveho vyhledavani pomoci AI, ktere je nezavisle na pouzitem jazyce a dava vysoce presne vysledky.
Verity pak pouziva semantickych stromu a ma podporu cestiny od firmy Tovek.
V obou pripadech jde ale o ceny v radu statisicu. -
Jerry (bez trojky) (neregistrovaný)
Fulltext pod PostgreSQL jsem zkoumal loni, tehdy jsem našel dvě věci, obě si dělaly do separátní tabulky seznam slov vázaný na původní záznamy. Čili spíš šidítko než fulltext. Možná už vymyslel někdo něco lepšího, ale pokud ne, tak bohužel v tomto směru není PostgreSQL to pravé ořechové, to už radši MySQL - ale to ho zase umí jen u MyISAM databází, které pro změnu nezvládají třeba transakce. To pak má občas člověk chuť řvát a mlátit hlavičkou o zeď...:-(
-
platYpus (neregistrovaný)
Fulltextové (plnotextové) databáze:
ConText CZ
producent: Sefira, spol. s r. o., Česká republika
Lokalizace a rozšíření funkčnosti modulu Oracle Context Cartridge (interMedia Text) o práci s českými a slovenskými texty.
Excalibur
producent: Excalibur Technologies
zastoupení v ČR: INCAD, spol. s r. o.
SuperText
producent: 5D software, spol. s r. o.
TexPro
producent: Fulcrum - Exprit, spol. s r. o.
zastoupení v ČR: Exprit, spol. s r. o.
Verity K2, TOPIC
producent: Verity, Inc.
WAIS -
kavol (neregistrovaný)
jak to tady ctu, napada me takovy hloupoucky dotaz - mohl by prosim nekdo udelat strucne porovnani MySQL/Postgres/Firebird a janevimco jeste je ted v soucasnosti "in"?
nemyslim nic ve stylu "ktera databaze na jakem selectu usetri milisekundu", toho se po webu vali tuny, ale spis nejaka doporuceni pro zacatecnika, co si ma pro sve ucely nainstalovat a nadale se s tim trapit (nezli zkouset kazdy tyden neco noveho) ...
momentalne si na svem webiku hraju s MySQL, staci mi, ale cervicek pochybnosti vrta - zvolil jsem spravne, nemam prejit jinam driv, nez by se stal prechod prilis slozitym? -
jezovec (neregistrovaný)
No, porovnání tu nenapíšu, ale možná by vám pomohla moje zkušenost.
Já jsem s něčím na způsob databazí začínal u Paradoxu/BDE (to jen pro úplnost), pak jsem několik let programoval s Oracle, Sybase a MSSQL (tedy "velké databáze") a teď už dva roky skoro výhradně v Postgresu. S MySQL mám zkušenost jenom uživatelskou (instaloval jsem některé programy, které MySQL používají). Firebird neznám.
Z tohoto pohledu doporučuji Postgres. Zejména, pokud se chcete databázovým programováním zabývat do větší hloubky. Na Postgresu si můžete vyzkoušet víceméně všechny prvky 'velkých' databází, velkým plus je také výborná dokumentace která uvádí nejen do vlastní databáze, ale i do databázového programování vůbec. -
venca trotl (neregistrovaný)
no pokud potrebujete triggery, ulozene procedury, vlastni agregacni funkce, schemata, referencni integritu (i kdyz mozna to uz i mysql ma) a ja nevim co si este ted vzpomenout a nechcete delat tricet updatu nebo insertu za vterinu.... doporucim jako velky fanda postgresu prekvapive postgres.
pokud tyto veci nepotrebujete (coz je pripad databazi tak odhaduji o peti mozna deseti tabulkach tabulkach) tak je mozne si vzit na to mysql.
ale jak uz me tu nekdo vodhalil priznavam ze ja sem fakt vysazenej proti mysql takze muj nazor vubec nemusi bejt objektivni. -
binary_runner (neregistrovaný)
PostgreSQL, velice slusna podpora standardu, databaze je skutecne relacni (MySQL neni) a podporuje veci jako referencni integrita, jejichz absence cini z vetsiny projektu presahujicich 3-4 tabulky peklo.
Ostatne pokud vim, tak starsi verze se stala zakladem minimalne dvou komercnich databazi( PostgreSQL -> Sybase -> MS SQL), takze spatna volba to aasi nebude.
PostgreSQL ma take nektere unikatni nebo nebovykle rysy, ktere mohou v konkretni situaci usetrit dny prace. -
jezovec (neregistrovaný)
To, že se uživatel / začínající vývojář (pokud dobře rozumím původnímu dotazu) naučí pracovat s relační databází - tj. s něco pak použije u kterékoliv jiné relační databáze.
V případě MySQL se naučí pracovat s MySQL.
Já bych, při vědomí toho že na něco se jistě MySQL výborně hodí, doporučil to prvé, protože to otevírá daleko širší obzory - a nezavírá cestu ani k MySQL, když bude potřeba... -
Miloslav Ponkrác (neregistrovaný)
Jakékoli porovnání je Vám k ničemu. Výběr databáze záleží tvrdě na tom, co chcete dělat, a za jakých podmínek to chcete dělat. Najdou se situace, kdy MySQL bude nejlepší, jindy zase Postgres a jindy zase Firebird a jindy ...
MySQL - jednoduchá, rychlá, škálovatelná, nenáročná, běží i na slabých strojích, optimalizovaná pro web. Na druhé straně je ořezaná o věci, které rychlostně zdržují. Má i transakce a referenční integritu, přestože řada lidí zde bude tvrdit opak.
Postgres - open source databáze, která má procedury, triggery a jiné serepetičky, co se požaduje po větších databázích.
Firebird - klon Borlandovské databáze Interbase, v zásadě dobrá a nenáročná databáze
-
dnc (neregistrovaný)
V zasade souhlasim.
Asi vsak patrim mezi radu lidi, kteri budou tvrdit,
ze s ref.integritou je to u MySQL ponekud osemetne.
Aktualni (stabilni) verze dle http://www.mysql.com/downloads/index.html
je 4.0. Verze ve ktere ma byt implementovan
FOREIGN KEY - 5.1. Tedy vzdalenejsi budoucnost.
Na druhou stranu pokud napr. chcete provozovat free
web site, pocet poskytovatelu, ktery vam nabidnou
X MB prostoru na disku + Y mista pro MySQL je pomerne velky. Obavam se ze totez rozhodne neplati
pro PostgeSQL ci Firebird. Ale rad se necham vyvest
z omylu ;-) -
Miloslav Ponkrác (neregistrovaný)
Stačí Vám toto?:
"In MySQL Version 3.23.44 or later, InnoDB tables support checking of foreign key constraints."
Mimochodem, dnes je je aktuální verze 4.0.x. Tedy už dost dlouhá minulost. Naprosto nechápu, kde jste přišel na tu 5.1. Klidně si samozřejmě můžete patřit lidi, kteří "vždycky budou tvrdit" cokoli, byť se to třeba nezakládá na pravdě.
To je prostě základní problém, většina lidí prostě říká, že MySQL nemá to, či ono, že je špatná, protože, a pokud to srovnáte s realitou, jsou to z takových 95% výmysly lidí, kteří o MySQL nic nevědí. Sorry.
MySQL má své určení, a je to jak říkáte, hlavně webová databáze a nebo malá databáze pro Vaší aplikaci. Můžete si klidně nahrát sdílenou knihovnu (DLL nebo so) k aplikaci a pracovat s daty. A díky konstrukci databáze MySQL si můžete být jistí, že práce s daty bude velmi komfortní, a přitom nebudete potřebovat hafo megabajtů paměti a nejnovější procesor. I to je třeba výhoda MySQL. Samozřejmě MySQL je také klasika pro web. MySQL je dobrá pro rozsáhlá data s jednoduchou strukturou, a pokud možno s převahou čtení.
Sám nasazuji MySQL omezeně, ale když jí nasadím, nasadím jí tam, kde se projeví její kladné stránky. A pak si lebedím. A samozřejmě nejsem blázen, a nestavím třeba nad MySQL žádné účetní systémy, apod.. -
dnc (neregistrovaný)
>In MySQL Version 3.23.44 or later, InnoDB tables
>support checking of foreign key constraints."
>...
>Naprosto nechápu, kde jste přišel na tu 5.1
Viz
http://www.mysql.com/doc/en/TODO_MySQL_5.1.html
1.9.3 New Features Planned For 5.1
FOREIGN KEY support for all table types.
Jinak nevim, proc jste nasadil tak konfrontacni
ton:
> jsou to z takových 95% výmysly lidí, kteří o
> MySQL nic nevědí
Nerikam, ze o MySQL toho vim hodne, ale neco snad
po dvoulete zkusenosti prece ;-)
Taky nerikam, ze MySQL je dobry ci spatny SRBD,
protoze nerad stoucham do vosiho hnizda.
Snazim se pouze klopotne davam dohromady fakta.
Jejich zhodnoceni pak ponecham na laskavem ctenari ;-) -
Miloslav Ponkrác (neregistrovaný)
S prominutím, ale chápete význam toho, co čtete? Já Vám to zkusím vysvětlit:
1) MySQL vám umožňuje zvolit si z několika možností uložení data na disk. Říká se tomu typ tabulky:
a) MyISAM - klasika, každá tabulka je v samostatných souborech, databáze je v samostatném adresáři, bez podpory trasakcí, bez podpory cizích klíčů
b) InnoDB - přístup moderních relačních databází, tj. máte datové spaces, kde je všechno nějak vnitřně uloženo, je rychlejší, než při použité MyISAM, podporuje transakce se všemi náležitostmi, podporuje cizí klíče a mnohé další, i další věci jsou zde mnohem propracovanější
c) BerkeleyDB - podobné jako u InnoDB, ale nabízí jen zamykání po stránkách
d) Některé další typy, nechám na Vaše samostudium.
Co tím chtěli tedy soudruzi z MySQL říci? Že pokud si vyberete InnoDB, tak máte cizí klíče a spoustu dalšího. Pokud si vyberete MyISAM, tak tím sám sobě říkáte, že chcete oželet transakce a cizí klíče. Je to jen Vaše volba. Tabulky MyISAM jsou tam hlavně z toho důvodu, abyste byl kompatibilní se staršími verzemi databází, jinak řečeno, pokud použijete data uložená před třeba šesti lety, abyste je pomocí MySQL byl schopen přečíst a třeba přeimportovat do InnoDB. A to, že si MySQL vývojáři dají za závazek, že na MyISAM ještě dodělají cizí klíče, to je to, co psali v textu, který citujete. Psali, že ve verzi 5.1 budou cizí klíče pro "VŠECHNY TYPY TABULEK".
Pro jistotu píšu, že se jednotlivé typy tabulek dají navzájem kombinovat. Můžete mít v jedné databázi tabulka různých typů.
Čtenáři nechť si udělají závěr sami. Dávám k dispozici pouze fakta. -
dnc (neregistrovaný)
Pekne.
Mate pedagogicky talent ;-)
Pro uplnost dodavam, ze implicitni typ tabulky
je MyISAM. Odtud (mozna) ten duvod proc "soudruzi"
chteji implementovat cizi klice i do 'ostatnich
typu' tabulek. Ono totiz pri kazdem prikazu
CREATE TABLE davat napr. jeste TYPE = BDB je
s prominutim opruz. Navic ne vzdy mate pristup
primo k SQL kodu (embedded SQL, generated SQL).
Takze abych byl spravedlivy, opravim svuj puvodni
vyrok z:
> Verze ve ktere ma byt implementovan FOREIGN KEY -
> 5.1
na:
Verze ve ktere ma byt plne implementovan
FOREIGN KEY - 5.1
Mozna me nachytate na hruskach, ale nevim o tom,
ze by slo nekde globalne nastavit, aby implicitni
tabulka nebyla MyISAM ale treba InnoDB.
Pokud to nejde, je to jako rikat ridici osobniho
auta - pokud nastartujete auto beznym zpusobem, nebude mozne s autem couvat a navic vam pri pripadne havarii usekne hlavu. Chcete-li jezdit
bezpecne a mit moznost couvani, otvrte a zase
zavrete pred startem zadni okenko. -
dnc (neregistrovaný)
Pekne.
Mate pedagogicky talent ;-)
Pro uplnost dodavam, ze implicitni typ tabulky
je MyISAM. Odtud (mozna) ten duvod proc "soudruzi"
chteji implementovat cizi klice i do 'ostatnich
typu' tabulek. Ono totiz pri kazdem prikazu
CREATE TABLE davat napr. jeste TYPE = BDB je
s prominutim opruz. Navic ne vzdy mate pristup
primo k SQL kodu (embedded SQL, generated SQL).
Takze abych byl spravedlivy, opravim svuj puvodni
vyrok z:
> Verze ve ktere ma byt implementovan FOREIGN KEY -
> 5.1
na:
Verze ve ktere ma byt plne implementovan
FOREIGN KEY - 5.1
Mozna me nachytate na hruskach, ale nevim o tom,
ze by slo nekde globalne nastavit, aby implicitni
tabulka nebyla MyISAM ale treba InnoDB.
Pokud to nejde, je to jako rikat ridici osobniho
auta - pokud nastartujete auto beznym zpusobem, nebude mozne s autem couvat a navic vam pri pripadne havarii usekne hlavu. Chcete-li jezdit
bezpecne a mit moznost couvani, otvrte a zase
zavrete pred startem zadni okenko. -
Miloslav Ponkrác (neregistrovaný)
Nenachytám Vás na hruškách, máte pravdu. Ono je to tak, že vlastně MySQL se teď dost přebudovává.
Ve verzi 4.x je InnoDb bráno jako směr, který chce MySQL preferovat. Ve verzi 4.1 MySQL rozšiřuje nativní rozhraní pro klientské aplikace, aby bylo vůbec možné pojmout nové features plánované pro další verze. Navíc MyISAM nemá ve svých datových strukturách místo, aby třeba informaci o cizím klíči byť třeba jen uložilo, natož používalo. Proto bude přidání klíčů do MyISAM nutně předcházet rozšíření jejich datových struktur.
MyISAM se implicitně preferuje proto, že se zaručuje přenositelnost souborů s tabulkami MyISAM. To jest, můžete klidně zkopírovat databázové soubory třeba pod Linuxem a okamžitě jen bez nějakých exportů/importů používat třeba pod Novellem, nebo Windows, či jinde. Navíc MyISAM nepotřebuje žádné nastavení, stačí mu jen ukázat adresář, kde tvořit soubory.
Je jasné, že chcete-li vytvořit InnoDb tabulku musíte to uvést v "CREATE TABLE". A nebo převést existující tabulku na jiný typ pomocí "ALTER TABLE nazev_tabulky TYPE=InnoDB". To znamená, že i když nemáte přístup k embedded kódu, lze změnit typ tabulky dodatečně. Nevím o tom, že by se dalo nějak defaultně nastavit, jaký typ tabulky má tvořit. -
dnc (neregistrovaný)
V zasade souhlasim.
Asi vsak patrim mezi radu lidi, kteri budou tvrdit,
ze s ref.integritou je to u MySQL ponekud osemetne.
Aktualni (stabilni) verze dle http://www.mysql.com/downloads/index.html
je 4.0. Verze ve ktere ma byt implementovan
FOREIGN KEY - 5.1. Tedy vzdalenejsi budoucnost.
Na druhou stranu pokud napr. chcete provozovat free
web site, pocet poskytovatelu, ktery vam nabidnou
X MB prostoru na disku + Y mista pro MySQL je pomerne velky. Obavam se ze totez rozhodne neplati
pro PostgeSQL ci Firebird. Ale rad se necham vyvest
z omylu ;-) -
Michal Kubeček (neregistrovaný)
PostgreSQL i Firebird jsou velmi vyspělé databáze. PostgreSQL má v některých směrech více funkcí, pro Firebird mluví možnost používat nástroje a komponenty, které jsou k dispozici pro InterBase (ocení zejména vývojáři v C++ Builder/Delphi/Kylix). Také mám pocit, že díky MGA Firebird lépe zvládá větší množství konkurenčních transakcí. Ale není to podloženo solidními testy, může to být i rozdílnou mírou zkušeností.
MySQL se od těch dvou hodně liší. Primárně je to databáze konstruovaná pro situace, kdy data moc nemodifikujete (a spíš insert než update) a potřebujete hlavně rychlé selecty. Takže podpora některých základních věcí (transakce, foreign keys) je dodělávána dodatečně (a není úplná), jiné chybějí zcela (stored procedures, triggers, ...). Výsledkem je, že uživatel MySQL je nucen prakticky vše řešit na straně klienta a získá tak určité špatné návyky. Přesto má MySQL své uplatnění a pro určité typy aplikací se docela dobře hodí.
Pokud se chcete něco s databázemi skutečně naučit, rozhodně bych doporučil spíš Firebird nebo PostgreSQL. Když pak budete potřebovat použít Sybase nebo MS SQL (nebo třeba i DB/2 či Oracle), budete rozhodně víc "doma".
Jinak ale musím poznamenat, že přechod z MySQL na Firebird není zdaleka takový problém jako přechod opačným směrem. -
matouš červenka (neregistrovaný)
moc diky vsem za info, nakonec jsem zvolil 602sql server -- snadna instalace, prijemne prostredi, vychytavky (napr import dat z ruznych formatu...), plna podpora SQL 92, atd ... a je to i pro linux, panove!
Ostatni produkty mi bud nesedely, nebo jsem je neumel nainstalovat. jeste jednou diky -
Ditys (neregistrovaný)
Kdysi jsem vážně uvažoval o Interbase (tedy
ještě free verzi 6.0). Úspěšně jsem ji našel
na Internetu, nainstaloval - a poté zjistil,
že prakticky neexistuje free ODBC ovladač.
Systém funkční leč nepřístupný. I zalovil
jsem na CD Red Hat 7.1, našel Postgres a zprovoznil
ho. I ovladač ODBC byl k mání. Nejvíc mě ale
potěšilo, že umí bez problémů česky. -
roman (neregistrovaný)
Mozna to sem treba nepatri, ale je to trochu pribuzne tema. Noveji se daji vytvorit (v Oracle od verze 8i) i tzv. objektove tabulky, tj. tabulky, kde radka je tvorena objektem. Za primarni klic je pak mozne zvolit tzv. referenci na objekt, coz je normalni index udrzovany automaticky. Vyhodou je bezvadne API v C++ klientovi, kde je mozne nastavovat fieldy pres REF pointer a databaze sama ulozi tyto fieldy do tabulky. Neni tedy nutne davat prikaz update nebo insert. Je to hezke pro lidi pisici v C++, pro PLSQL nasinec to ma vyhodu ve zjednodusene navigaci (syntaxi) pri joinovani vice tabulek - neni nutne explicitne joinovat. Nevyhodou je neportabilita (ne vsechny databaze objektove SQL podporuji), objekty neni mozne pouzivat pres databazove linky a je nutne vyuzivat primarni klic, coz pro velke a casto se menici tabulky neni vzdy zadouci. Existuje jeste nekolik nevyhod, ale nebudu zabihat do detailu.
Objektove tabulky mam odzkousene, funguji dobre. Daji se pouzit zejmena na tabulku ruznych nastaveni (od zakladniho typu jsou odvozene dalsi specificke typy nastaveni). -
lzap (neregistrovaný)
Pekny clanek, jenom mam malou pripominku. To, co mate na obrazku neni B-strom (binarni strom) ale N-strom (n-arni strom). Ackoliv se binarni stromy take muzou pouzivat, spise se v relacnich databazich pouzivaji N-stromy. Umoznuji totiz relativne jednoduche vyvazovani a take strankovani na disk.
Hezky den -
Michal Kubeček (neregistrovaný)
O InterBase se dá říci přibližně totéž jako o Firebirdu, tak moc se zatím (IB 7.0, FB 1.0.3) ty dva projekty rozejít nestihly. InterBase ale není open source (kromě verze 6.0-6.0.1), od verze 6.5 ji Borland opět vyvíjí jako uzavřejný projekt (což je, zjednodušeně řečeno, hlavní důvod vzniku Firebirdu).
-
onovy (neregistrovaný)
Zdravim. Mel bych mensi dotaz. Resim tento problem:
Kazdych 5 minut se do jedne tabulky ulozi data(cca 100 radku). tabulka ma tyto sloupce. in bytes,out bytes,in packets,out packets,timestamp. kdyz pak potrebuju tyto polozky sum() za celej mesic, tak to trva rekneme trosku hafo dlouho. ale pokud zapnu indexovani teto tabulky, tak dojde k tomu z pridavani je tak pomaly, ze za tech 5 minut nez se zacne pridavat znova, se nestihnout udelat ani indexy, takze disk vali furt. Jaky doporucujete reseni? da se v mysql udelat neco jako vytvoreni indexu jenom na cast polozek a zbytek aby dohledaval rucne? tozn. ze bych v noci udelal index cele tabulky, a pres den by se index nedelal na nove polozky. -
dnc (neregistrovaný)
Da se napr. vytvorit novou tabulku s indexama
a jednou za urc.cas.jedn. tam zaznamy zkopirovat/presunout, coz je z hlediska db teorie
naprosty hnus ;-)
Taky lze puvodni tabulku mit jako temporary
typu HEAP (viz http://www.mysql.com/doc/en/HEAP.html)
Do trvale tabulky pak ukladat pouze data prechroustana z HEAPu. -
Jakub Vrána (neregistrovaný)
V první řadě se mi nezdá, že indexování popsaných 100 položek by stroj dokázalo vytížit na 5 minut. To musí být v nepořádku ještě něco jiného.
Ale hlavně je důležité rozmyslet si, nad kterými sloupci vůbec index nasadím. V příspěvku je uvedeno pouze "zapnu indexování tabulky". Jestli to znamená, že je vytvořen index nad všemi sloupci, je tento index v podstatě zbytečný. Jestli je vytvořen nad sloupcem timestamp, není také moc užitečný, protože když pokládám dotaz např. SELECT EXTRACT(YEAR_MONTH FROM timestamp) AS year_month, SUM(in_bytes) FROM data GROUP BY year_month, index se stejně nemůže použít, protože se sloupcem nepracuji přímo, ale přes funkci.
Správné řešení tedy vypadá tak, že se do tabulky přidá ještě sloupec year_month, nad kterým bude jediný index a který se bude počítat už v době vkládání záznamů.
Pokud vám však stačí údaje jako počet položek, jejich součet a průměr po měsících, je lepší primární data vůbec neukládat a jenom si v malé tabulce aktualizovat sledované hodnoty. -
tobog (neregistrovaný)
Vážení,
hodně mě to jako amatéra zajímá - celá tato oblast, je možné doporučit nějakou literaturu, která by laikovi přiblížila metodiku databázových indexů a podobných záležitostí (včetně robustních věcí), nějaká pdf na webu, odkazy?
Google mi ne a ne dát odpověď, rád bych si něčím pojmově otevřel oči (nikoli v tom, že "existuje něco jako primární klíč", ale "existují tyto metodologie pro tovrbu indexových stromů, blablabla").
Děkuji - jde mi o odkazy.
