Příspěvky

1066

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 12. 10. 2019, 10:15:59 »

Ano, a tady je struktura dat taková, že se zabýváme jenom záznamy existujícími v tbl2.

Ne. Struktura dat je dána databází (její zamýšlenou interpretací). Struktura se nemění dotaz od dotazu. Ve správném návrhu by měla být vyjádřena i správně postavenými FOREIGN KEYS.

Existence záznamu není podmínkou dotazu, protože takové záznamy se do výsledné sady před filtrováním vůbec nedostanou. Ostatně tazatel o tom přesně takhle uvažoval, proto dokonce to spojování tabulek ani nezmínil – připadalo mu to samozřejmé.

Existence záznamu je tacitní podmínkou dotazu. Pokud musí existovat allowed > 0, implikuje to existenci záznamu v tbl2.

Vy jste mu zodpovědel dotaz jen pro jeho jeden speciální případ, ale už jste vůbec nepřemýšlel, že v praxi se podmínky parametrizují. Panu kolegovi, který se učí, a který potřebuje vytvořit správné návyky, jste poradil pěknou blbost, která mu jednou zkomplikuje život.

1067

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 12. 10. 2019, 10:04:35 »

klidně můžete napsat jako CROSS JOIN a všechny podmínky dát do WHERE, aby to bylo dostatečně obecné.

JOINY mají odpovídat struktuře dat, nikoliv podmínkám dotazu. CROSS JOIN by těmto datům neodpovídal, proto by byl taky špatně. Kritéria spojení byste přesouval do podmínky dotazu.

Stejně tak špatně by bylo dávat i druhou podmínku do joinu, byť by to fungovalo:
SELECT * FROM tbl1 JOIN tbl2 ON (tbl1.id_data=tbl2.id_data AND allowed > 0)

V tomto případě byste se mohl WHERE vyhnout úplně a je to ta samá chyba - přesouvání podmínky dotazu do kritérií spojení.

Prostě Váš návyk omezovat joiny podle podmínky dotazu je nezdravý, tak se SQL dělat nemá. Na projektu, kde se musí nad dotazem (nebo view) vystřídat víc lidí, nebo je použitý ve více situacích, nebo se může podmínka dotazu měnit, je potřeba dodržovat určitá pravidla.

Umím pochopit, že jste se třeba ještě nedostal do prostředí, kde by byly takové nároky, ale pak si aspoň nechte poradit a nešiřte bludy.

1068

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 12. 10. 2019, 09:51:27 »

Ano, jedním z nich je například Miroslav Šilhavý, který se neustále spojovací kritérium snaží cpát do podmínek.

Spojovací kritérium je odvislé od struktury dat. Tu nám tazatel popsal. V tbl2 mohou a nemusí být záznamy odpovídající tbl1. To je spojovací kritérium. Toto spojovací kritérium zůstane platné za všech okolností, i když se podmínka dotazu změní.

S tímto spojením pak můžete pokládat dotaz, který tazatel položil (najít záznamy, které mají odpovídající záznam v tbl2 a zároveň allowed > 0), ale můžete podmínku i libovolně přeformulovat (zejm. najít záznamy, které nemají odpovídající záznam v tbl2 nebo mají allowed = 0). S vaším inner joinem se můžete jít klouzat, při změně podmínky budete muset přeformulovat i joiny.

1069

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 12. 10. 2019, 08:59:14 »

2. mas tabulku 2 kde su niektore ID s tabulky 1
preto LEFT JOIN... tam neni o com s inner joinom.

Jojo, je to tak.

To, co říká Filip, dělá spousta lidí - podmínku zaměňuje s joinovacím kritériem. Ony dost často fungují totožně, ale čitelnější (a správnější) je v joinu vyjadřovat typ spojení, a ve where vyjadřovat, co požaduji za data.

Nevím, jestli tento zlozvyk přišel s internetovými návody, nebo jestli je to třeba důsledek MySQL-školy, kde MySQL spoustu věcí neumí, nebo umí bídně, a tak programátoři hledají obezličky..

1070

Hardware / Re:Mám pořídit nový disk?

« kdy: 10. 10. 2019, 19:22:17 »

pre-fail NEznamena "pred selhanim" ale ze jde o TYP udaje kterej uzivatel muze poznat z udaje v poslednim sloupci
dale mas typ old-age, coz opet NEznamena ze je disk "starej", ale pouze ze jde o TYP udaje kterej naznacuje stari disku coz ale neznamena ze musi kvuli tomu byt problem...

Pravda. Mozek mimo hlavu.
Díky.

1071

Hardware / Re:Mám pořídit nový disk?

« kdy: 10. 10. 2019, 19:11:30 »

Miroslav je okecavajici teoretik, to co citoval nejsou problemy,  Raw_Read_Error_Rate  je normalni ze jsou disk je opravuje za chodu, Spin_Up_Time je take normalni (jde o pocet normalniho roztoceni motoru, tedy pri zapnuti stroje a/nebo probuzeni disku). spletl si to se Spin_Retry_Count (to je ze se NEdari roztocit motor a disk to zkousi znovu) ktere mas 0, posledni Miroslav citoval Reallocated_Sector_Ct ktere mas 0...

Já myslím že stačí přečíst pre-fail status.

1072

Hardware / Re:Mám pořídit nový disk?

« kdy: 10. 10. 2019, 17:36:12 »

Kód: [Vybrat]

  1 Raw_Read_Error_Rate     0x002f   100   100   051    Pre-fail  Always       -       1481
  3 Spin_Up_Time            0x0023   092   085   025    Pre-fail  Always       -       2501
  5 Reallocated_Sector_Ct   0x0033   252   252   010    Pre-fail  Always       -       0

Vyhodit.

1073

Hardware / Re:Mam poridit novy disk ?

« kdy: 10. 10. 2019, 12:52:49 »

a neni to tak ze kdyz badblock najde bad block, tak se FW disku pokusi sektor realokovat na zalozni, a zvysi pocet realocated_sector_counts v smartctl, pokud tedy uz zalozni bloky nedosly?

Přesně tak. Toto jsou obvykle výsledky relokace, jestli se povede / nepovede. To může být odvislé mj. od kvality napájení, datového kabelu, nebo i provozní teploty.

Kdyby smartctl ukázal, že je disk v háji, je na vyhození určite.
Pokud smartctl neukáže chyby, pak stejně nezbyde, než disk vyzkoušet v jiném PC.

1074

Hardware / Re:Mam poridit novy disk ?

« kdy: 10. 10. 2019, 12:16:52 »

Na to je děsně jednoduchá odpověď: pokud je disk vadný, okamžitě vyměnit.
Jediné, co musíte ověřit je, jestli není vadný řadič nebo kabel - to se nejjednodušeji udělá v jiném PC.
Pokud se najde jakákoliv chyba, patří do stoupy.

1075

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 09. 10. 2019, 10:14:35 »

Vždyť už jsi rovnou budoucí problém napsal.

To je věc názoru. Zdejší diskuse ukázala, že mnoha lidem nedošlo, že neexistence záznamu v tbl2 může mít nějaký interpretovaný význam - např. pokud by se hledaly položky v tbl1 s opačným významem.

Abych to snad zakončil: já preferuji a kolegy učím, že v případě, že v druhé tabulce záznam být nemusí, mají si vytvářet dotazy outer joinem. Také doporučuju tyto základní, nebo časté operace vytknout do view a dál už pracovat výhradně nad ním. Je mnohem výhodnější, když základní strukturu programátor čte z hotového pohledu, než aby ji na každém dotazu vymýšlel znovu. Výhodnější je to i pro refaktorování, nemusí se pak revidovat spousta míst v kódu.

1076

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 08. 10. 2019, 21:27:49 »

nechapem ten flamewar ohladom INNER a LEFT OUTER JOIN.

On to není úplně flamewar.
Diskuse je o tom, že jedno řešení je přesně podle požadavku.
Druhé řešení je univerzálnější pro ten konkrétní požadavek a připravené i pro další předpokladatelné situace.

Já zastávám názor, že ten, kdo projektuje dotazy, měl by myslet v širším kontextu a předcházet tak budoucím problémům.

1077

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 07. 10. 2019, 15:59:57 »

Tohle je ukázkový příklad antipatternu „předčasná optimalizace“. Kód má být především správný, pak přehledný, srozumitelný a udržovatelný. Což v tomto případě znamená INNER JOIN, protože u něj to každý vidí na první pohled, že jde o INNER JOIN.

To si nemyslím. Pro ladění je daleko výhodnější si vytvořit VIEW s LEFT OUTER JOINEM. Když si pak vyselektujete všechny záznamy, daleko líp si představíte, co navrací. INNER JOINEM se připravíte o možná nerelevantní, ale možná taky o relevantní hodnoty a nevyladíte ani zblo.

1078

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 07. 10. 2019, 15:11:16 »

Poradím si s tím snadno – když ty záznamy neexistují, asi nemají žádný význam, a je tedy v pořádku, že se do výsledné sady záznamů příslušný záznam vůbec nedostane. Všimněte si, že je to přesně to, co Racchek potřeboval, jak později napsal.

To je velmi krátkozraké uvažování při návrhu selectu.
Racchek může ve své práci potřebovat následně vyselektovat třeba opak. Pokud to udělá OUTER JOINEM, jen vymění podmínku - což se hodí zejména ve scriptech.

Proto tvrdím, že pokud někdo navrhuje dotaz, měl by ho udělat co nejuniverzálnější. Následně se dá takový dotaz uložit jako VIEW a pak už vstoupí do hry jen to samotné WHERE.

1079

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 07. 10. 2019, 00:18:42 »

O záznamu s hodnotou NULL jsem nikdy nemluvil, to jste si musel domyslet jako projekci Vašich myšlenek.

V tom případě to byl někdo jiný téhož jména.

NULL může reprezentovat implicitní nastavení

NULL je v takovýchto případech naprosto správná hodnota, od toho je.

Moje tvrzení se stále týkala výsledku JOINU. V implicitním nastavení nemáte patřičný záznam v tabulce tbl2 a tudíž se ve výsledku joinu objeví hodnota NULL. A je v takovém případě zcela na místě.

Chápu, měl jsem to napsat přesněji, tak příště.

Ale i kdyby: stále k tomu platí racchekovo zadání, že v tbl2 nemusí záznam existovat. A s tím si prostě v INNER JOINU neporadíte, na to nemá žádný vliv to, jestli v tabulce tbl2 ve sloupci allow může být NULL nebo ne.

1080

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 07. 10. 2019, 00:03:48 »

Není nutné opakovat celý kontext. Jenom je nutné neplést si dvě různé věci, „neexistenci záznamu“ a „záznam, který má v jednom sloupci hodnotu NULL“. Z této diskuse je vidět, že až to začnete rozlišovat, ozřejmí se vám mnoho věcí.

O záznamu s hodnotou NULL jsem nikdy nemluvil, to jste si musel domyslet jako projekci Vašich myšlenek. Já řeším pouze otázku INNER / OUTER JOINU v kontextu toho, že v tbl2 může a nemusí příslušný záznam existovat. Pokud jsem hovořil o sloupci allow, jedině jakožto výsledném sloupci (outer) joinu.

Ukládat NULL do sloupce allow v tabulce tbl2 by byla hovadina. Pokud jste tímto směrem vedl argumentaci, pak zbytečně a můžeme toto téma opustit a znovu se věnovat pouze té otázce joinu a jeho interpretaci různých situací.