Vyšel phpMinAdmin 1.8.0
Školení, která pořádám 
Hlavní změnou viditelnou na první pohled je v nové verzi nástroje phpMinAdmin zobrazování SQL kódu u všech provedených příkazů – tedy ve výpisu tabulky a v informačních a chybových zprávách. Chvíli jsem uvažoval, jestli a jakým způsobem tuto vlastnost implementuji (za konzultace děkuji grafikovi), ale vzhledem k tomu, že v důsledku vedla ke zjednodušení kódu, tak jsem ji nakonec použil. Miluji opravování chyb metodou zjednodušování kódu… Pro obarvení SQL kódu doporučuji zapnout zvýrazňování syntaxe v SQL příkazu (které je externí a proto ve výchozím nastavení vypnuté).
Další viditelnou změnou je nezalamování řádků ve výpisu tabulky (dlouhé texty jsou oříznuté, takže si od toho slibuji zpřehlednění tabulky) a zobrazování počtu nalezených řádek tamtéž. Užitečnou vlastností pro neveřejné weby je automatické přihlášení realizované předáním parametru ?username= (heslo předat nejde, lze ho ale určit pomocí konfigurační direktivy PHP mysql.default_password nebo mysqli.default_pw).
Implementoval jsem také podporu pro události, což je jedna ze dvou syntaktických novinek v MySQL 5.1. Schválně jsem se podíval i na konkurenční phpMyAdmin verze 3, který tuto novinku také implementuje, a kladu si otázku, který z těchto dvou nástrojů je vlastně ten funkčně bohatý a který jednoduchý a rychlý. V různých diskusích často slýchám, že uživatelé postrádají nějakou funkčnost, ale když se zeptám jakou, tak si většinou na nic nemohou vzpomenout. Já jsem si naopak udělal seznam toho, co mi chybí v phpMyAdminu:
- Cizí klíče nelze definovat přes více sloupců.
- Třídění podle více sloupců je možné jen přes databázový dotaz.
- Události, uložené procedury a spouště lze modifikovat jen přímým zadáním SQL příkazu (je nutné znát syntaxi, k dispozici není ani odkaz na dokumentaci).
- Uložené procedury a funkce nelze volat jinak než přímým zadáním SQL příkazu.
- Data ve sloupcích typu blob lze stáhnout jen pomocí transformací.
- Odkazy podle referencí se vytvoří opět jen po vytvoření dodatečných tabulek.
- Nelze měnit definici pohledů.
Samozřejmě vím, že v phpMinAdminu také leccos chybí (v diskusi se můžete vyjádřit, co konkrétně chybí vám), ale divím se, že phpMyAdmin implementuje nové vlastnosti tak ledabyle (a „nové“ jsou třeba už čtyři roky).
Z dalších novinek phpMinAdmina 1.8.0 už jen možnost řadit podle COUNT(*) a přidání italského a estonského překladu – všem překladatelům děkuji za aktualizaci.
Diskuse
OndroNR:
je aj insi sposob ako zapnut JUSH okrem zaskrtnutia checkboxu v Upravit?
Jakub Vrána 
:
U SQL příkazu je políčko Zvýrazňování syntaxe, které nastaví cookie highlight=jush. Takže alternativou je nastavit tuto cookie (třeba v auto_prepend_file).
Jakub Vrána : 
v6ak:
Existuje dnes alespoň jeden důvod pro PhpMyAdmina? :-) Myslím, že jsem s tím pomalým a velkým správcem právě skončil...
v6ak: Kajman:
"už jen možnost řadit podle COUNT(*)"U starších verzí (např. v demu) bude asi třeba řadit podle aliasu `COUNT(*)` nebo pořadím sloupečku.
Jakub Vrána :
Aha, to jsem vůbec nevěděl, že ve starších verzích MySQL přímo podle COUNT(*) řadit nejde. Vrácená chyba je "Invalid use of group function".
Díky za upozornění, v SVN jsem to opravil tak, že se použije `COUNT(*)`.
Jakub Vrána : Jakub Vrána :
SourceForge.net přemigroval na novější verzi MySQL, která navíc podporuje InnoDB tabulky, takže v demu je konečně vidět většina vlastností phpMinAdmina. Uloženými procedury počínaje a schématem databáze konče.
Mám z toho radost.
Jakub Vrána : Michal Ševčík:
Líbilo by se mi, kdyby se dal SQL dotaz psát přímo u výpisu dat v tabulce, případně u výpisu struktury tabulky. Jde o to, že ve výpisu rovnou vidím názvy sloupců a nějaká data, což je někdy užitečné.
Každopádně díky za perfektně odvedenou práci!
kozotoč:
Do toho, co phpMyAdmin neumí a phpMinAdmin jo, můžeš, Jakube, připsat i řazení sloupců tabulky přímo při editaci její struktury. Tahle featurka v phpMinAdminu je velice sympatická.Petr:
Z toho, co má phpMyAdmin navíc (a z toho, co jsem stačil z obou adminů vyzkoušet):* editace více záznamů (nezjistil jsem, že by to v MinAdminu šlo)
* zkopírování (duplikování) tabulku - to beru jako funkci, která (z těch ostatních, následujících) se používá nejčastěji a považuju za dobré/vhodné/důležité ji mít implementovanou.
* to samé: přesun tabulky do jiné databáze (pod (volitelně) jiným jménem)
* když chci v phpMyAdminu vložit nový záznam, který je buď stejný jako nějaký jiný již existující v dané tabulce, nebo lišící se jen o málo, můžu ho dát editovat a pak v jednom "udělátku" dole zvolit "vložit jako nový záznam".
* upravovat privilegia pro konkrétní databázi (v phpMinAdminu jsem nenašel - možná by šlo jednoduše dodělat jako <select> u změn "globálních" privilegií, co tam už jsou)
* navigace stránkování pod výpisem tabulky v <select>u (můžu vybrat *jakoukoli* stránku z dlouhých výpisů, ne jen tu, která se mi nabídne jako odkaz)
* export více nebo všech databází najednou (využití: méně často, ale už to nastane, tak se hodí to mít)
blbůstky jako:
*CHECK/ANALYZE/REPAIR/OPTIMIZE/FLUSH TABLE (přes odkaz) a ALTER TABLE ORDER BY (přes select nebo input),
*u úpravy tabulky: PACK_KEYS, CHECKSUM, DELAY_KEY_WRITE,
*u exportu: kromě INSERT INTO a UPDATE i REPLACE INTO (pro případ vytvoření exportu do téže tabulky jinde, kde chci jenom "přeplácnout" data uložená tady),
obecně řečeno, v několika případech je phpMinAdmin "o jedno kliknutí pozadu" před phpMyAdminem. Třeba by se mi líbilo mít textareu pro SQL dotaz i ve stránce, která se objeví po kliknutí na tabulku (v současné verzi z ní není odkaz ani na vložení nových dat, stejně tak by se v ní hodila i informace o datu poslední změny nebo hodnoty autoindexu).
p.s.
1) K čemu je *užitečné* Schéma databáze?
2) V některých případech (Upravit SQL dotaz) se dotaz přenáší v URL. Je nějak ošetřena velikost toho dotazu?
3) Jak je těžké přidat export do ZIP nebo GZ? Pokud je to na pár řádek, pak si myslím, že by stálo za to o tom zauvažovat, protože u extra velkých databází *je* podstatný rozdíl mezi velikostí (potažmo dobou stahování) zazipovaného a nezazipovaného exportu.
4) Nejnovější verze phpMyAdmina (a hlavně, MySQL 5) umožňuje u tabulky taky zadat MIME typ, jakousi transformaci pro prohlížení a její parametry. Moc se to asi nevyužívá, ale má to i phpMinAdmin?
Jakub Vrána :
Díky za tipy. Něco je v TODO, něco okomentuji zde:
Hromadnou editaci se chystám udělat, ale jinak, než phpMyAdmin – u každého sloupce půjde zvolit, zda se v něm u všech záznamů má nechat původní hodnota, nebo nastavit nová.
Klonování záznamů bych chtěl taky udělat, ale opět jinak – to, že chci záznam zduplikovat, je lepší zvolit ještě předtím, než úpravy provedu. Protože jinak na to zapomenu a původní záznam si přepíšu novými hodnotami.
Oprávnění lze v phpMinAdminu nastavit na jakékoliv úrovni – jen je potřeba je ručně vyplnit. Pro databázi např. ve tvaru db.*.
Zobrazují se odkazy na dvě předchozí, dvě následující, první a poslední stránku. Kdy je potřeba odkaz na jinou stránku?
Export více databází najednou možný je. Ve starších verzích bylo možné exportovat všechno, od 1.7.0 lze vybrat, které databáze se mají exportovat.
Ohledně těch blbůstek – já sám je nepoužívám, tak se mi je tam nechce dávat.
V exportu lze zvolit UPDATE, který provede INSERT INTO … ON DUPLICATE KEY UPDATE. REPLACE je příliš agresivní (může smazat dva záznamy a vložit jen jeden).
Co se „kliknutí pozadu“ týče – phpMinAdmin má minimalistický design, což mimo jiné znamená, že odkaz pro vložení záznamu je jen na stránce s výpisem dat, protože pracuje s daty a nikoliv se strukturou tabulky.
Stejně tak auto_increment není natolik zásadní informace, aby musela strašit u struktury tabulky.
Odkaz na SQL příkaz je na každé stránce a přímo <textarea> nemá jinde co dělat.
Schéma databáze je užitečné pro získání představy o propojení tabulek. Samozřejmě hlavně v případě, že se používají cizí klíče. Důležité je taky vědět, že se tabulky dají přetahovat…
Délka URL nijak ošetřena není, uživatelé chybového IE mají s extrémně dlouhými dotazy smůlu.
Komprimaci exportu mám naplánovanou, stejně tak je potřeba doplnit tuto možnost do importu.
MIME typ je výmysl phpMyAdmina, s verzí MySQL to pokud vím nemá co dělat. Do phpMinAdmina nic takového rozhodně dodělávat nebudu – je to na půl cesty mezi nízkoúrovňovou správou databáze a plnohodnotným administračním rozhraním. Na plnohodnotné administrační rozhraní je lepší použít např. http://www.adminer.cz.
Jakub Vrána : Jakub Vrána :
Na stránku s přehledem databází jsem přidal výpis Tabulky a pohledy, kde jsou o nich uvedeny základní informace a kde s nimi lze provádět údržbářské operace. Zároveň jsem tyto informace odstranil z title v levé navigaci.
Je to vidět v SVN a v demu.
Jakub Vrána : Petr:
Update: Možná si už vymýšlím, ale od věci by nebylo ani pozměňování dat v AJAXu, což považuju za nejrychlejší (nejpohotovější) a tím pádem i uživatelsky nejpřívětivější funkci a argument pro jeho používání. Nevím, jak by to fungovalo pro velké bloby, ale pro malá data je to ideální a ultimátně lepší než úmorným stylem "označit, dát upravit, opět zobrazit výpis a nalistovat na stránku, kde jsem v prohlížení skončil". Jakub Vrána :
Zvážím to. Sám to obvykle řeším tak, že si editaci otevřu do nového tabu.
Jakub Vrána : Crempa:
Tak pod tohle se podepisu, mit moznost editace pres ajax je perfektni napad.. uz ted pouzivam MinAdmina namisto desktop reseni a tunelovani a tohle by znamenalo odinstalaci HeidiSQL :-) v6ak:
AFAIk je problém pomocí AJAXu uploadovat soubory, ne?
v6ak: Petr:
myslel jsem, že 'minimální' u MinAdmina mají být: instalace, velikost a počet souborů, nároky a omezení. Ne (nutně) design (tj. že má vypadat 'chudě') nebo navigace (tj. že používané věci, které by mohly být na jedno kliknutí, musí být nutně na 2 nebo 3 kliknutí). Na tom se snad shodneme, ne?UPDATE u exportu) Takže to, co je označeno jako "UPDATE" dělá INSERT...? To by asi chtělo dát to title="nápověda, že to dělá tohle". (tip: Pokud bys použil toliko "INSERT .. ON DUPLICATE KEY UPDATE", nemusel byl rozšiřovat překladovou tabulku a jako minimum by to stačilo.)
ad další informace u tabulky) autoincrement může být důležitý, když mám testovací a vývojovou databázi, na jedné jsem nucen např. pro potřeby testování něco vložit a poté to z důvodu synchronizace obou databází "dát do původního stavu". vím, že je to "o jeden odkaz dál(pozadu)", ale to je právě to, co tím mám na mysli.
textarea) s tím, že "jinde nemá co dělat" s tebou nesouhlasím, ale respektuju to. Když už jsem u toho, má MinAdmin historii SQL příkazů?
ještě mě napadá, že odkaz velký nadpis phpMinAdmin by asi neměl vést na (externí) stránku projektu ale na hlavní stránku minAdminu (z ní pak může vést odkaz na projekt na sourceforge nebo tvoji) - můj dojem je, že ten odkaz mate, tj. zavede uživatele jinam, než si myslí, že se dostane. (prostě nějak odlišit, že je to externí odkaz..)
ad blbůstky) já si občas všímám, jestli některá data jsou tzv. "unoptimized" nebo "overhead" a pak prostě kliknu na OPTIMIZE- nebo REPAIR TABLE. nic víc, nic míň. musím uznat, že jsem nikdy neshledal, že by těch pár bajtů navíc dělalo nějaký (třeba rychlostní) problémy, na druhou stranu u databází jiných uživatelů to nemusí být pár bajtů ale pár MB a pak to třeba může být problém. a když to zobecním, tak "vo tom to je" - myslet nejen na to, co většinou využívám, ale i na to, co mohou pravděpodobně využívat i ostatní.
z toho hlavního je pramálo co vytknout.
ještě k tomu designu. co se jeho týče (a to můj subjektivní názor), tak:
k obrázkům bych ještě přidal ikonku pro odkaz "vypsat" (tabulku).
Můžu ti rovnou dát i jeho base64_decode parametr (jak to používáš ve zdrojáku) - a sice je to:
R0lGODdhEgASALMAAAQCBJyanOzu7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAEgASAAAEL1DISau9OOvNewVgqIESKZjfFAJqWrJi2aorO582jqL062e1nGdILHYCyKRymYwAADs=
:-)
obdobně to platí ještě v několika místech, kde záhlaví tabulky tabulku neesteticky roztahuje (auto_increment - na to popravdě nevím, jaká by byla ikona)
Jakub Vrána :
Minimalismus znamená i to, že mi nebudou překážet informace, které nutně nepotřebuji. AUTO_INCREMENT (stejně jako třeba COLLATE) není natolik zásadní, aby překážel u struktury tabulky. Ale když ho chci zjistit, tu možnost mám.
K UPDATE v exportu title doplním, díky za tip.
Historie SQL příkazů k dispozici není, opět to jde nad rámec zamýšlené funkčnosti.
Odkaz na nadřazené objekty je k dispozici v drobečkové navigaci. Odkaz z „loga“ asi měnit nebudu, i když mám pocit, že to tak ve starší verzi dokonce bylo (a odkaz na domácí stránku chyběl úplně).
Používání OPTIMIZE je obvykle pouze obsese – ha, tabulka má 1 KB navíc, rychle ji musím optimalizovat. V naprosté většině případů to pro správu databáze není potřeba.
Za ikonu díky, ale rozhodně ji nepoužiji. Když jsem např. studenty dřív nechával pracovat s phpMyAdminem, tak vůbec netušili, že ikona vedle názvu tabulky plní nějaký jiný účel než samotný název tabulky.
Zalamovaný Auto Increment mě taky trápí, ale třeba A_I (což nesmyslně používá phpMyAdmin, který má místa dost) by snížilo přehlednost.
Jakub Vrána : Petr:
Ještě z toho, na co jsem zapomněl odpovědět:ad hromadná editace) phpMyAdmin nabídne k editaci záznamu(ů) vždy všechny sloupce; po potvrzení zanalyzuje, co se změnilo oproti původním hodnotám a podle toho spustí (a uživateli zobrazí) dotaz, kde nezměněné sloupce jsou vynechány. Pokud to v MinAdminu uděláš tak, jak si myslím, že to uděláš, bude to bez toho nutného dotazu navíc, rychlejší a vlastně i logičtější.
koukám, že nejsem jediný, komu SQL okno u stránky s tabulkou přijde praktické.
ad stránkování) u výběru stránky přes select můžu vybrat *jakoukoli* stránku dlouhého výpisu v jednom kroku. stylem "dvě předchozí, dvě následující" se k např. 125. stránce doklikám napotřiašedesáté. Vím, že jde zadat offset, ale to není tak pohodlné (nebo se mi nechce počítat 125*30). (odpověď na otázku, kdy je to potřeba: např. něco hledám v nějaké obsažné tabulce a vím, že je to třeba na 10. stránce od konce. nebo zhruba ve 3/4 výpisu. nebo zhruba v 1/3 výpisu. zvolit to přes select je jednoduché. Naklikat tam přes "předchozí/další" je horor. asi tak.)
blbůstky (pokud bys změnil názor) mohou být na samostatné stránce (stejně tomu je i u MyAdmina). Tam by tolik "nestrašily" :-)
kozotoč:
Máš tam čas od času XHTML chybky:*v drobkovém menu: & nahraď &
*v exportu - tlačítko "Export" obalit např. do <p>...</p>
*u vytváření nové tabulky - <script>...</script> vycpat <!-- ... --> nebo <![CDATA[!> ... <!]]!>
*SQL příkaz - dtto
*pozměnit indexy - dtto
*oprávnění - za odkazem "vytvořit uživatele" přebývá </p>
*vytvořit proceduru (když se otevře a není definován žádný parametr) - v tabulce parametrů chybí sekce <tbody>
Jakub Vrána :
Paráda, díky za pečlivou práci. Všechno jsem to opravil.
Jakub Vrána : kozotoč:
na hlavní stránce databázemísto nadpisu "Procedury"
Základní operace
pozměnit..
schéma..
Ostatní databázové entity
vytvořit pohled
vytvořit proceduru
vytvořit funkci
?
Mít nadpis "procedury" pro procedury a funkce mi přijde divné.
Jakub Vrána :
Anglicky to je Routines, Procedures a Functions, takže jsem jenom změnil překlad Routines na Procedury a funkce.
Jakub Vrána : kozotoč:
Popř. to nazvat "Procedury a funkce"Dále:
*databázové funkce by mohly mít zatrhávátko "DETERMINISTIC" (a i ostatní atributy - nevím, jestli ještě nějaké jsou)
*jak jsou na odlišeny pohledy (views) od tabulek? myslím: tak, že to vidím na první pohled. Title je nemotorné, šlo by to stylem (kurzíva apod.)?
Jakub Vrána :
Volby funkcí jsem dal do TODO, totéž platí i pro pohledy.
Kurzívu pro pohledy jsem zkusil, ale vypadá to divně. Na první pohled to stejně není patrné a dělá to v tom seznamu optický zmatek.
Jakub Vrána : JirkaK:
Ve slušné společnosti se view prefixují.. třeba v_moje_view už z názvu je pak patrné že se jedná o view aniž bych se musel dívat na typ objektu..kozotoč:
Další praktická zkušenost:Zkusil jsem v phpMinAdminu exportovat databázi a importovat ji na jednom typickém hostingovém phpMyAdminovi.
Házelo to chybu, že musím být superuživatel, abych vyexportovaný soubor mohl spustit. Při zběžném pohledu do .sql souboru to pravděpodobně způsobují úvodní příkazy, které např. nastavují velikost paměti pro zpracování. Méně zkušeným uživatelům by to potenciálně mohlo způsobit problémy, že by nevěděli, co s tím dělat.
Mohl bys sis to, Jakube, taky prakticky vyzkoušet?
Jakub Vrána :
Vím o tom. Problém je v tom, že se na hodnotu nastavované direktivy nedá spolehnout. Udělám z toho volbu.
Jakub Vrána : Jakub Vrána :
Ono to je ještě trochu složitější – lokální volba se kvůli bugu http://bugs.mysql.com/bug.php?id=22891 ignoruje a globální začne platit až při další konexi (empiricky zjištěno). Takže jsem tam nechal jenom tu lokální, čímž odpadl problém s právy a až MySQL fixne ten bug, tak to i začne fungovat.
Jakub Vrána : Karel:
Nahodil jsem téma phpMinAdminu, když jsem se bavil s kamarádem, který dělá v jedné nejmenované webhostingové firmě. Překvapil mě tím, že o něm ví a dokonce že vážně uvažují, že by ho nasadili - jako jeden z možných nástrojů pro správu webu pro jejich zákazníky (jako alternativu k phpMyAdminu, který tam budou mít i nadále).Co ty na to říkáš, Jakube?
Máš nějaké námitky, až/pokud bude soukromá firma tvůj skript používat tímto způsobem? Jsou na phpMinAdmin vůbec nějaká omezení ohledně tohoto použití?
Jakub Vrána :
Licence dovoluje komerční i nekomerční použití zdarma. Já budu opravdu rád, když se phpMinAdmin bude používat co nejvíc, takže vítám i tento záměr.
Jakub Vrána : Karel:
Tak. Nové zprávy.1) Už o tom neuvažují. Už se na to v nejbližší době chystají (a prý něco pro minAdmin „upravují”).
2) Ten nejmenovaný hosting, na kterým má minAdmin být, se jmenuje flyweb.cz.
štíhloprd:
Ad Indexy: U definice klíčů jde v návrhu vybrat 2-a-vícekrát PRIMARY. Takže by *možná* byla lepší konstrukce, kdy u typů by šlo vybírat pouze z INDEX, UNIQUE a FULL TEXT a PRIMARY by byl realizován jako <input type="radio" ../>Kde jde v návrhu tabulky definovat cizí klíče (pokud zatím žádné definované nejsou)?
Jakub Vrána :
Pokud to myslíš tak, že by vedle každého indexu byl ještě <input type="radio">, tak by to byl zmatek, protože bys primárnímu klíči musel určit ještě typ indexu (který by se potom ignoroval, takže by to bylo matoucí). Jako možnost bych viděl, že by se primární klíč definoval jen jednou (třeba na začátku tabulky), někdy si ale můžeš vzpomenout, že primární klíč vyměníš s nějakým unikátním, což by se dělalo špatně. Nechám to tedy tak, jak to je.
Cizí klíče lze definovat pouze u InnoDB tabulek na stránce se strukturou tabulky v oddílu Cizí klíče.
Jakub Vrána : ia:
Mne osobne trochu chýba zobrazovanie času, ktorý SQL požiadavka potrebovala na vykonanie. Jakub Vrána :
A kde? Jen u ručního SQL příkazu nebo i u příkazů spuštěných phpMinAdminem?
Jakub Vrána : ia:
Myslím, že pri každom SQL príkaze. Nech to je jednotné. Mohlo by to byť napríklad za výpisom SQL príkazu v zátvorke, resp. niečo podobné...Inak musím poznamenať, že phpMinAdmin je veľmi šikovný a podarený nástroj. Veľká vďaka.
Diskuse je zrušena z důvodu spamu.
© 2005-2024 