ARCHIV

Napadl mě ještě další důvod, proč vypnout zobrazování chyb: některé chybové hlášky jsou tak upovídané, že vyzradí např. verzi software (dejme tomu MySQL), kde se "to" stalo. Pokud je to verze s nějakou známou bezpečnostní dírou, mohli bychom nevědomky usnadnit život útočníkovi.

Jinak, ten příklad s obrázky jsem moc nepochopil. Proč se to ukládá do db? Nestačilo by projít složku a pokud bude neprázdná tak obrákzy načíst a zobrazit? Jistě, je to až řádově pomalejší, ale zase je to mnohem jednoduší na správu (např. vymažu obrázek... a on se nezobrazí). No, asi to byl jenom příklad, pak to chápu.

Ahoj,
právě že to tak dělám ;-)... Názvy obrázků v databázi a v adresáři, jehož název je odvozen od ID článku/newsy/... ke kterému patří. Přeci jen zákazníkům běžně nedávám přístup na FTP a metodu s názvy v db používá většina firem. Tebou navrhovanou metodu jsem také zkoušel, ale jaxi napsal, je to pomalé. Znám dokonce many, kteří cpou přílohy do BLOBů v databázi, ale mám proti tomu hodně důvodů.
Chyby loguji do texťáku, který si jednou za týden posílám na mail cronem, nebo stáhnu jej ftpkem...
BTW: Doufal jsem, že první komentář bude od Tebe, ale nedoufal jsem v kladný. Už píšu Smarty šablony a občas používám i PHP Peary, takže snad jednou...

Ale vždyť to bylo kladný... jen jsem se prostě zamyslel, že by to šlo dělat i jinak, to je všechno ;-)))

Práci s BLOBy jsem popisoval v seriálu o PHP a pomalé to bylo ukrutně. Nemluvě už o tom, že musíš spoustu věcí hlídat a je to veliký. Čili ruce od toho pryč...

Měl jsem na mysli něco jako Simple Picture Gallery Manager, jež DB taky nepoužívá.
http://spgm.sourceforge.net

Já jsem právě byl překvapen, že to bylo kladný, protože tahle druhá půlka je IMHO podstatně slabší, než první.
Do databáze je to pomalé i proto, že na to není dostatečně dimenzovaná cache (to jen pro informaci pro ostatní) a protože kvůli tomu musíš napsat mnoho kódu kolem jen abys to ošetřil...
http://spgm.sourceforge.net ... Děkuji, neznal jsem a kouknu na to.

Jsem docela skeptický k této střední vrstvě. Podle mě je použitelná jen pro naprosto triviální projekty. Složitější projekty je rozumné psát na míru použité db. Příklady: Vím-li, že budu pracovat s MySQL, těžko mohu spoléhat na trasakce. Pokud na serveru běží MySQL 4.0, nemohu si dovolit subqueries. Píšu-li pro Firebird, tak v jistých situacích raději použiji prepare/execute než query. Atd, atd.

No, on je to argument s obou stran. Čím specifičtější (nebo složitější?) je projekt, tím častěji (a asi je to dobře) se začíná výběrem databáze a pak se naplno využívají její možnosti. Ostatně, proto tolik databází máme.

Ale přesto mi to přijde jako šikovná věcička - třeba pro to ladění a tak.

....Ostatně, proto tolik databází máme.....

ne, tolik databazime mame proto, protoze se vyrobci snazi nekompatibilitou vuci jakemukoliv standartu si udrzet zakazniky - a programatori nebo uzivatele, kteri to jeste nepochopili tomu rikaji 'moznost volby'....bylo by to legracni, kdyby to nebylo k placi....

Trochu mimo, ale třeba MySQL je whodná v nasazení na weby, protože díky tomu, že dost věcí neobsahuje je velmi rychlá. Standardy? Hmm a PL/SQL je standardizované? Subqueries (ty možná ano)? Transakce? Triggery? Views? Myslím, že ne. Nehledě k tomu, že PostgreSQL umožňuje použít na stored procedury nejen svůj PL/SQL, ale třeba Python, Perl, C, ... Pokud budu potřebovat vymoženosti, které MySQL neobsahuje, použiji jednoznačně PostgreSQL, které nejenže mám slušně osedlané, ale je druhé nejrozšířenější na webhostinzích, protože k čemu mi je, když použiji Oracle, když zákazník nebude schopen/ochoten zaplatit za server xx tisíc VZK navíc a můj produkt se stane neprodejný...
Každý programátor chce psát to nejlepší, ale každý se musí uživit, což znamená používat to, co je rozšířené.

no tak kdyz uz jsme u tech standartu, tak je treba rici, ze ten problem lezi samozrejme na tom tzv. standartu = SQL. Ten koho to napadlo, ze se deskriptivni jazyk povysi na standart pro praci s daty a jejich uskladnenim by mel byt okamzite zastrelen. Takovy standart, s kterym nelze nic poradneho delat jen primo vybizi vyrobce k tomu, nadefinovat si v tom nesmyslu sva vlastni vylepseni. A konci to tim, ze se pise vyse pojednavane software pro mezivrstvy.

Pisi o tom, protoze mi na zacatku toho serialu chybi prave mala uvaha, jak je mozne ze to tak daleko doslo, ze se vubec o nejake te mezivrstve musi vubec mluvit.

To ze se dovime, jak pouzivat nejake funkce nejake mezivrstvy je jiste chvalyhodne, ale kdy uz se prestaneme konecne opajet tou technicitou nejakeho softwaroveho prostredku misto abychom byli rozhorceni, ze je vubec nutne, aby nejaky takovy prostredek vubec vzniknul.

Ano, svet uz je takovy, ale to snad neznamena, ze nebudeme kazdou minutu poukazovat na ty nesmysly, ktere nam programatorum ztezuji zivot a hlavne na to , jak k nim doslo.

Ten priklad z tim Office je priznacny. To software jen zdrzuje denne miliony lidi od prace, ale to neodradi OpenOffice lidi od toho, ten nesmysl vylepsovat.Ano, office je rozsirene software a my to hned tak nezmenime - a samozrejme to musime jako programatori v nasi praci zohlednit - ale proboha nam prece musi byt denne jasno, ze je to srot!!!!! A zrovna totez plati pro tu mezivrstvu.

A proc mame nekolik vzajemne nekomatibilnich prekladacu jazyka C, proc mame nekolik verzi Fortranu, Pascalu, Javy, Assembleru, ...? Nebude to tim, ze od zacatku kazdy vyvijel to svoje a alespon jakys standard vznikl pozdeji, diky kteremu je alespon spolecny prunik vlastnosti a zakladnich prikazu? Budme radi alespon za to...

JE to k pláči. Jenomže svět už je takovej. Můžu já za to, že v T-SQL (což je odnož SQL pro M$ server) umím jak když bičem mrská prostě proto, že jsem se to kdysi musel naučit? Když mám totéž dělat na Oraclu, tak to "neumím" (tzn. trvá mi to třeba trojnásobek času jen proto, že neznám do detailů dialekt jazyka). Bude-li se ale hovořit o nových projektech, bude naprostá většina programátorů prosazovat ne to, co je nejlepší, ale to, co umí. Ruku na srdce, je to většnou tak.

Proto nezbývá než souhlasit s tím, že kdyby se splňovaly standardy (např. SQL), problém popsaný výše by přestal existovat a pak bychom si vybírali databáze ne podle toho, jak se v nich snadno píše kód pro procedury a triggery (čti: jak snadno to umím JÁ), ale podle toho, co ta databáze umí.

Zhruba to odpovídá problému boje mezi M$ Office a OpenOffice.Org. Kdyby existovaly 100% kompatibilní otevřené formáty souborů, byla by hybnou silou vývoje kvalita kancelářských balíků. Takhle je tou silou (ne) schopnost sekterářky přečíst nabídku pod myší.

Jej, to jsem se ale rozvášnil ;-)))

Hezký... dva komentáře výše jsme psali s Markem "do sebe". Je až komické, jak jsou si podobné.

No přiznejme si, že tak 95% projektů, které píšeme patří k těm menším. Na velký projekt by asi PHP nestačilo výkovově, tam je asi vhodnějším nástrojem jsp+servlet, nebo Python. Třeba i proto, že v PHP je režie, co stránka, to připojení k db serveru, pak odpojení a pokud budou těchto požadavků řádově tisíce v každý okamžik, bude brzdou především to, že PHP je interpretovaný jazyk. Ale je to můj soukromý názor. Pro naprostou většinu běžného vývoje tato mezivrstva zpříjemní vývoj a následné nasazení.

Možná menších, ale už ne triviálních. Dovolím si nesouhlasit, že "co stránka, to připojení k db serveru". Pokud používám persistentní spojení, tak se nová spojení k databázi zbytečně nezavírají a znovu neotvírají.

Subqueries jsou potřeba celkem často, ale pokud je na hostingu starší MySQL, nemohu je použít. Občas se hodí Views, ale se starší MySQL mám opět smůlu. Velice užitečné mně přijde generovat XHTML element select podle datového typu enum (v případě MySQL). Nejsem si jistý, jak moc by byl kód přenositelný pod jinou db. Potřebuji-li zařídit integritu dat, musím v MySQL použít zamykání tabulek, jinde bych použil transakce. Takových případů, kdy SQL píšu s vědomím konkrétní db, by se našla celá řada.

EZ SQL má použití právě a jen u triviálních projektů, kdy si vystačím s jednoduchými SELECT a INSERT. Bohužel hodně projektů, které vytvářím, se řadí už do kategorie menší, nikoliv triviální.

Mohu se zeptat autora, co ho vede k tomu, že lokálně píše aplikaci pro PostgreSQL, když na hostingu běží MySQL? Přijde mně to jako zbytečné zadělávání si na problémy. Mně stačí řešit rozdíly mezi MySQL 4.0 a 4.1.

Po Pythonu pošilhávám, nikoliv z důvodu výkonnosti, ale kvůli čistotě jazyka. PHP4 má šílený "objektový" model, register_globals a gpc_magic_quotes jsou jen pro zlost.

Jednoduche... Autor pouziva par aplikaci, ktere primo zavisi na PostgreSQL a mit na locale pustene dva servery povazuje za plytvani strojovym casem a RAM (maje jako desktop 700MHz Durona). Na dost hostinzich "uz" je k dispozici i PgSQL, takze prevod neni nutny.

No jestli jsou trivialni projekty jako redakcni system a webshop nevim, ale prave z techto mnozin znam takove, ktere pouzivaji prave tuto knihovnicku. Mimochodem, ja mam upravenou verzi tehoz, ktera ma navic $db->start_transaction a $db->stop_transaction, ktera na MySQL zamkne tabulky a vsude jinde nastartuje transakci. Krome toho si to upravuji, aby dalsi zakazala indexovani a konecna to cele preindexovala, preci jen je-li indexu vice, tak vkladani vetsiho mnozstvi dat by bylo pomale a tato cesta je rychlejsi (mluvim o importu v radu 10.000 rakdu), na coz taky budu muset udelat vlastni fci.

Inspiroval jste mě napsáním si metod, které nahrazují alespoň trochu transakce pro MySQL. Sám používám vlastní třídu, která zatím jednoduše zapouzdřuje volání MySQL, ale postupně ji rozšiřuji o užitečné funkce.