Příspěvky

391

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

« kdy: 25. 10. 2019, 20:19:53 »

My ale umíme udělat našeptávač štítků. Jen k tomu nepoužíváme indexy do obřích tabulek, protože víme, že by to bylo zoufale neefektivní a uživatel by mezitím mohl usnout.

Google má vyhledávač a má v něm i našeptávač. Buď je to zoufale neefektivní a uživatelé u toho usínají, nebo nemá zaindexováno moc dokumentů, nebo používá nějakou jinou zázračnou metodu, než indexy. A nebo neplatí váš předpoklad efektivita správného indexu pro fulltextové vyhledávání není tolik citlivá na počet zaindexovaných dokumentů/záznamů.

Pomiňme, že Google pro tento účel nepoužívá SQL, ale vlastní databázi Big Table.

Jenže i v SQL tohle umíme. Stačí jen tu databázi normalizovat. Tabulka se nám rozpadne na tři tabulky a ejhle, najednou našeptávač neprochází milióny záznamů se štítky, ale jen stovky. Navíc je tabulka se štítky velmi úzká a tedy i rychlá. Samozřejmě má i svůj index.

392

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

« kdy: 25. 10. 2019, 15:09:21 »

Víš, my nejsme teoretici, co evidentně v DB toho moc nenaprogramovali

No, pokud to programujete tak, že uživateli neposkytnete našeptávač štítků, protože ho neumíte udělat, a místo toho nutíte admina, aby se jednou za měsíc vypsal nestránkovaný seznam všech štítků a ručně tam hledal duplicity, pak upřímně lituju uživatele vašich aplikací.

My ale umíme udělat našeptávač štítků. Jen k tomu nepoužíváme indexy do obřích tabulek, protože víme, že by to bylo zoufale neefektivní a uživatel by mezitím mohl usnout.

393

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

« kdy: 25. 10. 2019, 09:56:47 »

Už výše bylo řečeno, že součástí toho klíče je i interní ID záznamu, které nemůže být duplicitní.

Podle tohoto popisu není v PostgreSQL ID záznamu součástí klíče, ale je ve stromu uložené jako hodnota, na kterou se ten klíč odkazuje. Z čeho usuzujete na opak?

Takže to má jinak a připouští duplicitu klíče, viz klíč '49'. Jak by z tohoto měl jít udělat distinct jinak, než poctivým traverzováním?

Já si myslím, že Filip hovoří o databázích, u kterých je (možná?) full table scan jednoho sloupce pomalejší, než totožné projití stejného počtu záznamů v indexu. Je to možné?

Možné to je, dokonce se to může dynamicky měnit i v průběhu života jedné tabulky.

394

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

« kdy: 25. 10. 2019, 09:13:40 »

Už výše bylo řečeno, že součástí toho klíče je i interní ID záznamu, které nemůže být duplicitní.

Podle tohoto popisu není v PostgreSQL ID záznamu součástí klíče, ale je ve stromu uložené jako hodnota, na kterou se ten klíč odkazuje. Z čeho usuzujete na opak?

Takže to má jinak a připouští duplicitu klíče, viz klíč '49'. Jak by z tohoto měl jít udělat distinct jinak, než poctivým traverzováním?

395

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

« kdy: 24. 10. 2019, 23:00:16 »

To by nebyl B-Tree.

Pokud něco z uváděného není B-Tree, pak ta varianta používaná PostgreSQL,která umožňuje ukládat duplicitní klíče – protože striktní definice B-Tree vyžaduje lineárně uspořádané klíče.

Už výše bylo řečeno, že součástí toho klíče je i interní ID záznamu, které nemůže být duplicitní.

396

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

« kdy: 24. 10. 2019, 22:20:51 »

Jenže on to je principiální problém, se kterým si B-stromy ani heše neporadí. To by musel být ke každému klíči přidělen seznam ID záznamů, které tomu klíči vyhovují, abys mohl vždy vybrat jen ten první a jít dál.

Existují ale i jiné druhy indexů. Hash si s tím neporadí, protože v indexu není uložena hodnota. B-Tree si s tím může poradit například právě tím způsobem, jaký jste popsal – v každém listu bude uložen seznam záznamů, které ten klíč obsahují. Vybírat první záznam není potřeba, protože hodnotu zná databáze už z indexu. Problém s B-Tree je jenom tehdy, pokud se používá upravená varianta, která umožňuje ukládat duplicitní klíče přímo jako samostatné uzly stromu – jako to má právě PostgreSQL nebo Oracle. To ale není obecná vlastnost B-Tree, naopak je to spíš odchylka těchto databází od standardní implementace B-Tree (i když je to odchylka logická, protože umožňuje řešit neunikátní hodnoty pořád v rámci jedné datové struktury B-Tree).

To by nebyl B-Tree.

V hešovaném indexu se neukládá heš, ale přímo klíče.

397

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

« kdy: 24. 10. 2019, 21:47:23 »

Filipe, na DISTINCT opravdu indexy nezabírají.

Když píšete o implementaci nějakého konkrétního databázového enginu, konkrétně ho pojmenujte. Když to napíšete takhle obecně, někdo by si mohl myslet, že je to nějaký principiální problém.

Jenže on to je principiální problém, se kterým si B-stromy ani heše neporadí. To by musel být ke každému klíči přidělen seznam ID záznamů, které tomu klíči vyhovují, abys mohl vždy vybrat jen ten první a jít dál.

398

Odkladiště / Re:Zákonná výpovědní lhůta a úmyslné dělání potíží

« kdy: 24. 10. 2019, 14:10:01 »

Jinak zbytek otázky je klasické čecháčkovství, které třeba v německu nedokážou pochopit:

Čech: "Chci firemní XXX"
Němec: "Proč by si to chtěl? Dyť to vůbec není potřeba k tvé práci."
Čech: "Ušetřím na daních"
Němec: "Proč by si chtěl sakra o*ebávat stát?"

Němci zřejmě důvěřují státu, že umí s těmi penězi hospodařit.

399

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

« kdy: 23. 10. 2019, 23:26:13 »

Budem se tu ještě dlouho plácat kolem štítků, když víme, že je to M:N? Máme na to jasný a osvědčený vzor s bázovou tabulkou, jedním číselníkem a jednou vazební tabulkou.

Snad byste nechtěl porovnávat databázový výkon pro běžné operace – tj. získání seznamu štítků daného objektu, získání objektů s daným štítkem a přidání a smazání štítku u daného objektu. To ne, tady se přece porovnává výkon tak zásadních operací, jako je výpis všech štítků.

Pokud se to udělá M:N, tak číselník štítků bude mít jen stovky záznamů a práce s nimi bude velmi rychlá, včetně našeptávání. Rozhodně rychlejší, než index štítků v dlouhé tabulce.

400

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

« kdy: 23. 10. 2019, 23:18:47 »

Já narozdíl od Tebe netvrdím, že existuje nějaký index, který by Ti v tomto případě pomohl.

Aha. Takže uchovávat množinu krátkých textů je podle vás pro počítače neřešitelný úkol. Viděl jste někdy spellchecker, úplně tu nejprimitivnější implementaci? To je prostě množina slov, ve které se dá rychle vyhledat, jestli v ní dané slovo je nebo není. Seznam těch slov je možné i vypsat. Té struktuře, která umožňuje rychlé vyhledávání, se říká – index.

Je to řešitelné i bez M:N, ale používá se na to jiná metodika než prostý index. Udělá se další indexovaná tabulka, třeba i bez vazby na základní tabulku, ale zato s unikátním indexem, který nedovolí duplicitní vložení štítku. Taková tabulka už nemá milióny záznamů ale jen stovky a je tak pro našeptávač bezproblémově použitelná.

Je to denormalizované řešení, které tedy vyžaduje použití triggerů. Jeho možnou výhodou je, že se štítky po výmazu hlavního záznamu neztratí.

401

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

« kdy: 23. 10. 2019, 22:43:37 »

Budem se tu ještě dlouho plácat kolem štítků, když víme, že je to M:N? Máme na to jasný a osvědčený vzor s bázovou tabulkou, jedním číselníkem a jednou vazební tabulkou.

402

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 23. 10. 2019, 20:21:04 »

https://www.php.net/manual/en/function.stat.php

403

Odkladiště / Re:Zákonná výpovědní lhůta a úmyslné dělání potíží

« kdy: 23. 10. 2019, 18:56:17 »

To je takový problém si to v práci "odsedět"?

404

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

« kdy: 23. 10. 2019, 14:03:48 »

Důvod je prostý: Pokud má engine volbu, zda projít všechny záznamy nebo všechny klíče v indexu, zvolí průchod všemi záznamy. Distinct na to nemá vliv.

405

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

« kdy: 23. 10. 2019, 08:49:58 »

Tento přístup se v relačních databázích nepoužívá, to dělají jen bastly přes ORM.

Možná proto je teď takový boom NoSQL databází. Protože když si někdo nechá poradit s něčím, co by řešil jeden sloupeček, od „databázového SQL specialisty“, navrhne dotyčný několik tabulek a k údržbě bude potřeba uložené procedury a triggery.

Je to krátkozraké. Co když bude potřebný víc než jeden štítek? A co indexování štítků pro lepší vyhledávání? Bude to stíhat, když budu pravidelně potřebovat seznam štítků?

Pro evidenci domácích CD bych však jeden sloupeček pro štítky klidně použil.