Čím je Adminer lepší než phpMyAdmin?

Jens:

Zvyk je železná košile. Adminer jsem zkoušel ale těch spousta let na phpMyAdmin mě tak poznamenalo, že jsem v něm byl natolik neefektivní, že jsem se vrátil zpět. Tak zase možná časem, jinak podle toho srovnání to vypadá fakt dobře :)

JAM3SoN:

Som presne prípad ako Vy, len s tým rozdielom, že som pri ňom vydržal chvíľku dlhšie a už naň nedám dopustiť :)

Eda:

Jedině Adminer, kam se hrabe moloch phpMyAdmin... nemá nic navíc, ale zato je nepřehlednější, paráda :-)

Ne, vážně. Adminer je skvělý nástroj a doufám, že se brzo podaří jej široce prosadit. Jen tak dál.

blizzboz:

ja používam na MySql a Postgre SQL - Navicat a na MS SQL - SQL Server Management Studio. PhpMyAdmin používam len keď musím, má hrozne neprehĺadné rozhranie. Adminer som ešte neskúšal ale určite ho niekedy vyskúšam.

Daniel Máslo:

Adminer je skvělý nástroj, bohužel ho využívám jen zřídka. Většinou databázi jen vytvořím a pak vše spravuje framework nebo nějaké CMS.

Hodí se ale třeba u klienta. Stačí uploadovat jediný soubor a to je fantastické.

Adminer doporučuji.

finc:

Pri existenci vzdaleneho pripojeni k DB, jsou webove aplikace na spravu databazi k nicemu. Pote prichazi na radu desktop aplikace. A na desktop jedine AquaData Studio :)

Na webu a na par tabulek (viz e-shopy, cms, atd.), je Adminer urcite lepsi nez phpMyAdmin. Me se libi uz jen ta logika: "one file" :)

Jakub Vrána :

A jen šílenec by používal webové rozhraní pro správu mailů :-).

Miroslav Hruška:

Adminer je super nástroj, přehledný, jednosouborová verze je naprosto dokonalá, chybí mi tam však jedna důležitá věc, pro kterou nástroje tohoto typu využívám - export výsledku SQL dotazu do excelu nebo csv. Klient potřebuje data, na která nemá v adminstraci žádný nástroj - přihlásím se do phpmyadminu, vytvořím SQL dotaz a jeho výsledky vyexportuji a pošlu zákazníkovi, adminer toto zatím nenabízí nebo jsem to alespoň nikde nenašel.

Jakub Vrána :

Je to tak, dokonce na to existuje i bug: https://sourceforge.net/tracker/?func=detail&…&group_id=264133.

Nejvíc přemýšlím nad uživatelským rozhraním – aby to nepřekáželo a přitom bylo po ruce.

Miroslav Hruška:

IMHO by stačilo přidat záložku Export vedle "Ze serveru" a "Historie". To je přesně to místo, kde bych takovou funkci čekal, UI bych nechal stejné jako jsou exporty při výpisu z tabulky. Toto je jediná funkce, která mi braní v plném nasazení admineru, jinak opravdu dobrá práce Jakube, držím admineru palce.

Jakub Vrána :

Zajímavý nápad. Já jsem počítal s tím, že to dám pod každý jednotlivý výsledek (vedle Upravit a EXPLAIN). Ještě to zvážím.

Miroslav Hruška:

A nebude to matoucí? Vzhledem k tomu, že si uživatel všimne té záložky export například ve výpisu tabulky. Když pak budu pracovat s adminerem, čekal bych, že ta funkce bude stále na stejném místě a bude se chovat stejně. Jako jediný problém vidím v tom, že se musí přescrollovat celá textarea na úpravu zadaného dotazu ale zase jdu na jistotu. Jinak další věc, která by se minimálně mně hodila, je export EXPLAINu.

Jakub Vrána :

Export EXPLAINu řešit nebudu, půjde na to použít běžný export SQL (jen se EXPLAIN bude muset napsat ručně).

Miroslav Hruška:

Super, phpmyadmin tuhle funkci nemá (po zadání EXPLAIN nelze výsledek vyexportovat) a občas mi to chybí.

kozotoč:

Pár argumentů k zamyšlení pro obě dvě řešení exportu výsledku SQL:
* více SELECTů v jednom odeslaném SQL
 + pro uživatele pohodlnější než používání UNION
 + v některých případech UNION nestačí - například když je potřeba mezi výpisy, které mají tvořit část exportu, udělat nějaké data- nebo tabulky-měnící operace
 - problém, když každý SELECT má jiný počet sloupců - jak to řešit? Vložit prostě data za sebe? Nabídnout ZIP, obsahující co SELECT to soubor?
- export za každým SELECTem bude znamenat více odesílaného HTML kódu, má-li se nabízet onen rozklikávací fieldset s výstupními formáty
Příklad: export výstupu SQL je řešen za každým SELECTem. SQL obsahuje 1x SELECT, pak 1x UPDATE a 1x SELECT. Pokud uživatel otevře (nikoli uloží) první SELECT pro export, vrátit se může jen s novým odesláním požadavku, což způsobí, že se onen UPDATE provede podruhé a výsledek už nemusí být stejný.

Podle mě pokud bude možnost exportu celého SQL až na konci a uživatel to bude chtít využít, tak už si text SQL přizpůsobí, aby dostal to, co potřebuje.

Ještě mě napadla jedna lehce šílená možnost a to dát za každý v SQL sekci vypsaný SELECT checkbox s labelem "zahrnout do exportu", jehož tlačítko by bylo na konci :-)

Jakub Vrána :

Export už je v Gitu hotov. Nakonec je pod každým výpisem samostatně.

riki:

Tiez si neviem Adminera vynachvalit. Je neuveritelne prehladny, jednoduchy, minimalisticky. Kazdy prvok, ktory by spravca webovych databazi potreboval a ocakaval, clovek najde vsetko na svojom mieste. Silno radim kazdemu vyskusat a chvilku pri nom zostat :) PMA sa ale zbavit nemozem tiez z podobneho dovodu a tym je import z xls tabuliek.

kozotoč:

Import z XLS tabulek by šlo vyřešit přes CSV.
Ale neznám kontext - třeba to dělá sekretářka, které je těžké vysvětlit, jak na to...

Rak:

To je fakt dost podstatna funkce, kterou treba zase phpMyAdmin umi. Zajimave, ze treba toto se v onom objektivnim srovnani neobjevilo :D

Jenda:

Nedavno byl Adminer i ve zprávách na Čt1. Nevšimli jste si?

Juraj:

Na základe Twittru by som povedal, že si to Jakub všimol. Ja používam Adminer, a neviem si bez tohoto nástroja predstaviť vývoj a správu MySQL DB.

Milan:

Ano, jak studenti z Karlovky zjistili tu blamáž se státními penězi. Nejdelší záběr tam byl právě na Adminer ;)

Jakub Vrána :

Kdo by to chtěl vidět: Adminer v Událostech na ČT1: http://www.ceskatelevize.cz/porady/109718132…/211411000100125/video/ (čas 12:00 - 12:22).

Miroslav Hruška:

Překlep ve srovnávací tabulce: Adminer je k dispozici i ve verzi pouze pro MySQL :)

Jakub Vrána :

Asi to není překlep, ale nešikovná formulace. Mám tím na mysli, že když někdo jiné databáze nechce používat, tak si může stáhnout verzi Adminera, která umí pracovat pouze s MySQL. Nebo jsem něco přehlédl?

Miroslav Hruška:

Jo pardon, takhle po ránu jsem si to nějak nedal dohromady já, nějak jsem přehlédl "i" a vyšlo mi, že je POUZE pro MySQL, je to správně.

Schmutzka:

(Tip na vylepšení.) Vhodné by bylo by při zakládání tabulky ověřovat její název, zda náhodou nepatří mezi nějaké příkazy/fční výrazy (například teď mi chvilku trvalo, než jsem zjistil, že název 'order' zřejmě nepůjde), zejména v těch komplikovanějších slovech (předpokládám, že taková existují a ne všichni ji máme stále na paměti).

Maličkost udělaná za stejně odpovídající čas. Ale nespěchá to :).

Jakub Vrána :

Při ošetřování identifikátorů (které Adminer provádí) lze použít jakékoliv názvy. Takováto kontrola tedy nedává smysl.

kozotoč:

Admineru sice fandím a dlouho ho používám místo phpMyAdmina, ale musím říct, že to porovnání na oné odkazované stránce je v několika bodech značně tendenční ne-li přímo zmanipulované. U bodů, kde záleží na úhlu pohledu uživatele, jsou vypsány nevýhody phpMyAdminu a výhody Admineru, ale už ne výhody toho samého řešení u phpMyAdminu a nevýhody u Admineru. Některé funkce Admineru mají navíc své omezení, ty ale také záměrně nejsou zmíněny.

Jakub Vrána :

Konkrétně, prosím.

kozotoč:

Dobrá tedy. Vyberu některé body, ke kterým mám připomínky:

Vytvoření tabulky: chytrost/hloupost a stavíš na jedné věci - zde na tom, zda-li si musíš před vytvořením určit počet řádků. Při vypnutém JavaScriptu se v Admineru (stejně jako u PMA) stránka znovunačítá s každým přidaným sloupcem a navíc v Admineru to jde pouze po jednom, takže tento úkon je v něm paradoxně (a podlé tvé terminologie) "hloupější".

Změna tabulky: s tím, co je tam napsáno - souhlas. Ale když (ve většině případů) chci změnit jen jeden sloupec, tak u tabulky s opravdu mnoha sloupci má PMA ke cti menší přenesené HTML a přehlednost.

Cizí klíč: "Vícesloupcové cizí klíče v phpMyAdminu vůbec nelze vytvořit." → "Vícesloupcové cizí klíče v phpMyAdminu lze vytvořit pouze v SQL." (Na tom, že to zvládnou jen zkušení uživatelé, a tím pádem je to uživatelsky nepřívětivé, se shodneme.)

Přihlašování: proti tomuto neargumentuju, jen říkám, že označení "částečné" a "kompletní" jsou trochu nešťastně nazvané ('částečně' se přihlásil k phpMyAdminu, kompletně se přihlásil k Admineru). když už, tak bych vypíchl přihlášení ze seznamu uživatelů (ano/ne) a konfigurace přihlášení (částečná/pokročilá).

Uživatelské rozhraní: opět, intuitivnost a ohodnocení "matoucí" a "intuitivní" stavíš pouze na jedné věci, v tomto případě na zmateční ikoně pro výpis v PMA. To, že nováček v Admineru nebude vědět, jak odeslat příkaz v SQL oknu nebo editovat hodnotu z výpisu přes dvojklik, jsi ale kupodivu nějak opomněl. Říct, že uživatelské rozhraní v PMA je matoucí, jsou při vší objektivnosti silná slova. I Adminer má stále co dohánět, aby se dalo říct, že je zcela intuitivní.

Hromadná editace: V phpMyAdminu neexistuje žádný →(tady bych vložil "uživatelsky přívěřivý") způsob, jak změnit hodnotu políčka u více řádek najednou.

Vícenásobná editace: nějak je zřejmě zcenzurováno, že v Admineru editace přes dvojklik nejde pro delší texty. A pokud by se náhodou (podle tam zmíněného příkladu) korigovaly chyby v textu (které s velkou pravděpodobností budou přesahovat těch 100 nebo víc znaků), pak je rázem tato editace v Admineru velmi neohrabaná a nepříjemná. Ale to se do srovnání nehodí napsat, že?

Klonování řádku: Říct, že u PMA je klonování "náchylné k chybám" jako by naznačovalo, že chyby jsou ve skriptu. Není lepší "náchylné k omylu" nebo "náchylné k přepsání dat"? Technicky vzato, zapomenutí klonování při úkonu klonování je chyba uživatele (teoreticky by to nemělo být připisováno PMA, ale chápu, že teorie je teorie a praxe praxe). Dále, jak se tak na to koukám v Admineru, vidím, že u klonování chybí 'vícenásobná verze', která naopak v PMA je. To je opět věc názoru, co je lepší - ne však podle tohoto srovnání. A když už jsem u toho, v Admineru bych se přikláněl k tomu, aby na stránce klonování, v nadpise "Vložit: <název tabulky>" bylo "Vložit" změněno na "Klonovat", popřípadě aby se u obou rozlišilo, že operace je s řádky a ne celou tabulkou (tedy například nadpis "Vložit řádky: <název tabulky>"/"Klonovat řádky: <název tabulky>").

Seznam databází: V Admineru se při vypnutém JS žádnou statistiku nedozvím.

Klávesové zkratky: Mně sice Ctrl-šipky u PMA taky štvou, ale jiný, kdo je na to zvyklý, na ně třeba nedá dopustit. Napsat ale, že překáží, je podle mně subjektivní.

Celková výkonnost: Byl bych za to vyměnit hodnoty "pomalý"/"rychlý" za "pomalejší"/"rychlejší", protože takto mohou fungovat ve vzájemném porovnání, bez nutnosti dalšího kontextu. Říct "PMA je pomalý" nebo "Adminer je rychlý" by podle mě bylo v pořádku spolu s doložením, jak si na tom vede v porovnání se všemi obdobnými databázovými manažery.

Upozornění na nové verze: upozornění e-mailem u PMA je zobrazeno v červeně podbarveném políčku a zkontextu se lze dovtípit, že toto podbarvení znamená něco špatného. Smím se zeptat, jak/v čem je to špatné? (Obdobně, ale už v menší míře - co je špatné na tom, že PMA má 6 vzhledů?)

Formáty exportu: Prosím o výčet všech formátů u PMA místo záměrného uvedení jen těch nejexotičtějších.

Je dost možné, že jsem něco zapomněl zmínit/nezmínit, tak se předem omlouvám.

Možná je ještě pár věcí, které by se ve prospěch Admineru daly přidat.
Nejsem si jistý, jestli jsem mezi výčtem výhod viděl ono speciální replikační SQL, co eviduje rozdíly mezi databázemi. (Je to tam?)
Ještě bych se zeptal - může nastat případ, kdy PMA selže při pokusu založit si vlastní tabulky nebo databázi, kterou při určitém úkonu potřebuje k práci. Dalo by se to kvalifikovat jako obtrusivní?
Btw. podobné srovnání je na Wikipedii - http://en.wikipedia.org/wiki/Comparison_of_database_tools
'Ses tím, Jakube, nechal inspirovat? :-)

Jakub Vrána :

Děkuji za zpětnou vazbu a velmi pečlivě sepsané připomínky. Část z nich zohledním při dalším vývoji, k části se vyjádřím.

Srovnávat uživatelské rozhraní při vypnutém JavaScriptu je podle mě bezpředmětné. Důležité je, že bez JS všechno jde, i když méně pohodlně. Je to jako srovnávat vzhled s vypnutými styly.

Já si při změně jednoho sloupce často vzpomenu „jó, podobnou změnu jsem chtěl udělat ještě u tohohle sloupce“. V PMA to znamená buď se vrátit o krok zpátky, označit oba sloupce a provést změnu znovu, nebo změnu uložit, počkat na ALTER a pak totéž udělat s druhým sloupcem.

Asi se shodneme na tom, že hypotetický nástroj obsahující textareu schopnou vykonat SQL příkaz a zobrazit jeho výsledek, dokáže provést jakoukoliv operaci. Ale napsat o takovém nástroji, že tyto operace (např. správu vícesloupcových cizích klíčů) podporuje bych si tedy netroufl.

To „částečné“ se vztahuje hlavně k trvalému přihlášení, je to nešťastně napsané.

Mě PMA přijde matoucí opravdu skoro celý - přes 100 ikon, kde u většiny netuším, co dělají, dokud nad nimi nepodržím myš, mi jako ukázka použitelného rozhraní fakt nepřijde. Seznam tabulek je toho ale zářivá ukázka. Začínající uživatel odešle v Admineru SQL příkaz kliknutím na tlačítko, ne? A u toho se v bublině dozví, že ho jde odeslat i pomocí Ctrl+Enter. S neintuitivností editace přes dvojklik jsi ale uhodil hřebíček na hlavičku – s touto funkčností se uživatelé fakt těžko seznamují. Teď je to alespoň tak, že když zmáčknou „naprázdno“ tlačítko Uložit, tak se jim zobrazí instrukce, ale přes to se to řada uživatelů taky nedozví. Jiné řešení (které by nemělo ještě víc nevýhod) mě bohužel nenapadá.

Dá se v PMA víc řádek najednou změnit jinak než pomocí ručního SQL příkazu?

Editace delších textů jde, když je povolené jejich zobrazení. Ale máš pravdu, že chování bylo dost nešikovné – nicméně už je to umožněné tak dlouho, že už jsem skoro zapomněl, že to někdy šlo pouze takhle krkolomně (v branchi to bylo už měsíc před vydáním verze 3.1.0).

Klonování je náchylné k uživatelským chybám. Mě se opravdu několikrát stalo, že jsem na to zapomněl a pak jsem si rval vlasy. Při klonování řádku se skutečně vkládá nový řádek, smysl v odlišení nadpisu nevidím. Nadpis Vložit (Insert) vychází z terminologie SQL, pro změnu na Vložit řádky (nebo někdy spíš Vložit řádek) opět nevidím opodstatnění.

Leda by sis příkazy spustil ručně... :-)

Zabrat si Ctrl+Vlevo a Ctrl+Vpravo, které se používá pro skákání mezi slovy (a třeba já ho běžně používám i ve struktuře tabulky, natož v datech), je krajně neslušné a skutečně mi to překáží.

Věřím, že by rychlostní srovnání dopadlo podobně i s dalšími nástroji (tedy Adminer by byl srovnatelně rychlý jako ty nejrychlejší a PMA jako ty nejpomalejší).

U nástroje, který řeší tolik bezpečnostních chyb jako PMA, je žádoucí, aby uživatelé používali pokud možno aktuální verzi. Z vlastního pozorování mohu říct, že to tak velmi často není, takže současná notifikace asi nefunguje úplně ideálně. Je to i tím, že PMA na hostinzích už obvykle rovnou je a uživatele ani nenapadne se někam hlásit k odběru novinek. Když by přímo v rozhraní viděli, že existuje nová verze, tak by třeba sami na hosting zatlačili, ať ji tam dá. Na 6 vzhledech není špatného nic, jen je to míň než 8 ;-).

V tabulce je málo místa, takže jsem v ní primárně uvedl hlavně ty exporty, které jsou pro PMA nejspíš exkluzivní.

Alternativu ke CREATE+ALTER exportu PMA tuším v aktuální verzi má (Synchronizace), ale používat jsem ji nezkoušel – po pravdě řečeno z ní mám trochu strach, navíc netuším, jak se to bude chovat, když k druhému serveru nebudu mít vzdálený přístup.

Tabulka na Wikipedii je pěkná, i když samozřejmě poněkud neutrálnější :-). Mimochodem nechtěl by v ní někdo záznam Admineru aktualizovat? Existuje Multi server support a místo SVN se používá Git.

kozotoč:

Díky za reakci. Ještě pár poznámek:
Ano, vypnutý JavaScript v prohlížeči je poměrně minoritní záležitost. Podle mých informací by ho mělo mít vypnutý kolem 5 % uživatelů, tedy zhruba každý dvacátý.
Ad "nástroj s SQL oknem") ano, na tom se shodneme; problém je v tom, že je to tvůj konkrétní předpoklad, který nasazuješ na obecné porovnání, kde jsi tento předpoklad nikde nedeklaroval. A tak věta, že PMA cosi (vícenásobné klíče, procedury, triggery..) neumí (řečená takto obecně) není pravdivá a musí tam být nějak specifikováno, že to neumí uživatelsky-přívětivě nebo jinak než přes SQL okno.
Ad klonování) ano, klonování je zláštní případ vložení, ale klonování a vložení se přece liší (v předvyplněném obsahu u klonování) - proč to tedy neodlišit?

spuštění SQL přes tlačítko: to pardon - moje chyba. Místo toho to platí u editace z výpisu u polí typu text.

ad klonování) také se mi to stalo, ale i přesto to nic neubírá na tom, co jsem napsal předtím. včetně toho, že uvedený zápis naznačuje, že chyba souvisí se skriptem PMA. pokud jsou tvoje slova, že je klonování náchylné k uživatelským chybám, tak tam, prosím připiš to "uživatelským".

ad porovnání rychlosti) nic proti víře, ale víra jednoho z porovnávaných programů nestačí - chtělo by to podpořit něčím konkrétním a objektivním, nejlépe testem s několika běžnými úkony pro většinu z nástrojů uvedených v té srovnávací stránce na anglické Wikipedii.

ad upozorňování na nové verze) vysvětlil jsi svůj postoj, ale zůstává faktem, že je subjektivní označit jeden způsob, který se autorovi zamlouvá, za dobrý a druhý za špatný.

ad počet vzhledů) na 6 vzhledech není špatného nic - ok. proč jsou tedy podbarvené barvou, která na té stránce konzistentně symbolizuje, že na tom něco špatného je? podle mě by zde to podbarvení být nemělo.

ad uvedené exportní formáty) v tabulce je tolik místa, kolik si ho uděláš. ještě jednou tě prosím, abys v rámci objektivity uvedl seznam všech těch 16 formátů. má kritika tohoto porovnávání je z tendenčnosti a předpojatosti a to v tomto případě je přesně to, co děláš - ty častěji používané neuvedeš, vybereš si ty nejexotičtější a ty pomluvíš. pokud uvedeš všechny, tendenčnost zmizí.

jde o to být schopen obhájit si každé svoje slovo.

úpravy přes dvojklik) co takhle dát malým písmem před začátek tabulky krátkou nápovědu, něco jako "Hodnoty v jednotlivých buňkách můžete upravit poklepáním na ně."? Vychytávkou by pak bylo uvádět to jen od nové session do okamžiku, kdy to uživatel poprvé použije.
Ještě mi tam vadí, že se opakuje JavaScript v onClick u každé buňky - kyne tak výstupní kód a dá se to přece efektivně udělat přes funkci (snad už je to změněné, ale u hlášek, že se je text dlouhý, ještě ne).
A těch dlouhých textů - tam je to svízelné. Změnit chování při poklepání na otevření nového okna?

p.s. jak už tady někdo uvedl: "i pouze česká verze" → "i ryze česká verze", "i samostatná česká verze" nebo "jednojazyčná česká verze"?

Jakub Vrána :

Upozorňování na nové verze: tady podle mě opravdu nejde o to, co se mi zamlouvá nebo nezamlouvá, ale co funguje nebo nefunguje. E-mailové notifikace z mé zkušenosti prostě nefungují, protože řada uživatelů vesele používá staré verze PMA. Informace o nové verzi přímo v programu na druhou stranu funguje, protože koho znám, ten používá aktuální verzi Admineru :-).

Exportní formáty: Vždyť je to uvedené jako jasná výhoda PMA, co bys ještě chtěl? Že to je podané takovým způsobem, který naznačuje, že jde o výhodu zcela nepodstatnou? No, tak to já vidím a byl to nejspíš záměr.

Úpravy přes dvojklik: Já nemám rád, když jsou v programu nějaké takovéhle instrukce, zbytečně to zasírá uživatelské rozhraní. I kdyby to nakrásně mizelo, tak s novou session to tam bude zase. Dlouhé texty už jsou dávno vyřešené pomocí AJAXu (to už bylo měsíc před vydáním 3.1.0).

David Grudl:

Ty formáty jsou vážně úlet. Kdybys tam dal "Excel, PDF a XML" a poznámku: PMA disponuje širší nabídkou exportních formátů, pokud bude o některý zájem, rád jej do Admineru doplním", bude to vypadat řádově lépe.

Jakub Vrána :

Ale vždyť tam všechny ty formáty uvedené jsou - konkrétně na odkázaném screenshotu, kde je i zajímavá informace o tom, že se formát XML mezi verzemi PMA kompletně změnil. Adminer má zase uvedeno, že export do dalších formátů lze přidat pomocí přizpůsobení.

David Grudl:

Díváme se fakt na stejnou stránku? Já tam vidím 2 obskurní formáty Texy a LaTeX (+ jakýsi odkaz) a posměšný komentář.

Podívej se na to jinak. S tím porovnáním sis dal dost práce. Ale pro koho jsi ho dělal? Pro nadšené uživatele Admineru? Nebo pro potenciální uživatele? První skupina se nad řádkem "Formáty exportu" pobaví, druhá podle toho zrelativizuje celou tabulku, což je škoda, celá práce tím padá.

Když ty výhody PMA napíšeš tak, jak by je napsal obhájce PMA, tak čtenář - současný uživatel PMA - bude mít pocit, že mluvíš jeho řečí a že si rozumíte. Porozumí lépe i argumentům pro Adminer, protože už v nich nebude hledat nějakou manipulaci.

David Grudl:

ps. teprve až při studiu zdrojového kódu stránky jsem dohledal, kde se věta o změně formátu XML objevuje. A to jsem obrázek samozřejmě rozklikl.

David Grudl:

Líbilo se mi, že se tu objevil kritický a přitom konstruktivní komentář, taková věc je vždy jen ku prospěchu věci. Ale s tím prvním odstavcem jsi mě zarazil, to přece nemůžeš myslet vážně. Pokud PMA něco neumí, tak to holt neumí. Nikdo to nevymyslel, nenaprogramoval, _není_ to tam. To se nedá nijak okecat. Bylo by směšné udělat aplikaci s jedním oknem pro SQL a tlačítkem a tvrdit, že to "umí" to stejné, co Adminer + PMA dohromady.

Podobně s tím JavaScriptem: pokud si cíleně degraduju funkčnost prohlížeče a tím se připravím o určitou vlastnost Admineru, tak to neznamená, že Adminer tu vlastnost nemá. Vůbec už bych to toho nepletl nějaká procenta - ty tvrdíš 5%, já tvrdím 0%, ale oba si cucáme z prstu, protože nikdo nemá informaci, kolik procent uživatelů Admineru (!) má vypnutý JavaScript.

kozotoč:

ten 1. odstavec... předpokládám že je to SQL okno a neschopnost PMA definovat více indexů) "Nikdo to nevymyslel, nenaprogramoval, _není_ to tam." - Souhlasím. "Neumí to." - Nesouhlasím. Protože to prostě není pravda. Tvrdit to znamená tvrdit, že neexistuje způsob, jak v PMA vytvořit více indexů - a ten existuje (jakkoli je primitivní). Nejsem nějaký právní zástupce phpMyAdminu - jde jenom o to, jak je to napsané. Stačilo by předefinovat onen popisek v porovnání z "neumí to" na "nemá to" a pak s tím nebudu mít problém.

ad vypnutý JavaScript) myslím, že sis předefinoval něco, o čem jsem nemluvil - tam, kde mluvím o 5 % uživatelů bez JS, tam to říkám a myslím obecně. No, a abych si "necucal z prstu" - to samotné číslo je těžké říct: např. podle http://www.sitepoint.com/forums/showthread.php?t=560659 jich je tu 4 %, tu "kolem 10 %"; podle jiných zdrojů jen mezi 1-2 %, přičemž to závisí na zemi, ale třeba tom, používají-li lidé internet z domova nebo z práce (kde je často JS vypnut v rámci firemní politiky). A ano, to, kolik % uživatelů má vypnutý JS, zatím nikdo neví, a zjistit to nevidím jinak než zapojením nějakého "sosáku informací", který by je posílal třeba na vrana.cz :)

David Grudl:

Přesně tohle mi připadá hloupé, dělat z drobných nuancí mezi "neumí" a "nemá" nebo mezi 100 % a 99 % zásadní otázky života a bytí :-)

Jakub Vrána :

Ještě bych prosil o bližší popis tohohle: „PMA selže při pokusu založit si vlastní tabulky nebo databázi“. Myslel jsem, že extra tabulky PMA si musím vytvořit sám a pak je jen uvést v konfiguraci. Co jsi tím měl přesně na mysli?

kozotoč:

Já zase myslel, že si INFORMATION_SCHEMA a tabulky v ní vytvoří PMA sám - ale už ho nepoužívám, takže přesně nevím (proto se ptám). Pokud si je vytváří sám a/nebo funguje nějakým způsobem omezeně bez nich, dalo by se to brát jako další objektivní nevýhoda oproti Admineru.

Kdyžtak by mohli poradit ostatní v diskuzi.

Jakub Vrána :

Ne, information_schema je meta-databáze (soubor pohledů), které zpřístupňuje přímo MySQL od verze 5. PMA s tím nemá nic společného. PMA pro plnou funkčnost potřebuje vlastní databázi (obvykle pojmenovanou phpmyadmin) a vlastní sadu tabulek (obvykle s prefixem pma_). Ty se musí ručně vytvořit a specifikovat v konfiguraci. Bez toho nefunguje spousta funkcí, což je ve srovnání několikrát zmíněno. Kupodivu se to týká i některých funkcí, pro které tabulky nejsou vůbec potřeba – např. propojení dat podle cizích klíčů InnoDB nebo schéma databáze.

Miloš Brecher:

Na Admineru u mě vzniká až nezdravá závislost - doufám, že Jakub bude v podpoře Admineru i nadále pokračovat!