Jediný problém vidím v tom, že se pro řazení nepoužije index. Efektivnější by tedy nejspíš u velkých tabulek bylo: /---sql SELECT * FROM employees WHERE roworder IS NOT NULL ORDER BY roworder; SELECT * FROM employees WHERE roworder IS NULL; \---

Ne, bavíme se o vypnutí kontroly jakýchkoliv unikátních klíčů. Může to být dobré k importu starých dat, u kterých mi nevadí, že jsou duplicitní, ale nová už chci mít správně. Ale osobně mi to přijde jako misfeature.

Pozor na to, že v InnoDB se kontrola unikátnosti dá pomocí unique_checks vypnout.

Vždyť save() nemusí ukládat vždy všechna data. Jak INSERT, tak UPDATE uloží jenom to, co uživatel explicitně nastavil.

Jde o to načíst data až když budou potřeba. Uvádím to v této diskusi už potřetí, ale pořád to asi není pochopitelné. Z pohledu uživatele to je transparentní - když se k datům pokusí přistoupit, tak tam prostě budou. Nástin kódu: class Customer { function __get($name) { $row = mysql_fetch_assoc(mysql_query("SELECT * FROM customer WHERE id = $this->id")); foreach ($row as $key => $val) { $this->$key = $val; } return $row[$name]; } }

Jakub říká, že ano, pokud se k němu někdo pokusí přistoupit. Takže se nenačítá, dokud to není potřeba.

Lazy loading znamená, že položka se načte, až když je potřeba. Takže se s Davidem shodneme. $customer->active vypíše skutečnou hodnotu nezávisle na uložení, ale načte se jen když je potřeba.

Proměnná sql_mode je nastavitelná i pro připojení, podobně třeba jako kódování. Takže si ji každý projekt může nastavit podle potřeby.

Klíčový je lazy loading. Defaultní hodnoty nového záznamu si načteš, až když to bude potřeba, stejně tak stávající hodnoty existujícího.

To je pro mě dost neintuitivní chování. new Customer by podle mě mělo vždy vytvořit nového zákazníka. Když mu nastavím existující ID, tak by uložení mělo skončit chybou. Takže získání stávajícího zákazníka bych dělal třeba metodou Customer::getById(). Ta může zákazníka načíst buď hned nebo odloženě až když to bude potřeba (tedy třeba nikdy).

Hodnota DEFAULT se dá použít i explicitně, např. SET jmeno = DEFAULT. Využitelná je tedy i u NULL sloupců.

Bohužel COUNT(*) rychlejší než SQL_CALC_FOUND_ROWS prakticky vždy je. Pokud je nad počítanými daty index, tak je to rychlé i s WHERE. Nejvíce se zrychlení projeví, když se z dotazu COUNT(*) podaří vyhodit tabulky, které pro zjištění počtu nejsou potřeba (vazby 1:1 LEFT JOIN nebo INNER JOIN na vždy existující hodnotu).

Opět vidím nařčení bez jakéhokoliv odkazu, který by ho dokládal. Svůj postoj jsem shrnul v předchozím příspěvku, tvá interpretace je mylná.

Struktura databáze by měla být dobře rozšiřitelná, měla by být výkonná a když umožní psát snadno SQL dotazy, tak tím lépe. Podobné narážky prosím příště včetně odkazu, který je podloží.

Já jako identifikátor používám anglický text nezávislý na počtu, tedy např. "%d window(s)". K identifikátoru může existovat i anglický překlad respektující počet, tedy "%d window" a "%d windows". Pro angličtinu se tedy mohou překlady tvořit stejně jako pro ostatní jazyky a fallback funguje také stejně.

http://php.vrana.cz/odkaz-na-predchozi-a-dalsi-zaznam.php

Popsal jsem to na blogu PHP triky.

1. V článku je použito width="100px" height="150px". To je chyba, na kterou jsem upozornil. 2. Je to stejné jako u ZIPu nebo u RARu. Čím větší komprese, tím může být soubor menší, ale zabere to víc času a paměti.

I varianta se samotným onload se dá napsat rozšiřitelně: function register_onload(f) { var oldOnload = window.onload; window.onload = function () { if (typeof oldOnload == 'function') { oldOnload(); } f(); } } V naprosté většině případů je navíc lepší konkrétně událost onload vůbec nepoužívat (protože se vyvolá hrozně pozdě, až po nahrání všech externích objektů) a místo ní prostě funkci zavolat na konci dokumentu před značkou /BODY.

Atributy IMG WIDTH a HEIGHT se uvádí v pixlech bez jednotek, nebo v procentech. Jednotka px se používá ve stylech. PNG je bezztrátový formát a číslo je tedy opravdu jen úroveň komprese (stejně jako třeba u ZIPu). Nevyjadřuje tedy kvalitu, ta je vždy stejná.

Místo dvojice funkcí ob_get_contents a ob_end_clean lze použít ob_get_clean. Zároveň se tím ušetří proměnná $html.

Špatně jsem se v tom dotazu (přes několik šířek článku) zorientoval. Podmínka není uvnitř poddotazu, takže ten není korelovaný. U mého dotazu na testovacích datech navíc MySQL z nějakého důvodu nedokáže u vnějšího dotazu použít index, takže by ho bylo potřeba položit v PHP a do MySQL poslat dotazy dva.

Rozebíralo se to třeba na http://php.vrana.cz/vypnuti-magic_quotes_gpc.php#d-6187

Pro nastavení $r, $g a $b by se dalo použít min() a max(). Pro vytvoření barvy by se dalo použít sprintf("%02x").

Pokud má dotaz vybrat nejlepší týmy ze čtyř divizí, tak nebude fungovat správně, pokud budou mít dva týmy ve stejné divizi stejný počet bodů. Je to rozebráno na http://php.vrana.cz/ziskani-radku-s-maximalni-hodnotou.php

Kromě rychlého řešení, které navrhuje Karel Dytrych (které se ale špatně používá, pokud kromě ID chceme získat i něco dalšího), je možné ještě jedno: SELECT * FROM clanky WHERE name IN (SELECT name FROM clanky GROUP BY name HAVING (count(*)>1)) Je to o řád rychlejší než korelovaný poddotaz uvedený v článku.

Pro synchronizaci struktury databáze lze použít také http://phpminadmin.sourceforge.net/

Od PHP 4.3.10 a PHP 5.0.3 je k dispozici také modifikátor %F, který nehledí na lokální nastavení.

Další více než vhodné použití je u jednorázových hesel, které třeba banky posílají pomocí SMS.

Hlavní nevýhoda output bufferingu (pokud je přes celou stránku a bez druhého parametru funkce ob_start) je ta, že stránka se do prohlížeče začne posílat až v momentě, kdy se na serveru celá sestaví. Pro uživatele to je nepříjemné v tom, že první kousek stránky vidí až v momentě, kdy se mu už posílá celá. Lepší uživatelský dojem se navodí tím, když se stránka posílá průběžně.

Pokud data ošetříme funkcí addslashes (a není použita direktiva magic_quotes_gpc), tak jsou uvnitř databáze v čisté podobě. Ošetřit je na výstupu funkcí stripslashes je tedy chyba, protože sežere lomítka, která by v textu měla zůstat.

1. Zpětných lomítek před s* je moc, správně by tam měla být dvě (a stačilo by i jedno). 2. Funkce je koncepčně špatně. Data bychom měli ukládat (a vevnitř aplikace používat) nezávisle na výstupní vrstvě, takže "přeošetření" uvnitř aplikace není potřeba.

Kód nerespektuje fakt, že jeden skript může být v prostředí webové aplikace spuštěn paralelně vícekrát. Viz http://php.vrana.cz/atomicita-operaci.php PHP funkce tempnam() tento fakt respektuje.

Ve výrazu (?=.*d) chybí zpětné lomítko.