Autor Zpráva
joe
Profil
Ahoj,

rád bych po pár letech nekamarádění s PHP zjistil, jaký je dnešní trend v psaní modelů v PHP. Je to pár let, co se tady objevila diskuse na ORM framework a nebyl jsem moc pro jeho použití.

Zajímal by mě způsob, jakým píšete modely? Důraz kladu na znovupoužitelnost, upravitelnost, jednoduchost a samozřejmě efektivitu samotných dotazů.

Pokud se podívám na nějaký zbastlený web, používá se například SELECT * ..., je v dnešní době ještě nutné se zabývat výpisem sloupců, které opravdu chci? V tomto mi ani ORM framework nepomůže, protože vybírá také všechna data (třeba Doctrine 2, pokud se neřekne jinak). Celkem se mi líbí nápad v NotORM, kde se při prvním požadavku zjistí, jaké všechny sloupce se potřebují a uloží se do cache (jenom jsem ještě nezkoušel jak by to fungovalo, kdyby to při každém požadavku chtělo jiné sloupce :-))
Joker
Profil
joe:
Maličko mimo hlavní téma, ale:
je v dnešní době ještě nutné se zabývat výpisem sloupců, které opravdu chci?
Kdysi dávno jsem měřil rozdíl mezi SELECT sloupce a SELECT * v MySQL.
Vyšlo z toho, že SELECT * může být i rychlejší.
Konkrétně v situaci, kdy tabulka má málo a případně navíc pevných sloupců anebo když potřebuji většinu sloupců tabulky.
(tuším že pro tabulku se třemi sloupci typu INT bylo SELECT * FROM tabulka rychlejší než SELECT sloupec FROM tabulka. Ale už to je pár let a přesně si nevzpomínám.)
joe
Profil
Protože tu je velmi málo reakcí :) a díky Jokerovu příspěvku soudím, že takovou možná až mikrooptimalizací je třeba se zajímat asi jen v případě, kdy web navštíví miliony lidí denně.

Od programátorů (nadšených programátorů) získávám kladný pohled na Doctrine 2, ale databázi vůbec neušetří, co se týká výběrem sloupců a počtem kladených dotazů.

Přijde mi, že dřív se kladlo důraz právě na onu optimalizaci výběru sloupců a najednou jakoby to všem bylo jedno, protože Doctrine 2 používá *, pokud se neurčí jinak.
Jan Tvrdík
Profil
joe:
protože Doctrine 2 používá *
Ono to u ORM (obecně) totiž dost dobře nejde jinak. Pokud nemáš komplet data, tak místo entity máš jenom partial entity, což je problém.
Alphard
Profil
joe:
že takovou možná až mikrooptimalizací je třeba se zajímat asi jen v případě, kdy web navštíví miliony lidí denně
I když se nepoužije ORM, je to myslím často velmi rychlým vývojem, kdy je sice snaha psát efektivně, ale zároveň raději obětovat nějaké zlomky procenta výkonu v zájmu lepší budoucí upravitelnosti. Zvlášť když je náprava velmi snadná.

Když prohlížím svém modely s ručně sestavovanými dotazy, mám vypsané sloupce v případech, kdy jich chci vybírat jen málo a neočekávám rozšíření. Vstupy do širokých výpisů a datagridů jsou většinou *. Tam, kde používám NotORM, a potřebné sloupce se nacachují automaticky je to samozřejmě lepší.

Zrovna tohle bych neřešil, od roku 2007 je na youtube známé video If programmers have make a plane a od té doby se myslím situace ve webovém prostředí spíš zhoršuje.
Jan Tvrdík
Profil
Alphard:
od té doby se myslím situace ve webovém prostředí spíš zhoršuje.
Proč zhoršuje?
Alphard
Profil
Jan Tvrdík:
Proč zhoršuje?
1. Neměl jsem to zobecňovat na celé webové prostředí, to se omlouvám, již stabilní projekty jsou v tomto ohledu snad bezproblémové.
2. Možná nedochází ke zhoršování, ale je to stabilní neideální stav, nevím.

U mnoha začínajících projektů na různé služby nebo menší specifické portály jsem se setkal s vývojem ve stylu: „Nevíme, jestli se to chytne, zkusíme co nejrychleji a s co nejmenšími náklady vytvořit nějakou beta verzi a teprve když když to někoho zaujme, budeme to vyvíjet a opravovat předchozí zkratky. Když ne, skončí to v koši.“
Sám jsem před dvěma lety 2 měsíce vyvíjel web v tomto stylu, nesplnil obchodní očekávání a za půl roku přestal existovat. Nikoho netrápí, že v kódu byla hromada nehezkých věcí, hlavně že to bylo rychle (dle požadavků zadavatele).

Teď jsem se dostal hodně mimo téma, ale závěr je takový, že někdy se problémy řeší až když se objeví a * ve sql dotazech bych neřešil.
Jan Tvrdík
Profil
Alphard:
Nevíme, jestli se to chytne, zkusíme co nejrychleji
Postavit nejdřív Minimum viable product je korektní byznysová strategie. Rozhodně bych netvrdil, že je horší stav. Naopak to považuji za výrazně lepší stav. Díky různým knihovnám a frameworkům (ať už serverových jako Nette, nebo frontendových jako jQuery a Twitter Bootstrap) jsi schopný napsat během jednoho víkendu něco, co jsi před 10 lety psal několik týdnů. Kdybychom se neustále neposouvali na vyšší úroveň abstrakce, tak pořád děláme v assembleru. Bylo by to sice pekelně rychlý, ale já bych v tom osobně weby psát nechtěl =)
Joker
Profil
Alphard:
je sice snaha psát efektivně, ale zároveň raději obětovat nějaké zlomky procenta výkonu v zájmu lepší budoucí upravitelnosti.
To je ale do jisté míry správně.
V dnešní době, kdy cena nového serveru odpovídá ceně několika dnů práce programátora, je obětování trochy výkonu výměnou za snazší údržbu a rozšiřování u většiny projektů správná strategie.
Samozřejmě je rozdíl mezi předchozí větou a chybnou implementací, kdy horší výkon není vyvážen žádnou výhodou, nebo dokonce zvolený postup má i další nevýhody a ještě navíc je pomalejší.

Už asi tři roky se chystám do svého zápisníku sepsat textík na podobné téma :-)

již stabilní projekty jsou v tomto ohledu snad bezproblémové
Ten požadavek na rychlost se netýká jen nových projektů.
V manažerském newspeaku tomu říkají Time To Market: Za jak dlouho od zjištění, že něco chceme (třeba protože s tím přišla konkurence), jsme schopní to mít reálně v provozu.

Hodně ale záleží na oboru, někde se používají věci na které X let nikdo nesáhl (a původní programátor je neznámo kde, dokumentace neexistuje a nikdo neví, jak to přesně má fungovat… To jen tak na okraj :) ), jinde se naopak dělají změny každou chvíli.
Alphard
Profil
Jan Tvrdík, Joker:
Pánové, moje hodnocení o špatném/ zhoršujícím se stavu byla reakce na otázky efektivity. Začal jsem citací „že takovou možná až mikrooptimalizací je třeba se zajímat asi jen v případě, kdy web navštíví miliony lidí denně“ a pokračoval v předchozí diskuzi o efektvitě vypisování sloupců. Výpočetní efektivita jde do háje, právě kvůi abstrakci, Nette, jQuery atd., určitě ale neříkám, že mi to jako celek nelíbí, právě naopak.

Už asi tři roky se chystám do svého zápisníku sepsat textík na podobné téma :-)
Rád si ho přečtu, ale nemyslím, že bys ho musel psát kvůli mně :-).
joe
Profil
Díky všem za příspěvky, ještě se k nim vrátím , nabízí se mi teď ale otázka, zda vůbec používat Doctrine 2, když například NotORM nebo NDTB z Nette je v dotazech efektivnější a co se týká psaní i podle mě rychlejší.
Jan Tvrdík
Profil
joe:
Pokud nevíš, proč používat Doctrine (resp. ORM obecně), tak ji nepoužívej. NDBT prakticky vždy položí lepší dotazy než Doctrine* a bude vyžadovat výrazně méně psaní. Ale není to ORM a nemá to entity. Já bych netřeba nechtěl psát jakoukoliv netriviální aplikaci bez entit, ale pokud je nepotřebuješ, tak nedává smysl používat jakékoliv ORM.

* viz taky benchmark ORM a DBAL (zdrojáky – jsou dobré i pro ukázku, jak se stejný problém řeší pomocí různých knihoven).

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0