Příspěvky

61

Odkladiště / Re: Neexistující smlouva s O2

« kdy: 09. 06. 2011, 12:23:02 »

A nevím jak by se řešilo to že ses bez platne smlouvy připojil přes jejich modem na internet.

no nijako:) on to pripojenie neukradol, ani podvodnym sposobom ho neziskal. ze mu ho oni z vlastnej poskytli bez zmluvy, to je ich problem. to mas to iste, ako ked ti v obchode omylom nieco zauctuju za podstatne nizsiu cenu a zistia to dodatocne. daju ta na sud pre kradez?

tiez na druhej strane, ak ja ako zakaznik (riadne a platne zazmluvneny) pouzijem sluzbu nechtiac, moj argument "ja som nechcel" mi nepomoze. zmluva hovori jasne, sluzbu som pouzil, zaplatit musim. reciprocne to musi platit podla mna tiez. nic nepodpisal, zakon neporusil, neplynu mu zavazky. prevdzkovatel sluzby mu poskytol svoju sluzbu z vlastnej vole bez zmluvy. bodka:)

62

Odkladiště / Re: Neexistující smlouva s O2

« kdy: 09. 06. 2011, 10:04:30 »

neviem, ako je to u vas, ale u nas je clovek zo zakona povinny zaplatit pohladavku a nezrovnalosti riesi v reklmacnom konani. cize ak je zmluva platna, si povinny zalpatit za fakturu, aj ked si nespokojny a nespokojnost musis riesit reklamaciou. ine riesenie je len prejavom ich dobrej vole. ak ju maju, da sa to aj inak. ak som napriklad ja mal nejaky problem s fakturou, poziadal som telefonicky fakturacne o odklad uhrady do vyriesenia. oni mi to povolili, vec sa vyriesila a na oboch stranach prebehlo to, co prebehnut malo. ak je v tvojom pripade zmluva neplatna, neni o com:) zrejme nebudes povinny im nic platit. ale odbornik na pravo, duplom na to vase, nie som. zisti si u pravnika, co s tym mozes:) inak podobne haluze s kurierom a teleofonicky dojednanou zmluvou ficia aj u nas. aj tak ale zmluvu musim podpisat kurierovi a on ju mnou podpisanu odovzda operatorovi. az vtedy je platna. pokial tvoj operator nedisponuje zmluvou, ktoru si podpisal, asi si moze ist piskat:) ale opakujem, porad sa radsej s pravnikom.

63

Vývoj / Re: PHP profiler nasaditelný za plnej prevádzky

« kdy: 03. 06. 2011, 17:43:34 »

skus http://mirror.facebook.net/facebook/xhprof/

aktualne sa s tym hram a vyzera to byt relativne dobre:)

64

Vývoj / Re: Jak detekovat "mobilní návštěvníky" webu a přesměrovat je na m.example.com

« kdy: 27. 05. 2011, 08:28:10 »

Hlavní web udělat univerzálně a odkazy z něj selektivně skrýt odkazy pomocí atributu media v CSS. Nebo udělat univerzálně celý web, což je úplně nejlepší řešení.

no ty si tomu dal!


@GiBo: mozno existuju mnohe ine databazy user agentov, ale ja pouzivam a som velmi spokojny s vysledkami http://wurfl.sourceforge.net/ pozri na to a implementuj. spolahlivost rozpoznania je velmi vysoka...

65

Vývoj / Re: MySQL a použití sloupce ID

« kdy: 06. 05. 2011, 15:37:43 »

ani vediet, co si predstavujes pod pojmom "fungovalo to spolahlivo". MySQL vie od verzie 5.0 pouzit v specialnych pripadoch aj dva indexy s tym, ze ich merguje, ale pochybujem, ze to bol tvoj pripad... Urcite je lepsie spravit jeden index na oba stlpce v prepojovacich tabulkach v takom poradi, aby to databaza mohla vytiahnut z indexu a nemusela sahat do dat. V pripade MyISAM su data kesovane len na urovni systemu, takze sa nevyhnes systemovym volaniam, narozdiel od pristupu do indexu.

ak to nechces vediet, nepoviem. ale ak by si chcel, povedal by som, ze som na vlastne oci videl, ako mi aj druhy index vyberal priamo data podla indexu a neprechadzal vsetky zaznamy vybrane prvym indexom. ale keby si precitas poriadne celu debatu, vedel by si, ze myslim a predstavujem si presne toto:)

66

Vývoj / Re: MySQL a použití sloupce ID

« kdy: 06. 05. 2011, 11:16:23 »

Takovy explain bych chtel videt. Typuju ze ukazoval USING WHERE, coz je chyba pokud chces selektovat pomoci indexu. Zalezi ale jake dotazy jsi s tim provadel, no

zial, uz si ho nepamatam, ale viem, ze to fungovalo spolahlivo... s tym using where si nie som isty

Nevim jestli ted myslis me osobne, v kazdem pripade ja jsem zastance MySQL a mam stejny nazor jako ty - pokud nekdo spatne navrhne databazi a pak mu to nefunguje poradne a nadava na MySQL, tak je to spatne.

Tim selskym rozumem jsem mel na mysli predevsim to, pochopit jak databazovy server funguje a podle toho psat SQL dotazy a delat navrh db, a ne jen vzit nejakou teoretickou prirucku o 'normalizaci' (coz ja ani poradne nevim co je) a ridit se podle nejake prirucky.

A pokud mi je sloupec s auto increment ID k nicemu a v aplikaci ho nepouziju a mam moznost jednoznacne identifikovat radek tabulky pomoci jineho klice (treba slozeneho z vice sloupcu), tak se muzu na ID vykaslat a MySQL s tim NEMA nejmensi problem. A pokud nekdo tvrdi ze ma, tak at laskave odkaze na nejakou analyzu.

myslel som teba a kazdeho, kto pracuje s databazami bez akychkolvek predchadzajucich teoretickych znalosti len na zaklade ziskanych praktickych skusenosti (= sedliacky rozum ). do teoretickych znalosti neratam navody na spravnu pracu s mysql ako takym. ak to citas a riadis sa podla toho, je to fajn. ale ono k tomu treba vediet aj malinko viac. netvrdim, ze ja som guru, ale viem, ze precitat si cosi okolo normalizacie mi len pomohlo. zistis zase o cosi viac, ako pristupovat k tvorbe db. nestaci len chapat, ako funguje mysql server. treba pochopit aj zasady datoveho modelovania a aspon trosku treba poznat zasady normalizacie.

67

Vývoj / Re: MySQL a použití sloupce ID

« kdy: 06. 05. 2011, 07:26:55 »

Druhy moc nepomuze - prvni umi vyhledat vsechny radky co maji c1=0, a ty pak nezbyde nez jeden po druhem prochazet a filtrovat podle c2 - bud tabulkou nebo druhym indexem (ale to uz vyjde skoro nastejno, v obou pripadech to bude hodne tisic pristupu na disk). Kdezto index na (c1,c2) by udelal intervalovy dotaz a vratil primo radky vyhovujici _obema_ podminkam najednou, v pripade dotazu COUNT(*) by mohl rovnou vratit cislo.

Tusis absolutne spatne.

Staci si nechat ukazat EXPLAIN a uvidis, ze pokud mas 2 indexy tak je to neco uplne jineho nez kdyz je 1 index na obou sloupcich.

zaujimave, ze mne vzdy druhy zaberal a explain mi to potvrdil.

Co se tyce ID cloupecku na kazde tabulce, neexistuje nic co by me (nebo autora dotazu) prinutilo cpat id tam kde to neni potreba. A v dany moment nemusi nikoho zajimat 'normalizace' nebo co, zdravy selsky rozum rika, ze pokud auto increment id nebudu pouzivat, tak ho tam prece nedavam.

BTW je zcestne definovat ID jako AUTO INCREMENT INT, protoze tam vzdy budou ulozene jen kladne hodnoty, takze UNSIGNED INT je optimalnejsi; pro rozsahle tabulky ale nemusi stacit a je lepsi treba BIGINT. U mensich tabulek zas bigint je zbytecne velky. Zalezi kolik radku v tabulce kdo ocekava.

to je prave ten najvacsi problem 98% webovych aplikacii. ze kaslete na normalizaciu a riadite sa len sedliackym rozumom:) a potom databazy vyzeraju, ako vyzeraju a vsetci kydaju na mysql, ako keby ono mohlo za to, ze pouzivate iba sedliacky rozum namiesto pravidiel tvorby datoveho modelu. mysql mozno neni mega db. mozno neni vobec db, to nech si riesi ini inde. urcite to ale je nastroj, ktory si vie poradit datami a pokial dodrziavas iste pravidla (napr. normalizacia), vie to byt aj vykonny nastroj. ja by som sa teda v pripade databaz stranil sedliackeho rozumu, lebo to je najvacsi a najcastejsi zabijak databaz a je to najsignifikantjesi markant toho, ze autorom db je neskuseny amater, ktory je len mudry vo forach:)

To, že je jednoduchý primární klíč úplně na nic není tak úplně pravda.
- některé ORM systémy ho potřebují
- vývojem aplikace může dojít k tomu, že daný vztah bude nějak zobecněn např. typem vztahu. Tím se z 1:1 relace stane n:m relace. Pokud bude předem existovat primární klíč, bude úprava aplikace jednodušší.

ak dojde k tomuto, podla mna bol zle navrhnuty datovy model a aplikacia pred vyvojom nepresla dostatocnou analyzou. su sice hranicne okolnosti, kedy k podobnemu javu moze dojst, ale tie sa daju minimalizovat preciznou pripravou

68

Vývoj / Re: MySQL: kedy používať ID stĺpec ako PRIMARY KEY s auto_increment a kedy nie

« kdy: 05. 05. 2011, 16:47:04 »

Muzes, ale nedela to co by clovek potreboval (poradi za WHERE nehraje roli, psal jsem o poradi v indexu, a to je neco uplne jineho). Napriklad tabulka o 10 milionech radku, sloupce c1 a c2 obsahujici nahodne nuly a jednicky, index na c1, index na c2, dotaz 'SELECT COUNT(*) FROM tbl WHERE c1=0 AND c2=0'. Prvni index vybere korektne radky s c1=0, ale druhy index uz nepomuze, tech nekolik milionu radku s 'c1=0' se bude muset prochazet jedna po druhe. Pokud se mylim tak me opravte..

tusim sa mylis:) ak mas tie indexy spravene dobre, musi sa ti uplatnit aj ten druhy

69

Vývoj / Re: MySQL: kedy používať ID stĺpec ako PRIMARY KEY s auto_increment a kedy nie

« kdy: 05. 05. 2011, 15:12:02 »

To obecně nestačí - pokud mám např. WHERE na 3 atributy, tak potřebuji jeden index obsahující všechny 3, nikoliv 3 jednotlivé indexy. Navíc musejí být na začátku - index na (c1,c2,c3,c4) umí dotaz na (c1,c2) a (c1,c2,c3), ale ne (c2,c3,c4).

to plati len na zlozene indexy. pokial mas 3 samostatne indexy, mozes ich odkazovat v lubovolnom poradi. ak mas zlozeny kluc, plati to, co si napisal, ze sa na ne mozes odkazovat len v poradi od prveho zlava postupne...

70

Vývoj / Re: MySQL: kedy používať ID stĺpec ako PRIMARY KEY s auto_increment a kedy nie

« kdy: 05. 05. 2011, 14:56:28 »

precitaj si nieco o normalizacii db, mozno ti to pomoze.

su ludia, co si urputne obhajuju pchanie indexov (tym myslim samostatnych primary keys s auto incerement) do kazdej tabulky. ano, je to pohodlnejsie, ale podla mna je to nesystemove a neprogramatorske a nedatabazove:) kombinacia dvoch unikatnych klucov bude vzdy len unikatnym klucom, takze tam je treti kluc uplne zbytocny. zapamataj si, ze kazdy index ti zbytocne zvacsi tabulku. ak budes mat mrte dat, aj jej udrzba ta cosi bude stat. preto som ja osobne zastancom aplikacie normalizacie, premysleneho navrhu datoveho modelu a rozumnych indexov.

a ako tu uz chalani vyssie spomenuli, rozhodni sa podla toho, ci ten index realne a relevantne potrebujes. ak ho nikdy zmysluplne nevyuzijes, nepchaj ho tam. na vsetko trivialne ti staci unique key zlozeny z dvoch cudzich klucov;)

potom sa skus skamosit aj s 'explain'. to ti tez velmi ulahci zivot a pomoze pri vyrabani vykonnych selectov.

71

O serveru Root.cz / Re: Editace příspěvků v diskuzi

« kdy: 27. 04. 2011, 15:01:19 »

pecko: To je pravda. Jako nejrozumnější mi zatím přišel návrh od Ondry Nováka.

suhlasim

72

O serveru Root.cz / Re: Editace příspěvků v diskuzi

« kdy: 27. 04. 2011, 14:53:33 »

Jak sám píšeš: "Co je psáno, to je dáno"  .

to pisal petr, ja som mu dal len zapravdu:) ja som skor pisal, ze co je editovane, to uz nema nikto vidiet:) (myslim to povodne)


myslim, ze radsej by sme mali petrovi hadzat nejake navrhy na riesenie editacie namiesto handrkovania sa na sposoboch z(ne)viditelnovania hluposti tak, aby sa editacia znova vratila na povodne miesto:)

73

O serveru Root.cz / Re: Editace příspěvků v diskuzi

« kdy: 27. 04. 2011, 14:48:55 »

@asdasd: predstav si situaciu, ze omylom zverejnis nieco, co si (este) nechcel (vobec nemyslim urazky a pod. skor predcasne alebo nespravne info). co s tym potom? stale je podla mna lepsie neukazovat vsetko a raz za cas sa tym zaoberat, ako sa nezaoberat vobec, ale sposobovat obcas niekomu problemy:) wiki je myslim o niecom inom ako diskusie na root:)

74

O serveru Root.cz / Re: Editace příspěvků v diskuzi

« kdy: 27. 04. 2011, 14:43:59 »

Co takhle dát možnost upravit poslední odeslaný příspěvek, pakliže na něj neexistuje odpověď? Vždyť detekovat novou odpověď v diskuzi umíte ne?

podla mna tiez dobry napad. alebo povolit editovat len do 5 minut od odoslania poslednej upravy, pokial za nim nepribudol dalsi prispevok.


znova sa potvrdzuje, ze moznosti je vzdy viac, len rootaci si vybrali tu najlahsiu (zial aj najhlupejsiu)

75

O serveru Root.cz / Re: Editace příspěvků v diskuzi

« kdy: 27. 04. 2011, 14:33:05 »

@asdasd: ale ja som teba pochopil:) viem presne, co si myslel. ale zamysli sa. aky to ma vyznam a ake su dosledky? naco ja potrebujem vidiet (akokolvek html obalene) historiu tvojich uprav jednoeho prispevku? vypisovanie vsetkych verzii (akokolvek html obalenych) je stale v konecnom dosledku zobrazovanie "samostatnych prispevkov" a preto sa vyznam editacie v podstate straca. aj ked, povedzme si narovinu, 99% je lenivych uzivatelov a ti si nikdy ani len nevsimnu, ze take cosi by tam bolo a pre nich je to jedno. ale zo systemoveho hladiska to jedno nie je. editacia je editacia a co editovane, to uz nema nikto za normalnych okolnosti vidiet. ale zase, ako pise petr, co je napisane, to je dane. kompromis je, "editujte si, ale vas niekto obvini z niecoho, mame tu moznost si to ako admini overit, prip. to posunut policii". bezneho cloveka nemusi zaujimat historia editacii...