Starší komentáře ke článku: Převod MySQL tabulky do textového souboru a zpět
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 30.6.2003 9:03:21
Jedna z <I>mála</I> nevýhod? Mluvíte opravdu o software, který si říká SQL server a přitom dodnes nepodporuje stored procedures?
Ale ona celá ta idea provádění úprav v databázi přes dump/edit/restore zavání tím, že MySQL tu není používána jako skutečný SQL server, ale pouze jako jednoduchý data store (taková lepší dBase). Při skutečné aplikaci SQL serveru by něco takového nemohlo autora ani ve snu napadnout.
Datum vložení: 30.6.2003 9:59:35
hehe.. no co, predpokladame prece, ze mezitim nikdo zadne zmeny neudela. a kdyz udela, tak si to zopakuje jindy :)
jedina vyhoda mysql je rychlost. takze pro webove casopisy a spol. je to idealni. a kdyz uz ji vyuzijeme pro webove casopisy, tak proc ne i pro jine aplikace? stored procedury nahradime php skripty a budeme doufat, ze kdyz se podari pridat neco do jedne tabulky, tak se to za par milisekund podari pridat i do druhe. na co transakce? :)
mimochodem - takovato reseni se nejen bezne delaji, ale daji se i vyhodne prodat. tak co? :)) bezne jsem je videl v provozu (dokonce se jednalo i o financni zalezitosti, vyplyvajici z dat) a nikdy k zadne chybe nebo nekonzisteci nedoslo (a kdyz, tak k docela docela malilinkate). takze to, ze mysql neni SQL jsou povery a nechte si je od cesty :)
Datum vložení: 30.6.2003 10:21:10
Neosočoval bych zrovna MySQL, která umí ledacos (i ty transakce ;-) Problém je IMHO spíše v lidech - jsou to většinou programátoři, kteří MySQL používají jen jako jednoduchý backend a nijak se na ni nespecializují. Nedávno jsem v práci navštívil jednoho kolegu, jehož jediným "chlebíčkem" je právě MySQL a osobně jsem se přesvědčil, co v této oblasti znamená profesionální specializace ;-)
Datum vložení: 30.6.2003 10:44:05
Ale to prece neni pravda, vetsinu tech veci muzete snadno resit na urovni skriptovani.
Na updaty/inserty se da snadno udelat trida (ja ji alespon mam) ktera se proste stara o to aby updatovala jen zmenene udaje. Kdyz s necim nehnete, nehrabe se na to. Kdyz jo, posledni vyhraje. Data se tudiz navzajem prepisi opravdu jen v pripade pokus dva lide soucasne edituji ty samou polozku v tom samem radku (holt smula).
Je to proste o tom jak se k tomu stavite. Pokud zrovna update neprovedu (sql down) tak se to zapise do souboru ktery se pak muze spustit dodatecne - a dokonci co bylo zacnuto. Pravda, za tri roky na savvy ten soubor nema ani bajt takze predpokladam ze to neni takova krize.
Jestlize jsem na seznamu videl MYSQL ERROR: Failed to connect at line xx ... atd. nebo zive se svym server connection timeout ... pak nechapu co tady pan Kubecek resi. Tohle neni prece databaze - jestlize je nekdo takova lama ze si ani neoveri zda se mu povedlo pripojit se k databazi, pochybuju ze se bude zabyvat vecma jako je rollback. V opacnem pripade neni problem si tam prihodit sloupec s potvrzovanim pozadavku. Btw, sezname, jsi pro me prekvapenim.
Datum vložení: 30.6.2003 14:38:53
Co řeším? Narážím na to, že pod dojmem všeobecně propagovaného hesla "free SQL server = MySQL", získává spousta lidí (vzhledem k značným rezervám v implementaci zcela principiálních featur v MySQL) o SQL serverech naprosto zkreslené představy. Zejména pak mívají ve zvyku ignorovat základní princip, že s tou databází nepracují sami. Ve druhé řadě pak ten princip, že klientských aplikací může být více (a velice různorodých), takže čím víc práce přenesou na databázi, tím lépe.
Minulý týden jsem se zrovna s několika dalšími snažil v databases@linux.cz přesvědčit jednu oběť této výchovy, že zamykat celou tabulku kvůli zaúčtování každé faktury je přeci jen trochu silná káva. Neuvěřil.
A tento článek jde ještě daleko dál. Autor chce provést nějakou jednoduchou změnu nad více tabulkami. Připadá mu, že je příliš složité napsat si několikařádkový skript a spustit ho v transakci (vezmu-li za bernou minci, že MySQL už tedy <I>transakce umí</I>). Dokonce ani nezamkne ty záznamy/tabulky a neprovede ty změny postupně. On raději vydumpuje celou databázi, odedituje to ručně a pak tu databázi zrestauruje zpátky. A korunu tomu nasadí tvrzením, že je to tak jednodušší...
Abych nebyl špatně pochopen, jsem dalek tvrdit, že dump (v jakékoli formě - osobně bych dnes dal přednost XML) je zbytečná věc. To určitě ne. Pouze mi vstávají vlasy hrůzou na hlavě, když čtu takové věci jako je motivační příklad obsažený v prvních dvou větách článku.
Datum vložení: 30.6.2003 14:41:04
Heh no pravda. Ovsem pravda taky je ze psat clanky na urovni se vsim vsudy tak budou mit 5 pokracovani kazdy ;)
Datum vložení: 30.6.2003 19:04:22
Ony je budou mít stejně... Jenom nebudou na hlavní stránce ale v diskusi pod článkem... :-)
Datum vložení: 30.6.2003 14:49:54
Dovolil bych si nesouhlasit s tím, že by se maximum práce mělo přenášet na DB, to totiž v mnoha případech (hlavně u Oraclistů ;-) vede k přesvědčení, že by DB měla dělat všechno, včetně generování XHTML výstupu. DB by měla provádět jen to, k čemu je určena, tedy práci s daty, a neměla by nahrazovat klientské skripty ;-)
Datum vložení: 30.6.2003 19:01:41
Asi jsem se nechal unést tím, že vídám daleko víc odstrašujících příkladů z opačné strany spektra. Tedy těch, kteří se například snaží hlídat klientskými skripty referenční integritu dat (pokud možno bez použití transakcí). Takže mi trochu uniklo, že se to dá přehnat i na druhou stranu... :-)
Datum vložení: 8.7.2003 7:35:46
Vaše problémy bych chtěl mít. To, že se <B>MySQL</B> povaluje na většině freehostingů samozřejmě znamená, že na ni vzniká nejvíce (rádoby) řešení, byť připouštím, že některá jsou značně vychytaná a řeší i chybějící transakce (u verze 3.x)
Nicméně pokud rozumný člověk potřebuje solidní zázemí a transakce, přičemž cena je také jedním (hlavním) měřítkem, může použít free <B>PostgreSQL</B>, která umí mnohem více než <B>MySQL</B> (o podpoře vnořených sub<B>SELECT</B>ů, ke kterým se <B>MySQL</B> pomalu propracovává teprve v 4.x řadě ani nemluvě), byť není tak super-rychlá, jako <B>MySQL</B> (ovšem v dnešní době výkonných strojů to není zas až takový problém).
Datum vložení: 5.3.2004 7:15:40
Dobrý den, vyzkoušel jsem váš skript a výsledkem bylo, že skript vytvořil textové soubory, naplnil je svislítky, ale už tyto soubory nedokázal naplnit daty. V IE se objevily tyto chyby: eregi_replace():REG_EMPTY nebo eregi_replace():REG_EMPTY óempty(sub)expression in ...... Jestliže se jedná o nějakou triviální chybu, tak se omlouvám. V PHP jsem spíše začátečník. Děkuji za odpověď.
Jirka
Datum vložení: 18.3.2007 19:52:21
Riešim niečo podobne a mám jeden veľký problém počet záznamov mám už cez 1500 a tu je problém nemôžem nájsť rozumné riešenie ako zabezpečiť rýchly uptade jednotlivých záznamov. Nemá niekto na to niekto nejaký liek.Lebo ja už som bezradný.100 položiek spraví ešte ako tak rýchlo ale čím viac záznamov dám spracovať tak tým to takmer exponecialne vzrastie celý udate neviem či mám zlý webhosting, databázu, alebo je celý postup.