| Autor | Zpráva | ||
|---|---|---|---|
| blizzboz Profil |
#1 · Zasláno: 31. 1. 2010, 23:40:36
včera som si napísal knižnicu ktorá vytvorí formulár podľa databázovej tabuľky, prvky formulára vyberá podľa typu stĺpca v DB tabuľke, varchar-om priradí inputy tinyint-om s veľkosťou jeden znak priradí checkboxy text-om a blob-om priradí textarea atď, programátor si tieto controly potom môže aj upravovať mazať a meniť. ak bol vybratý konkrétny riadok alebo časť riadku tak knižnica tento formulár aj vyplní dátami.
ku controlom moja knižnica pridáva aj labely a naplní ich názvom stĺpca. problém je v tom že názvy stĺpcov dávam väčšinou v angličtine takže som si napísal triedu ktorá labely prekladá. akurát neviem kam mám tieto dáta uložiť. či do databázy, XML súboru, YAML, INI alebo priamo do PHP súboru ako pole? čo je najrýchlejšie a najvhodnejšie? |
||
| mattyZEM Profil |
#2 · Zasláno: 31. 1. 2010, 23:43:16 · Upravil/a: mattyZEM
INI, XML i YAML bych co se týče rychlosti okamžitě zavrhl.
|
||
| Alphard Profil |
#3 · Zasláno: 31. 1. 2010, 23:49:40
Tak ini bych určitě nezavrhoval kvůli rychlosti, ale je spíš pro konfiguraci.
blizzboz: Je nutné to překládat? Bude to matoucí. Pokud jde o nějaký administrační nástroj, tak bych rychlost nepřeceňoval, bude využíván minimálně, takže použijte, co se vám nejlíp zabuduje. Pole v samostatném souboru by podle mě klidně stačilo. |
||
| mattyZEM Profil |
#4 · Zasláno: 31. 1. 2010, 23:52:00
Alphard:
„Tak ini bych určitě nezavrhoval kvůli rychlosti, ale je spíš pro konfiguraci.“ To jistě, ale to už bych právě kvůli rychlosti spíše použil TXT než .ini... |
||
| blizzboz Profil |
#5 · Zasláno: 1. 2. 2010, 00:02:02
Alphard:
No to práve že nie je administračný nástroj len sa mi nechce vždy nanovo písať celý formulár ajtak len kopíruje dáta v tabuľke a niektoré aplikácie obsahujú aj 20 Formulárov tak som sa trochu inšpiroval Ruby On Rails a napísal som si triedy ktoré mi generujú formuláre podľa DB tabuliek. Btw: neni lepšie ten PHP kód toho poľa uložiť priamo do databázy? a potom vykonať cez eval? Predsa len databáza má aj nejakú cache a niektoré dáta sa ukladajú priamo do pamäte takže by to mohlo byť teoreticky rýchlejšie ako includovanie PHP súboru. |
||
| mattyZEM Profil |
#6 · Zasláno: 1. 2. 2010, 00:04:25
Jedna milisekunda sem, jedna milisekunda tam...
|
||
| blizzboz Profil |
#7 · Zasláno: 1. 2. 2010, 00:07:19 · Upravil/a: blizzboz
mattyZEM mno ale tú jednu milisekundu vynásob počtom užívateľov, ktorí práve v jednej chvíli používajú tvoju aplikáciu.
|
||
| mattyZEM Profil |
#8 · Zasláno: 1. 2. 2010, 00:09:05
blizzboz:
„vynásob počtom užívateľov, ktorí práve v jedej chvíli používajú tvoju aplikáciu.“ 3 milisekundy sem, 3 milisekundy tam... |
||
| blizzboz Profil |
#9 · Zasláno: 1. 2. 2010, 00:22:30
mattyZEM:
je veľa ďalších faktorov ktoré ti tie 3ms vynásobia až na 500 ms a to už je výrazné spomalenie. citujem Davida Grudla Skutečně se ukazuje, že jedním z největších zabijáků výkonu PHP je načítání velkého množství souborů. |
||
| AM_ Profil |
#10 · Zasláno: 1. 2. 2010, 01:24:37 · Upravil/a: AM_
blizzboz:
„neni lepšie ten PHP kód toho poľa uložiť priamo do databázy? a potom vykonať cez eval?“ eval je mezi profesionály dost neoblíbená konstrukce co se týče výkonu, run-time optimalizací a transparentnosti. Skoro vždycky to jde řešit i jinak. Nevím, jak ten tvůj form vypadá, ale já bych labely pro ty pole natáhl přímo v souboru s administrací, jestli to máš jako třídu, dělal bych to asi takhle:
$form = new myDBForm('users'); //předpokládám zde, že strukturu tabulky si odněkud natáhne konstruktor
$form->username->setLabel('Uživatelské jméno');
$form->password->setLabel('Heslo');
$form->render();
|
||
| Carrot Profil * |
#11 · Zasláno: 1. 2. 2010, 02:16:27
mattyZEM:
„INI, XML i YAML bych co se týče rychlosti okamžitě zavrhl.“ „To jistě, ale to už bych právě kvůli rychlosti spíše použil TXT než .ini...“ Vůbec nevíš o čem mluvíš, takže raději mlč. blizzboz: „čo je najrýchlejšie a najvhodnejšie?“ V daném objemu dat bude rozdíl rychlost nezměřitelný. Zvolil bych XML - Jeho flexibilita je největší a čtení i generování jednoduché. „je veľa ďalších faktorov ktoré ti tie 3ms vynásobia až na 500 ms a to už je výrazné spomalenie.“ To číslo 3 jsi vynásobil konstantou vesmíru? Nebo je to nějaký násobek Planckova času? Poděl se s námi, co může obyčejné čtení textových dat prodloužit stokrát - ideálně včetně procesních flow-grafů prosím. |
||
| blizzboz Profil |
#12 · Zasláno: 1. 2. 2010, 03:39:24 · Upravil/a: blizzboz
AM:
v niektorých prípadoch je použitie eval nevyhnutné napr. keď chceš spustiť PHPkód uložený v databáze, alebo v reťazci a do reťazca ho môžeš načítať z rôznych zdrojov. keď už je PHP interpretovaný jazyk (bohužiaľ) prečo by som nevyužíval jednu z mála výhod ktoré mi ako dynamický jazyk poskytuje? „Skoro vždycky to jde řešit i jinak.“ ako by si teda riešil vykonanie PHP kódu načítaného z databázy? a k tomu príkladu čo tam máš tak ja to riešim cez špeciálnu triedu LabelTranslator ktorá je potomkom Hashtable a implementuje rozhranie ILabelTranslator: $form = new Form();
$connector = new FormDataConnector($dataSource);
$connector->actualRecord = $dataSource->fetch();
$labelTranslator = new LabelTranslator();
$labelTranslator->add('username', 'Meno používateľa');
$labelTranslator->add('password', 'Heslo');
$connector->registerLabelTranslator($labelTranslator);
$connector->assignTo($form);
echo $form;ale to nerieši môj problém. tieto 2 riadky mi v PHP kóde úplne zavadzajú: $labelTranslator->add('username', 'Meno používateľa');
$labelTranslator->add('password', 'Heslo');určite tie dáta patria niekde inde, nie do PHP súboru keď má formulár len 2 položky tak to nevadí ale niektoré formuláre majú aj 10ky položiek. programový kód by mal (v ideálnom prípade) obsahovať len aplikčnú logiku. elegantnejšie je spraviť si triedu implementujúcu rozhranie ILabelTranslator (napr. XMLLabelTranslator), ktorá bude slovníky načítať priamo z XML súboru (alebo z iného zdroja) a ten môžem použiť aj pri iných formulároch. |
||
| blizzboz Profil |
#13 · Zasláno: 1. 2. 2010, 03:46:04
Carrot:
a ty vieš odkiaľ že to bude trvať len 3ms ? |
||
| Nox Profil |
#14 · Zasláno: 1. 2. 2010, 08:10:44 · Upravil/a: Nox
blizzboz:
Nesmyslně řešíš nanosekundy, bottleneck bude imho úplně jinde...prostě použij INI nebo pole Edit: právě jsem změřil svůj INI soubor a jeho parsování (60 položek) zabere 0.13ms Pro zajímavost 1 třída se mi parsne za 3ms, takže aby se ti to dostalo aspoň na tu 1 třídu (kterýma nejspíš nešetříš) bys potřeboval 1400 položek, nechci tě podceňovat, ale tipuju že máš spíš míň JGadrow BBGameZone: "Once the interpreter encounters an include, include_once, require, or require_once language construct, it utilizes the filesystem to open the specified file. There is some overhead associated with this, but not very much as the OS is VERY efficient at performing this sort of operation." + David Grudl taky píše >>> "Doporučuje se používat konfiguraci uloženou ve formátech ini a xml, jelikož parsery pro tyto soubory jsou nativně podporovány v PHP a jsou velmi rychlé. Dokonce tak rychlé, že naparsovanou konfiguraci se nevyplatí ani kešovat." Pokud to tedy chceš uber rychlé tak použij memcached.... ale je to podle mě zbytečné „je veľa ďalších faktorov ktoré ti tie 3ms vynásobia až na 500 ms a to už je výrazné spomalenie.“ To je nesmyslný argument - pak bys neměl používat přiřazení, když to pak umocníš svým uber číslem pak to dá 4 sekundy ;) „mno ale tú jednu milisekundu vynásob počtom užívateľov, ktorí práve v jednej chvíli používajú tvoju aplikáciu.“ Tahle jednoduše to imho nefunguje, málo až středně složitá aplikace by pak při 2-3 návštěvnících vůbec nejela a jak víme, tak to tak není |
||
| blizzboz Profil |
#15 · Zasláno: 1. 2. 2010, 08:25:20 · Upravil/a: blizzboz
Nox:
„Tahle jednoduše to imho nefunguje, málo až středně složitá aplikace by pak při 2-3 návštěvnících vůbec nejela a jak víme, tak to tak není“ to bol len príklad, ale ajtak čím efektívnejší kód tým menšia záťaž na server, a o to v prvom rade ide aby sa jedna stránka nenačítala pol dňa. "Doporučuje se používat konfiguraci uloženou ve formátech ini a xml, jelikož parsery pro tyto soubory jsou nativně podporovány v PHP a jsou velmi rychlé. Dokonce tak rychlé, že naparsovanou konfiguraci se nevyplatí ani kešovat." asi teda použijem XML |
||
| AM_ Profil |
#16 · Zasláno: 1. 2. 2010, 09:47:34
blizzboz:
> v niektorých prípadoch je použitie eval nevyhnutné napr. keď chceš spustiť PHPkód uložený v databáze, alebo v reťazci a do reťazca ho môžeš načítať z rôznych zdrojov. keď už je PHP interpretovaný jazyk (bohužiaľ) prečo by som nevyužíval jednu z mála výhod ktoré mi ako dynamický jazyk poskytuje? > > „Skoro vždycky to jde řešit i jinak.“ > ako by si teda riešil vykonanie PHP kódu načítaného z databázy? Mě by hlavně nejdřív někdo musel strašlivě praštit do hlavy, abych ukládal PHP do databáze. To tam prostě podle mě nepatří. - bezpečnost bude lehce pofidérní (převzetí kontroly nad databází bude mít automaticky za následek převzetí kontroly nad PHP, když už je špatně proč si to dělat ještě horší), - přístup k databázi je pokud vím řádově 10x pomalejší, než přístup k souborům - samotná potřeba použití eval() je taky odrazující - proč to nevyužít? já to vidím spíš jinak. Když už je to interpretovaný jazyk, má mít pro úplnost tuto funkci. Ale opět - rychlost, bezpečnost a transparentnost kódu jsou v opozici. A zkus si třeba eval() procházet debuggerem - to nevím jestli vůbec PHP umí. Je to tedy nakonec stejně otázka vkusu, funguje samozřejmě obojí, ale výše uvedené důvody jsou pro mě dost pádné k tomu mít PHP v souborech a ty includovat. |
||
| blizzboz Profil |
#17 · Zasláno: 1. 2. 2010, 23:19:35 · Upravil/a: blizzboz
AM:
o tom že by PHP kód nemohol byť uložený v databáze počujem prvý krát, a bolo by to dosť veľké obmedzenie, väčšinou sa články ukladajú do DB a u väčšiny článkov možnosť s pušťať PHP vypínam ale keď chceš mať v článku nejaké dynamické časti tak čo potom? nie všetko sa dá riešiť pomocou šablónovacieho systému sú situácie kedy je elegantnejšie do článku vložiť priamo PHP. ja mám vo svojom CMS možnosť spúšťať aj PHP. argument že útočník získaním prístupu k databáze získa aj možnosť spúštať PHP kód je IMHO dosť nezmyselný, analogicky by si si mohol zamurovať vchod do bytu len preto aby si tak znemožnil vstup do bytu potencionálnym zlodejom. |
||
| Kacko Profil |
#18 · Zasláno: 1. 2. 2010, 23:59:03
blizzboz:
Ukládal bych do DB a výsledek bych kešoval. Předpokládám, že aplikaci budete stejně kešovat, takže to rychlostně vyjde skoro nastejno. Výhodou bude snadná editovatelnost textů, také vám stačí zálohovat pouze DB. Záleží, co preferujete. Uniklo mi kde se tu vzal problém s eval().. Jinak třída LabelTranslator může automaticky vědět, co se má zobrazit po klíčem "username" a dle toho se zachovat. Také netuším proč to vše neřeší třída Form, která může využívat třídy FormDataConnector, když se dá předpokládat, že jí bude využívat vždy(?). Osobně bych to řešil takto: $form = new Form(); $form->setDataSource($dataSource); $form->setLabelTranslator(new LabelTranslator()); // Idealne by Form() tento translator vyuzival defaultne echo $form; |
||
| AM_ Profil |
#19 · Zasláno: 2. 2. 2010, 00:05:21
blizzboz:
„o tom že by PHP kód nemohol byť uložený v databáze počujem prvý krát,“ uložený tam být může, jak jsem řekl, je to vlastně otázka vkusu, technicky to samozřejmě lze. Pokud chci mít k dispozici luxus psát si do článků PHP, udělal bych nějakou cache, která články bude ukládat do souborů. Vyhnu se tím časové náročnosti práce s DB a funkci eval(). „argument že útočník získaním prístupu k databáze získa aj možnosť spúštať PHP kód je IMHO dosť nezmyselný, analogicky by si si mohol zamurovať vchod do bytu len preto aby si tak znemožnil vstup do bytu potencionálnym zlodejom.“ to už je spíš jako zapouzdření v jazyce HQ9++ :) když už jsme u přirovnání, tak je to spíš takto: když budu pracovat na tajném projektu pro vládu, nenechám si doma na stole dokumenty k němu, pro případ, že by mi vykradli hůře střežený byt. tj. když někdo převezme kontrolu nad MySQL (stačí drobná chybka, se kterou si hacker stáhne soubor s heslem), je to pohroma samo o sobě, ale když mu dám zároveň šanci infiltrovat PHP skripty, apokalypsa webu se stane prakticky nevyhnutelnou. |
||
|
Časová prodleva: 14 let
|
|||
0