Adminer nebo phpMyAdmin? Přece SQLyog!

K napsání tohoto příspěvku mě inspiroval článek phpMyAdmin VS Adminer a následná bouřlivá diskuse na Zdrojáku. Jakub Vrána ve svém textu srovnává notoricky známý phpMyAdmin a vlastní produkt Adminer, přičemž podle názoru části diskutujících tak nečiní příliš vyváženě. Původní zamýšlený komentář se mi trochu protáhl, publikuji jej tedy zde.

Stručně řečeno, celá debata, která se pod článkem strhla, mi přijde zbytečná - používát jakoukoliv webovou aplikaci pro pokročilou právu MySQL databáze je neefektivní. Pro vývojáře je totiž výhodnější zvolit některou z řady desktopových aplikací, které nabízejí lepší komfort a neporovnatelně vyšší rychlost, než jakých bude sebelepší webová aplikace kdy schopna.

Já ke své práci využívám SQLyog Community Edition, který je šířen pod licencí GPL, tedy zcela zdarma. Jiné, patrně nejznámější MySQL GUI, Navicat, verzí zdarma také disponuje, ta je ale k dispozici pouze pro nekomerční využití. Než bych zeširoka vyjmenovával všechny výhody, které takové řešení přináší, řeknu jen: zkuste a uvidíte, jestli se vám bude chtít k Adminerovi nebo phpMyAdminovi vracet. A pokud ano, budu rád, když mi své důvody uvedete do komenátřů. Ze své dosavadní praxe totiž nevím o nikom, kdo by tak učinil.

Jediným smysluplnýho využitím webového klienta pro přístup k MySQL je situace, kdy nemám povoleno vzdálené připojení k databázovému serveru (tedy typický webhosting). Ale i v takovém případě mi stačí pouze dvě funkce - dump databáze a možnost spouštět vlastní rozdílové SQL dotazy pro update databáze. Jakékoliv vytváření, úpravy nebo mazání tabulek, cizích klíčů, funkcí, trigerů atd. provádím nejprve na lokálním vývojovém prostředí v pohodlném SQLyogu a venku použiji až vygenerované SQL dotazy, které stejně musím pro pozdější případné dohledání uchovávat. Problémy mohou nastat snad jen při přesunu kompletní databáze. Popravdě si ale neumím představit situaci, kdy bych přenášel databázi, jejíž za(g/b)zipovaný dump by byl větší, než povoluje konfigurační direktiva PHP, na server, kde nemohu provést nutné změny v nastavení. Na takový server bych databázi snad ani nepřesouval.

Viděno touto optikou, je celkem jedno, jestli na serveru použijete Adminer nebo phpMyAdmin. Výhodou phpMyAdmina je to, že jej spousta webhostingů standardně předinstalovává, nemusíte tedy nic kopírovat ani konfigurovat. Pro Adminera zase hovoří jeho velikost a rychlost. Volba "co na server" je tedy na vás.

Každopádně veškerý vývoj dělejte na lokále a tam raději použijte robustní a komfortní desktopový program.

Webové aplikace

Jeden můj kamarád přechod z desktopové aplikace (myslím, že to byl Navicat) na Adminera podstoupil a udělal to kvůli použitelnosti.

Tvým argumentům rozumím a stejně tak si nedovedu představit, že by někdo mohl webovou aplikaci používat třeba pro práci s mailem nebo RSS...

Co se velikosti dumpu týče, tak Adminer dokáže zpracovat i soubory nahrané přes FTP, takže v tom by problém nebyl.

Navicat je celkem těžkopádný,

Navicat je celkem těžkopádný, tam by se dalo hledání lehčí alternativy snad pochopit..

Obecně máš pravdu - jedná se vlastně o spor desktopové vs webové aplikace.. Já rozhodně patřím mezi zastánce standardních "tlustých" klientů, i když je fakt, že zrovna na RSS si vystačím s Google Readerem. Především proto, že je pro mě důležitá možnost číst RSS bez ohledu na to, kde se zrovna nacházím. A žádné pokročilejší funkce (např. tagování, sdílení atd.) nepoužívám - buď si článek rozkliknu a případně uložím mezi oblíbené přímo v prohlížeči, nebo jej označím jako přečtený a dál to neřeším.

Zpátečníku

Zpátečníku
Webové aplikace a cloud computing mají budoucnost.

Spíše než za zpátečníka bych

Spíše než za zpátečníka bych se označil za konzervativního (-:

Jistě, webové aplikace a cloud computing budoucnost nepochybně mají, ale vývoj aplikací je natolik specializovaná a na výkon náročná činnost, že provozovat ji v prostředí webového prohlížeče nemůže být efektivní.

desktopova alternativa

Dalsi velmi dobre pouzitelna desktopova alternativa je HeidiSQL.

Podívám se na něj, díky za

Podívám se na něj, díky za tip!

Mam taky pocit, ze

Mam taky pocit, ze porovnavate trosku ine veci. Samozrejme okenna aplikacia je idealna pri vyvoji lebo ma lepsiu odozvu ako webova aplikacia. Samozrejmostou pri vacsich produktoch je pristup do DB priamo z vonka, ale tycht projektov je menej. Na klasickom webhostingu je vyhodne mat web rozhranie. Ak sa vyksytne chyba v aplikacii ktoru neviete vyvolat na vyvojovej databazi tak potrebujete sa pozriet na ostre data. Kedze tieto pripady potrebuju rychlu opravu a stava sa, ze z dat zobrazovanych aplikacou chybu nezistite (tie udaje nezobrazujete alebo pouzivate na ne nejaky filter ktory moze na nejakom specialnom znaku zblbnut). Mozno sa Vam to zda, ze take veci sa stavaju raz za tisic rokov, ale prave pri aplikaciach vacsich ale nie prilis velkych sa sto stavat moze. Nik nemoze pocitat s kazdou situaciou.

Porovnával jsem je záměrně,

Porovnával jsem je záměrně, neboť jsem z debaty pod originálním článkem vyrozuměl, že hodně programátorů používá phpMyAdmin nebo Adminer i pro samotný vývoj. A oba tyto nástroje se také snaží přidáváním nových funkcí okenním aplikacím konkurovat.

Co se týče druhé části, samozřejmě je nutné mít webové rozhraní k databázi i na serveru, to jsem v textu zmínil. Ani v takovém případě ale nepotřebuji nadupaného klienta se spoustou vychytávek, protože:

  • pokud se vyskytne chyba v aplikaci přímo související s daty na produkčním serveru, musíte stáhnout databázi na vývojové prostředí a tam chybu opravit. Přímému přístupu k ostrým datům je potřeba se vyhýbat, jak je to jenom možné - stačí malá nepozornost a důsledky mohou být katastrofální.
  • jen v opravdu výjimečných situacích se může stát, že nejste schopen na lokále chybu vyvolat i když skripty a data jsou stejná jako na serveru. Ale i tak vám bude stačit jedna textarea pro SQL dotazy a rozumné zobrazení výsledku. Už ve chvíli, kdy potřebujete joinovat dvě tabulky, je ruční napsání dotazu rychlejší než využívání grafického prostředí.

Čili srovnávat zmíněné produkty z hlediska implementovaných funkcí, což se dělo v článku i v diskusi, je jaksi k ničemu.

Re: Adminer nebo phpMyAdmin? Přece SQLyog!

Děkuji autorovi za článek. Já naprosto souhlasím. Nevidím důvod, proč se prát s nějakými webovými správci MySQL.

Abych to upřesnil. Tedy, ne že bych žádný z nich nikdy nepoužil - to rozhodně ano a užíval jsem je hojně -, ale nemám k tomu nyní už důvod. Hosting si vždy vybírám takový, který zbytečně neklade nesmyslná omezení, jako například pouze lokální přístup do MySQL. Co by mě mohlo donutit zvolit hosting, který něco takového neumožňuje? Inteligentní hosteři provozují vzdálený přístup do MySQL na jiném portu (savana.cz), za SSL vrstvou (tojeono.cz) a v krajním případě jsou ochotni manuálně povolit vzdálený přístup z dané IP (stable.cz).

Jak radí David Grudl, pokud váš hosting klade nesmyslné překážky, změňte jej!

Re: Adminer nebo phpMyAdmin? Přece SQLyog!

BTW: Zde na blogu bych docela rád uvedl ke komentáři své jméno a případně i kontakt, ale nenalezl jsem odpovídající políčka v odesílacím formuláři. Ostatní to možná ocení, ale já nerad píši jako "Anonym", tak je přikládám nyní: Jakub Bouček, jakub@boucek.info

Re: Adminer nebo phpMyAdmin? Přece SQLyog!

Díky za upozornění, pole pro vkládání kontaktních údajů jsem doplnil. Dále jsem ještě změnil řazení komentářů od nejstarších po nejnovější a doplnil možnost nechat si zaslat informace o nových příspěvcích na mail.

Další možnost

Poslední dobou používám HeidiSQL. Je monoplatformní, což mi ale jako zarytému fandovi Oken nevadí ;) Výhoda oproti Navicatu je např. v tom, že každý dotaz, který provede (vč. výpusi seznamu tabulek) vypíše do konzole. Při vytváření a úpravách tabulky nabízí CREATE a ALTER script pro neuložené změny a další...

Re: Další možnost

Závislost na Windows mi v tomto případě nevadí, HeidiSQL (stejně jako SQLyog) ve Wine šlape bez problémů. A vypadá vážně dobře, pokud někdy budu chtít SQLyog opustit, HeidiSQL zkusím nejspíš jako první.

Poslat nový komentář

Obsah tohoto pole je soukromý a nebude veřejně zobrazen.
  • Webové a e-mailové adresy jsou automaticky převedeny na odkazy.
  • Povolené HTML značky: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Řádky a odstavce se zalomí automaticky.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>. Beside the tag style "<foo>" it is also possible to use "[foo]".

Více informací o možnostech formátování