Ale je stále. 602Form Filler navíc už dnes ani pod wine nejde za normálních okolností nainstalovat, dřívější .exe instalátory jsou nahrazeny .msi. A ta státní správa? 602Form Filler widle only je jedno ze dvou aplikačních rozhraní nutných pro provozování CZECH-POINT. Takže 602Soft jako člen OSS ALiance je současně schizofrenně žába na prameni, která brání rozvoji použití OSS ve veřejné správě - zejména pokud jde o použití alternativních OS. A pokud brání použití jiných OS než jsou widle svým win-only CZECH-POINT řešením (které se ale vesele používá i v dalších případech komunikace, často jako výhradní způsob pro výměnu dokumentů s veřejnou správou), může na poli OSS dělat co chce (OpenOffice, 602SQL) a bude se to míjet účinkem, neb se bude mít ze setrvačnosti za to, že widle OS vyžaduje "přirozeně" i widle kancelářský balík. A tak veřejná správa bude i nadále vydávat významný balík za licence M$, ač by nemusela. Malé obci, ač by mohla kompletně jet na OSS, pokud bude poskytovat výstupy z CZECH-POINT, je "díky" 602softu diktováno win řešení.
Asi ani moc ne... lide si najdou neco jineho OSS (Postgres? Kdo vi.). Myslim ze MySQL se pro weby pouzivala v tech "takovych normalnich webech" jen proto ze ji pouzivaji ostatni, ne kvuli nejake jeji zasadni vlastnosti. Takze pripadna nutnost migrovat na jinou DB sice bude vypadat hrozive, ale nakonec IMHO tak moc bolet nebude.
Jestli teda rozumim pojmu "takovy ty normalni weby" spravne (pro mne to predstavuje slepenec kusu kodu od lidi co tomu moc nerozumi, ale nakonec jim to cca. dela to co chteli a jsou se sebou maximalne spokojeni).
-existuje fůra dokumentace pro začátečníky a lamy, kde se člověk dostane bezbolestně od uplného začátku až k relativně pokročilejm věcem (např. ta tlustá bichle mistrovství v MySQL 5, docela jsem brečel, když jsem ji musel vrátit do knihovny), nemluvě o všech těch PHP a MySQL knihách. Možná nad některejma návodama databázovejm odborníkům šednou čupřiny a odborníkům na bezpečnost klesá brada nad takovou nehorázností. Nicméně jsou to věci který člověka provedou od uplnýho základu, k řešení, který je, ať si kdo chce, co chce říká, použitelný. To prostě pro Postgre neni (aspoň v ČJ a ve srovnatelnym rozsahu). Navíc pro mysql jsou docela příjemný gui tools.
Jako, pro databázisty skalní je MySQL možná nedopečená hračka vhodná leda na weby, ale co dělám v práci na MS SQL, tak mi příde obecně MySQL uplně zlatý (i když je mi jasný, že muj subjektivní dojem uživatele není žádný měřítko).
Presne tak jsem to myslel. Pointa je v tom, ze kdyby MySQL zmizelo, tak to nepotrva moc dlouho a tech par lidi co tomu rozumi docela slusne posune nejakou jinou OSS DB na stejne misto jako MySQL ted, t.j. spousta tutorialu jak rozbehnout LAMP (ale bez M), prijemne gui tools, atd.
Jedine co bude vzdycky spatne je CJ, kdo neumi anglicky, bude vzdy nekolik let pozadu a paberkovat v tom co mu znalejsi predhodi, ale to neni dusledek prodeje SUNu, to je nemenny fakt od zacatku veku pocitacu.
Podle mě to bude v zásadě znamenat, že člověk kterej chce web s databází, nebude už tušit, co je vevnitř, rozběhá si prostě drupal, joomlu, nebo něco takovýho a databáze se bude přesouvat do pozice černá škatule někde v počítači, ve který jsou jakože nějaký data.
Nerozumiem tejto panike. "...kdyby MySQL zmizelo".
MySQL Community Server je open source pod GPL. Co komu brani v tom aby urobil fork a pokracoval vo vyvoji pod inym nazvom ak Oracle stopne vyvoj? Je azda malo dokumentacie? Alebo nestacia tie miliony instalacii? Sakra, este dobre, ze SuSE svojho casu kupil Novell a nie m$... to uz by OSS azda ani neexistoval a vsetci by sa asi klanali velkej BSOD.
Open-source se sice hezká věc, ale realita je taková, že jen pár lidí, kteří několik let stojí za vývojem, skutečně danému projektu rozumí. Buď seženeš takové klíčové lidi nebo se spíše vyplatí začít od nuly a brát jen inspiraci.
Azda neplati to iste aj pre linuxove distribucie? A napriek tomu sa kazdu chvilu niekde vyliahne nova (ci uz fork niecoho osvedceneho, alebo nieco uplne nove - ako svojho casu Gentoo), niektore zakapu, ine preziju. Preco by to nemalo fungovat aj v pripade databaz?
btw, Bud klucovych ludi zozenies, alebo sa klucovi ludia toho chytia sami...
je sakra rozdiel, postavit si vlastnu linuxovu distribuciu, co dokaze aj priemerny pouzivatel, nemusi to byt ani extra linuxovy guru. vid projekt greenie, kedze priemerne *buntu klony, nie su nic ine, len baliky ubuntu, s nejakymi metabalikmy. Kvazi vyvojar tejto distribucie nema ani potrebu prekompilovat zdrojovy kod. Kdezto ked chces nieco take robit s databazami , tak sa asi bez kompilacie nezaobides, a dokonca budes musiet pravdepodobne aj pochopit tomu , co chces kompilovat.
Inac osobne som radsej, ze to kupil oracle , ako keby to kupilo IBM, kedze tak by s ovela pravdepodobnejsie pochovali Solaris, co by bola vacsia skoda.
Mozno ze spoja Oracle s Mysql ( rozumej vybrakuju z nej to malo co tam je , napr. Innodb engine, a plugin engine ) a Spravia z Oracle XE open source.
MySQL a její engine MyISAM je pravděpodobně nejlepší současná databáze na netransakční tabulky. Používá ji i Seznam na databázi procházených URL (SeznamBot).
jenomze bez podpory transakci nemuzete implementovat ani SQL standard. vemte si konstrukci
UPDATE XX SET PRICE = PRICE * 1.05
co se stane kdyz to v pulce spadne?
Navic nepodpora transakci v MYISAM je zjevne ten duvod proc to nici data kdyz dojde misto na disku. Neda se udelat rollback a vratit zmeny takze to zapise pointer na stranku co neexistuje.
InnoDB ma taky pekny races pri db recovery. Cas od casu nam sem volaji zakaznici at jim pujcime naseho experta na mysql protoze jim innodb pri recovery spadlo. Opravuje se to systemem pridavame 1MB /dev/zero na konec souboru nez to projde kdyz to canca o invalid page pointerech.
Standard SQL přece definuje jazyk, ne funkcionalitu DBMS. Jestli je při pádu během provádění dotazu zachována integrita nebo ne, to snad standard neřeší.
Představa, že by z nejrůznějších důvodů byla porušena integrita dat, je ovšem tak hrozná, že s ní standard nepočítá. Nevím, jestli jste viděl standard - kromě jazyka je tam jistým způsobem definováno i prostředí a chování.
Pak tedy holt MyISAM neodpovídá standardu a mě je to osobně fuk.
Kdybych chtěl používat transakce, sáhnu po PostgeSQL.
MySQL používám právě proto, že umožnuje transakce ignorovat a dosahovat díky tomu mnohem vyšších výkonů. A to je právě ta vlastnost MySQL, která je dle mě jedinečná - výkon nad MyISAM.
Coby 'odbornik' jsem vyvoj MySQL prestal sledovat v situaci, kdy s obrovskym halo oznamili hotovou podporu transakci: na konci clanku plnych oslavnych od bylo male upozorneni, ze tedy transakce ano, ale rollback jeste neni implementovany.
Migrace na PostgreSQL u "domácího webu" není problém, horší je to tam, kde se MySQL využívá pro její obrovský výkon, rychlost, tam se náhrada bude hledat špatně... (Oracl$ :).
mysql nema obrovsky vykon. Kdyz uz se mu databaze nevejde do cache, rekneme tak 10GB dat tak ho vyklepe i Cloudscape, o serioznejsich db ani nemluve.
Kolik insertu zvladne mysql za sekundu? DB2 zvladne ve stored procedure (nejsou tam network round tripy) cca 80k insertu/sec, Oracle umi importovat bez pouziti direct loadu tedy pomoci poctivych insertu asi 5M radek ze souboru za minutu.
tak tech 5M/minutu bylo pro DB2 9.5.1 kdyz se delaji single row inserty a importi se to ze souboru. DB2 DRDA protokol se nema moc rad s RTT.
Oracle 10g
import sql*loaderem options (errors=999999, rows=1000)
55.81M radku celkem. Indexy behem loadovani zadne.
Export s oddelenim polozek znakem "," - 593MB
export s oddelenim polozek pomoci "'" a ',' - 680MB
celkova doba importu 2m 8s, loader delal zhruba 120 radku/insert
vytvoreni indexu nad char polozkou - 21sec
select s where z='nonexist' -> bez indexu full table scan 6.5 sec.
shrnuto - nerekl bych ze je ten oracle nejak extremne pomaly.
To asi nikdo netvrdí. (pro insert je ovšem nutné použít sql*loader), obdobně jako u pg COPY. Jde o to, že pro UPDATE, DELETE, SELECT nad jednou tabulkou s primárním klíčem který se nemění, je na MyISAM v single režimu cca 10 rychlejší než u PostgreSQL, Oraclu, Firebirdu, vlastně jakékoliv ACID databáze - výjimkou je asi jen single user databáze SQLite. MyISAM je ideální na zpracování logů, párování - i když některé úlohy se dnes dají udělat ještě efektivněji s memcache. Na něco je to použitelné velice dobře. Jde jen o to správně si vybrat, který engine kdy a na co použít - což je asi pro někoho problém.
10x rychlejsi to neni. Kdyz pouzijete prepared statementy ktere vyrazne zvysi rychlost Oracle a DB2 tak mysql isam neni ani 2x rychlejsi pokud se mu vejde cela tabulka do cache (coz je nelepsi mozny pripad pro mysql, jakmile musi cist z disku tak uz je pomalejsi).
ostatne tenhle test to doklada taky. myisam 4.0.X je jen 2x rychlejsi nez db2. Asi nepouzivali prepared nebo static SQL v DB2, od zacatecniku bych to ani necekal.
prepared statements maji smysl pouze pokud opakujete slozitejsi dotazy - a samozrejme jako obrana proti SQL injektazi. Planner u MySQL je radove jednodussi a tudiz i rychlejsi nez u Oraclu. Jde o zpusob ulozeni dat na disk, zamykani, resp. nezamykani, zapis resp. chybejici zapis do transakcniho logu. Diky tomu je MyISAM fakt velice rychla. Neni nic jednodussiho nez si to vyzkouset - plati pravidlo, ze se jedna o jednoduche selecty a jednouzivatelsky provoz.
s tema prepared statementama nemate pravdu. Nejvice % usetrite u jednoduchych dotazu. Kdyz dotaz bezi rekneme 5 sekund, tak cas jeho naplanovani - radove milisekundy nehraje podstatnou roli. Kdyz dotaz bezi minuty tak je to pak uz uplne jedno.
Ja jsem si to vyzkousel a dava mne to stejne vysledky jako v tom clanku. Nikdy nebylo mysql 10x rychlejsi, vzdy bylo rychlejsi maximalne faktorem 2.
Navic pgsql 8.3 dava srovnatelny vykon na malych tabulkach s db2 9.5, takze ani pgsql neni vyrazne rychlejsi (protoze je jednodusi timpadem kratsi CPU execution path. navic db2 je v c++) nez profi db.
Zřejmě ještě záleží na hw a stroji. U těch prep. statements - v podstatě jsou 4 kombinace z (jednoduchy, slozity dotaz) X (rychly, pomaly dotaz). Porovnavat pg a db2 za ucelem odhadu rychlosti planneru dost dobre nejde. Je to porovnani mvcc a non mvcc architektury.