reklama

Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: [1] 2 3 ... 228
1
Jenom bych upřesnil, že neustále píšete, že selhávají funkce flock() a file_put_contents() atd., ale ve skutečnosti selhává váš kód. Ty funkce fungují správně, chyby jsou ve vašem kódu.

2
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 16. 10. 2019, 20:19:44 »
Právě proto, že může být vedoucí oddělení, kde nejsou zaměstnanci (ale např. platově je v třídě vedoucích atd....) - spojuješ do jednoho příznaku dva nesouvisející fakty.
Ty dva nesouvisející fakty (vedoucí a platová třída) jste spojil vy.
 
Stejnej nesmysl je vynucovat že každý má svého nadřízeného
Někdy je to naopak velice praktické. Můžete organizačně (ne databázově) s tou rolí nadřízeného spojit určitá oprávnění, např. schvalování dovolené. A pak nedojde k situaci, že si ředitel nemůže vzít dovolenou, protože mu ji nemá kdo schválit.

nebude dobře fungovat, protože např. dotaz na počty podřízených jednotlivých lidí bude dávat (bez patřičných ošetření komplikujících dotazy a navíc snadno opomenutelných) špatné výsledky, protože ostatní vedoucí sami sebe nepovedou
Větší banalitu už tam nemáte?

Stará známá poučka návrhu databází praví: "zachycujte realitu".
A proto mi tu ve svém komentáři vysvětlujte, že mám ignorovat realitu a databázi raději navrhnout jinak.

Mimochodem, ten můj model databáze zachycující realitu je problematický z jiného důvodu. Další poučka říká, že není vhodné databázi modelovat těsně podle pravidel daných realitou, pokud jsou ta pravidla daná rozhodnutím. Protože se to rozhodnutí může změnit.  Takže pokud mi někdo řekne, že u nich ve firmě je nadřízený definován tím, že má podřízené, budu zvažovat porušení pravidla „modeluj realitu“ právě proto, že ta definice nadřízeného je daná rozhodnutím a může se změnit.

Takže se moc nedivím, že ostatní Tvé "zlepšováky" pro návrh db ignorovali
Já jsem žádné zlepšováky nenavrhoval, právě naopak – já jsem psal o standardním zápisu INNER JOINu pomocí INNER JOINu. Naopak jsem proti zlepšováku Miroslava Šilhavého s tím, že pro INNER JOIN použije zápis pomocí OUTER JOINu a spojovací podmínku přidá k filtrovacím podmínkám do WHERE.

To je o tom, jestli chcete být programátorská lopata, která nechce rozumět reálnému prostředí a co jí není vyspecifikováno do puntíku, tak to ignoruje. Nebo jestli chcete program (včetně SQL) opravdu navrhovat. Pak musíte přemýšlet o krok dál.
Když píšete o sobě, pište raději v první osobě než v druhé. Navíc vy jste ignoroval i to, co do puntíku specifikováno bylo.

Zadání bylo naprosto přesně zadané: struktura dat byla dána tím, že "v tbl2 může a nemusí existovat odpovídající záznam"
Ano, tím je dána struktura dat. Struktura dat se popisuje pomocí DDL, zatímco JOIN je součástí SELECTu, tedy DML. Je hloupé pokoušet se JOINem určovat strukturu dat, protože tím strukturu nezměníte.

zatímco podmínka dotazu byla dána "allowed > 0"
Jsem rád, že jste konečně zaregistroval, jak byla dána podmínka. Ano, přesně takhle. Proto je také přesně tahle podmínka ve WHERE. A nefunguje to jen náhodou, jako ve vašem případě, ale vždycky, pro jakoukoli podmínku. Co když se podmínka změní na allowed IS NULL? V mém postupu se jenom změní podmínka ve WHERE a bude to dál fungovat. Vy byste v takovém případě (možná) zjistil, že jste použil špatný JOIN a že ho musíte opravit.

Naopak vy jste ze zadání naprosto nadbytečně dovodil, že OUTER JOIN se dá redukovat na INNER JOIN.
Nikoli, ten INNER JOIN je v zadání napsaný: „vybrat pouze to, co v tbl2 je …“. To naopak vy jste zcela nadbytečně odvodil, že zrovna v tomhle konkrétním případě se i OUTER JOIN bude chovat stejně jako požadovaný INNER JOIN.

ja som skor riesil Vasu fobiu z NULL hodnot spomenutu niekde vyssie.
Zkuste příště řešit reálné věci a ne vaše výmysly. Žádnou fóbii z NULL hodnot nemám, jenom jsem připomněl, že NULL je speciální hodnota, která má svůj význam, a není vhodné její význam měnit.

3
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 15. 10. 2019, 21:16:48 »
sakra Filip vyser sa uz na to. proste mozes dostat listu zamestnancov ktory uz nemaju nadriadenych a tam bude NULL. NULL neni nic zle da sa s tym dalej pracovat. ide o to co chces robit.
Myslím, že o tom, jak psát správně SQL dotazy, by neměli poučovat lidé, kteří mají problém zapamatovat si zadání o třech větách. Napíšu, že vedoucí je definován tím, že má podřízené, načež Miroslav Šilhavý začne řešit, co když vedoucí nemá podřízené. Napíšu, že každý zaměstnanec má svého nadřízeného (což může platit i pro ředitele, který může být v databázi nadřízeným sám sobě – může to být vhodné, protože pak není potřeba řešit výjimky, kdo mu bude schvalovat dovolenou apod. ) – a e3k objeví, že je možné to řešit i tak, že ne každý má svého nadřízeného.

Zadání vám klidně může připadat hloupé, pak je ale potřeba s tím zadáním polemizovat, ne si potichoučku řešit něco jiného. Takže za sebe bych to uzavřel, že než začnete řešit, jaký typ JOINu je nejlepší, je nejprve potřeba si pořádně přečíst zadání.

4
Pokud by za hosting platil 50 Kč měsíčně, měl by naprosto stejné problémy se zamykáním souborů, jaké tady řeší. Cena za hosting v tom nehraje roli.
Nikoli, stejné problémy by neměl. Nebyl by omezený limitem 20 MB na databázi, takže by se nepokoušel bez jakýchkoli znalostí naprogramovat vlastní databázi, ale použil by tu, kterou nabízí webhosting.

Dík Kite za zastání. A to jsem nezmínil, že by těch projektů klidně časem mohlo být víc. Platit za něco co slouží druhým a mě ne, proč bych to měl platit? Ať si to platí sami. Anebo ať mi to zaplatí ten pán co mi tak doporučuje placený hosting, když má tolik peněz na sponzorování nekomerčních projektů.
Jenže vy za to platíte svým časem, a to daleko víc, než kolik byste zaplatil za ten hosting. Navíc to zatím nevypadá, že byste se blížil k cíli – o konkurenčním přístupu k souborům toho nevíte o nic víc, než na začátku. A upřímně řečeno, nemyslím si, že byste se to mohl naučit z komentářů na diskusním fóru a generováním náhodných testů, které se s podstatou zamykání souborů míjí.

5
To nepotřebuju. Efektivní vyhledávání mám ale už dávno vyřešeno.
Efektivní hledání v registrovaných uživatelích, které zapisujete do souboru na disk? To bych chtěl vidět…

Nedám ani korunu za web, který nevydělává, leda že by si za to návštěvníci ten hosting sami zaplatili. Ale u webu který nemá žádnou návštěvnost asi těžko. Navíc mě těmi svými blbými řečmi rozpalujete doběla. Soudíte druhé lidi podle sebe, jenže vy jste profík, můžete si dovolit strávit u počítače kolik času chcete. Vůbec jsem z těch vašich subjektivně laděných soudů znechucen. To je jak bavit se s blbým člověkem, už jsem vám říkal, že hosting placený nechci a ten neplacený má kapacitu jen 20MB. Taky jsem psal, že tu databázi použiju, ale rozhodně ne na registraci. A tento týden se databází rozhodně zabývat nebudu. To jakým tempem pracuju je moje věc, do toho vám nic není pane.
Mně by to trvalo hodinu. Vám by to trvalo den, kdybyste si nechal poradit. Bude vám to trvat měsíce, když to budete dělat způsobem, jak to tady popisujete.

Nehodnotil jsem, jak dlouho na tom pracujete nebo kolik máte času. Pouze se podivuju nad tím, že si svou práci dobrovolně tolik komplikujete. To, že vás dobré rady rozpalují doběla, je váš problém.

Pokud nejste ochoten dát 50 Kč měsíčně, místo toho budete týdny něco programovat s nejistým výsledkem, znamená to, že váš čas nemá žádnou hodnotu. Můj čas hodnotu má a nehodlám ho plýtvat na řešení vašich problémů, které si sám vytváříte svou umíněností. Takže za mne naposledy: pokud je pro vás příliš pracné použít úplně základním způsobem jakoukoli databázi, ukládání dat do souborů v konkurenčním prostředí (tak, aby to alespoň trochu rozumně fungovalo) naprogramovat nedokážete. To není žádné souzení nebo hodnocení, je to prosté konstatování faktu. Buď to můžete vzít na vědomí, zařídit se podle toho a změnit svůj postup tak, abyste naprogramoval to, co naprogramovat chcete. A nebo můžete hlavou dál zkoušet prorazit betonovou zeď.

6
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 14. 10. 2019, 22:57:22 »
Pořád se slepě řídíte strukturou tabulek a neberete v úvahu význam dat. Pokud záznamy s neexistující vazbou nemají žádný význam, nemá smysl vytvářet nad nimi pohled, abyste je následně při každém použití toho pohledu musel odfiltrovat. Já jsem nepsal o pohledech, které přidávají jednu podmínku, ale o pohledech, které reprezentují různá data. Např. pokud je vedoucí zaměstnanec definován tím, že má podřízené, nemá smysl vytvářet si pohled s vedoucími, který bude obsahovat i ty, kteří žádné podřízené nemají, a ty z něj pak při každém použití odfiltrovávat.

Přesně naopak. V aplikaci můžu chtít zobrazit všechny vedoucí, co mají podřízené zaměstnance. Ale také můžu chtít (a je to dost běžné) na jiném místě zobrazit i ty, co (už) žádné podřízené nemají. Tedy jak existence, tak neexistence navázaného záznamu je významná. Struktura dat je pro oba záměry shodná, liší se jen v podmínce filtru.

7
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 14. 10. 2019, 21:47:41 »
Pořád se slepě řídíte strukturou tabulek a neberete v úvahu význam dat. Pokud záznamy s neexistující vazbou nemají žádný význam, nemá smysl vytvářet nad nimi pohled, abyste je následně při každém použití toho pohledu musel odfiltrovat. Já jsem nepsal o pohledech, které přidávají jednu podmínku, ale o pohledech, které reprezentují různá data. Např. pokud je vedoucí zaměstnanec definován tím, že má podřízené, nemá smysl vytvářet si pohled s vedoucími, který bude obsahovat i ty, kteří žádné podřízené nemají, a ty z něj pak při každém použití odfiltrovávat. Zároveň můžu mít nadefinováno, že každý zaměstnanec má svého vedoucího, to je pořád stejná struktura dat, pohled „zaměstnanci se svým vedoucím“ bude velmi podobný. Stejná struktura tabulek, stejná data, JOIN stejné tabulky do sebe sama – ale dva různé významy, dva různé pohledy, a možná dva různé JOINy, podle toho, jak bude vyřešen ředitel firmy, zda i u něj bude dodrženo pravidlo, že každý má vedoucího.

8
To je blbost, registraci si napíšu za týden.
Když vás baví psát týden něco, co můžete mít hotové za hodinu… Navíc už se tu dva dny snažíte přijít na to, jak se mají zamykat soubory, řešení stále nikde – a to zatím řešíte jen přidávání záznamů, ale ne aktualizaci nebo mazání nebo dokonce efektivní vyhledávání.

9
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 14. 10. 2019, 20:57:14 »
:) jenže to jsme pořád u toho samého. Pokud si "SELECT * FROM tbl1 LEFT JOIN tbl2" vyčleníte do VIEW, můžete pak s tím samým VIEW pracovat všemi způsoby. Třeba tím, že do WHERE doplníte allowed > 0, nebo že tbl2.id_data IS NULL.

Je pochopitelně dost účelné mít jedno VIEW a pracovat s ním jen v podmínce.
Když jsem psal o tom CROSS JOINu všech tabulek, myslel jsem to ironicky. To nebyl návod, že se k tomu máte snažit přiblížit…

Já osobně dělám pohledy na data, která dávají nějaký smysl. Pokud dává smysl spojit tbl1 s existujícími řádky v tbl2, udělám si na to pohled. Pokud dává smysl ty tabulky spojit, ale ignorovat neexistenci záznamů v tbl2 a prostě místo nich doplnit NULL hodnoty, udělám si na to pohled. Pokud dávají smysl oba dva přístupy, udělám dva pohledy. Vy za každý vytvořený pohled platíte, nebo proč je pro vás tak důležité, že je ten pohled jeden a ne dva? Navíc se ty dva pohledy používají v různých situacích, takže se mi to krásně oddělí. Dost možná ty pohledy budou mít i jiné sloupce nebo dokonce připojené jiné další tabulky. Kdyby to vše nacpal do jednoho pohledu, budu muset navíc v aplikaci k tomu jednomu způsobu použití muset všude přidávat podmínku (proč? přesně k tomu přece mají sloužit pohledy).Nedej bože, abych u jednoho způsobu použití potřeboval něco změnit – jiné sloupečky, připojit další tabulku… Pak stejně budu muset projít celou aplikaci, najít všechna místa, kde se ten pohled používá, zjistit, že je to způsob použití 1 nebo 2 a pak to budu moci konečně slavnostně rozdělit na dva různé pohledy.

Obzvlášť zábavné to vaše řešení bude tehdy, když optimalizátor nezvládne nad tím vaším view udělat predicate push a vy donutíte databázi přečíst celou velkou tabulku, ze které by vám normálně INNER JOIN vybral pár záznamů podle indexu.

10
Na jaké produkci? Já nejsem produkční studio!
„Produkce“ je v IT slangové označení pro „produkční prostředí“, nebo také „ostré prostředí“ – prostředí, kde aplikace běží „na ostro“, připojují se k ní reální uživatelé, má reálná data atd. Tedy např. i ta vaše aplikace na free webhostingu. Vedle toho pak mohou existovat různá nedůležitá nebo méně důležitá prostředí – vývojová, testovací, integrační, akceptační apod.

Zrovna problémy s konkurenčním přístupem se často vyskytují až od určitého množství současně pracujících uživatelů. Pokud řešíte webhosting zdarma, asi nebudete mít testovací prostředí, kde byste věrohodně simuloval souběžnou práci většího množství uživatelů. Takže na problémy se špatně napsaným konkurenčním přístupem můžete narazit až na ostrém serveru – až se vám začnou ztrácet data nebo se vám datový soubor poškodí.

Jak jsem psal, databázi určitě použiju, to jsem si už vyjasnil, ale rozhodně ne na ptákoviny jako je registrace a loginy, to zvládnu přes soubory […] Tady jednu kravinu abych programoval dva tři měsíce.
Pokud si pro prkotiny jako registrace a loginy budete programovat vlastní databázi, opravdu vám to bude trvat dva tři měsíce, klidně i déle. Pokud se na tom budete metodou pokusu a omylu učit, jak se pracuje se soubory při konkurenčním přístupu a jak se zamykají, bude vám to trvat podstatně déle, než tři měsíce. A možná nakonec zjistíte, že když budete zamykat celé soubory, už s malým množstvím uživatelů na freehostingu narazíte na limity v počtu souběžně otevřených souborů nebo doby zpracování skriptu.

A k tomu hostingu zdarma – slušný webhosting seženete už okolo 50 Kč za měsíc. Už jenom psaním těch podivuhodných testů jste propálil tolik času, že byste za to tu aplikaci provozoval několik let.

11
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 14. 10. 2019, 17:03:03 »
A pak někdo do toho WHERE dá takovouhle podmínku:
Kód: [Vybrat]
SELECT * FROM tbl1 LEFT OUTER JOIN tbl2 USING (id_data) WHERE tbl2.allowed IS NULL

Pokud dáte podmínku WHERE allowed > 0, pak Vám to tyto záznamy přirozeně nevrátí.
Ta podmínka je o dva komentáře výš, sám jste ji ve svém předchozím komentáři citoval. Mám pro vás tip – když píšete komentář, na stránce níž jsou předchozí komentáře v diskusi. Abyste ze sebe neudělal hlupáka, bývalo by stačilo odrolovat o jednu obrazovku dolů.

Jedná se o (primární / vzdálený) klíč. Ten může mít buďto hodnotu a dojde k joinu, nebo nedojde k joinu a pak záznam neexistuje. NULL v klíči má jasně daný význam. U ostatních sloupců, mimo klíčů platí to, co píšete.
Pro neexistenci záznamu platí to samé, co pro NULL. Není to stejná hodnota, jako kterákoli jiná, je speciální –ostatně i proto se při OUTER JOINu neexistující záznamy mapují právě na NULL, což je jiná speciální hodnota. Pokud chcete v SELECTu říct, že vás neexistující záznamy nezajímají, uděláte to právě pomocí INNER JOINu. Tím si zajistíte, že se ty neexistující záznamy ve výsledné sadě ani neobjeví, tím pádem není nutné je mapovat na NULL a tím pádem ani nemusíte NULL hodnotu řešit.

12
Flock sice spolehlivý je, ale nezaručuje že mezi otevřením a flockem se k souboru, nedostane jiný proces.
To je naprosto normální, takhle se budou chovat všechny synchronizační mechanismy. Vždy je to založené na tom, že se pokusíte udělat nějakou exkluzivní akci, vyhodnotíte výsledek a zjistíte, zda se podařila, nebo zda perníček loupe i někdo jiný a musíte chvilku počkat a zkusit to znovu.

flock neselhal ani jednou, vždy byl výsledek true.
Když chcete jako programátor řešit paralelní přístup k datům, tohle nemůžete nikdy napsat. To, že se vám nepodařilo nějaký souběh nasimulovat, vůbec neznamená, že nenastane hned při prvním spuštění na produkci.

A co takhle zkusit vyrobit jiný typ zámku, který by byl spolehlivější.
Dám vám dobrou radu. Nepokoušejte se vymýšlet vlastní zámky, v tuto chvíli na to nemáte znalosti. Použijte nějakou běžně používanou databázi, která už má tyhle nízkoúrovňové věci vyřešené. Tam můžete studovat třeba to, jak fungují ACID transakce, jak jsou od sebe izolované – a na základě toho si začnete pomalu budovat představu o tom, co se může dít, když se stejnými daty pracuje několik programů nebo vláken souběžně.

Takže až vyřešíš problémy se zamykáním souborů, přejdi na databázi.
Takhle to nebude fungovat, jedině opačně – nejprve se naučit používat prostředky databáze, které jsou jednodušší, a teprve pak se případně dostat k souborům.

13
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 14. 10. 2019, 16:37:48 »
Ano, ale přesně o to jde, aby mohl udělat. Tedy vyselektovat si záznamy, ke kterým není právo "allowed" explicitně dané.
Mně na tom teda poněkud vadí, že je ten dotaz špatně. Chtěl jsem záznamy, které v tbl2 existují a mají tam allowed IS NULL, ale vrátilo mi to i záznamy, které v tbl2 vůbec neexistují.

Jako další příklad toho, co může dávat smysl je dotaz:
SELECT  * FROM tbl1 LEFT OUTER JOIN tbl2 USING (id_data) WHERE tbl2.id_data IS NULL OR tbl2.allowed = 0
Pokud často píšete dotazy, ve kterých neexistence záznamu nebo NULL hodnota má stejný význam, jako nějaká jiná hodnota, tedy vyskytují se vám tam konstrukce … IS NULL OR … , je to známka toho, že máte špatně navrženou strukturu databáze. NULL není jedna z mnoha hodnot, NULL je speciální hodnota, výjimečná – proto se s ní nepracuje pomocí běžných operátorů = nebo !=, ale má speciální operátory; proto je „nakažlivá“ a když se objeví u běžných operátorů, je na výstupu zase NULL

14
Myslel jsem to tak, jak se píše v tom odkazu, tzn. že mezi fopen a flock se může dostat jiný proces.
To ale neznamená, že flock() není atomický.

Pokud bych to tedy měl říci přesně, tak flock() je atomická funkce, ale ke svému využití potřebuje fopen(), a spojení fopen()+flock() atomické není.
To, že volání dvou funkcí po sobě není atomické, je naprostý základ. Bez pochopení téhle věci je zbytečné pokoušet se programovat cokoli se zámky nebo řešit nějakou atomicitu.

15
Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky
« kdy: 14. 10. 2019, 10:09:28 »
Co prosím? Já tvrdím, že správně napsaný skelet dotazu je takový, kde se podmínka "metá" jen do WHERE a nemusí se nic dalšího měnit. Takový skelet lze zobecnit do VIEW a pak pracovat jen nad ním.

A pak někdo do toho WHERE dá takovouhle podmínku:
Kód: [Vybrat]
SELECT * FROM tbl1 LEFT OUTER JOIN tbl2 USING (id_data) WHERE tbl2.allowed IS NULL
Případně to udělá nad tím view – ideálně, když k tabulce ani nebude mít přístup. To už pak tu vaši chybu s použitím chybného JOINu ani v SELECTu neopraví. I když ve výsledku by to asi bylo dobře – konečně by opravil ten váš JOIN v pohledu na správný INNER JOIN.

Stran: [1] 2 3 ... 228

reklama