Hlavní navigace

Drizzle nedovolí implicitní kartézský součin

Sdílet

Pavel Stěhule 8. 2. 2011

Poměrně záludnou ale typickou copy/paste chybou v SQL dotazech je nechtěný kartézský součin. Záludnost této chyby spočívá v tom, že se projevuje se značným zpožděním – někdy i po několika letech provozu. Jeden z nových a velice aktivních forků MySQL Drizzle řeší tento problém velice přímočaře (a já jim v tom fandím) – implicitní kartézský součin v SQL dotazech neumožňuje.

Tato zprávička byla zaslána čtenářem serveru Root.cz pomocí formuláře Přidat zprávičku. Děkujeme!

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 8. 2. 2011 16:30

    Petr Šmíd (neregistrovaný) ---.frankfurt.ipgprs.viaginterkom.de

    To by mě zajímalo, jak budou řešit zpětnou kompatibilitu. No asi nijak. Takže pokud použiji novější verzi databáze, tak mi přestane starý program fungovat. Bezva...

  • 8. 2. 2011 20:38

    Pavel Stěhule

    Starý zápis povolený je. Jen nesmí vést ke kartézskému součinu. Osobně jsem ještě neviděl kód, který by nebyl zabugovaný a kartézský součin obsahoval. A k tomu ještě Drizzle kompatibilitu řešit nemusí - je kompatibilní sám se sebou a ještě teď ještě nevyšla finální verze. Co se týče funkcionality, tak se Drizzle pohybuje někde mezi 4 a 5 verzí MySQL. Takže apriori není kompatibilní s žádnou verzí MySQL, přičemž ovšem typické www aplikace by neměly mít zvláštní problém.

  • 9. 2. 2011 11:18

    Karel (neregistrovaný) 93.90.162.---

    1. U produkčního kódu máte víceméně pravdu, ale u testů a datových analýz je "plný" kartézský součin běžně používán. A protože žijeme v době, kdy testy jsou součástí produkčních kódů...

    2. Chyb s kartézským součinem tak jak je ukázán ve článku je minimum. Taková chyba bude unikat vaší pozornosti jen pokud v jedné z těch tabulek bude právě jeden záznam. A pak je otázkou, proč taková tabulka vůbec existuje. Drtivá většina (víceméně všechny) chyb s kartézským součinem je neúplná reference. Mou noční můrou byl uživatel ERP systému, který provedl duplicitní příjem a ručně přepsal číslo šarže na již existující. Teprve v té chvíli se ukázalo, že pole "release_no" skutečně smysl má a "batch_no" nemusí být vždy unikátní (což evidentně řada programátorů nevěděla). To je právě ta chyba, která 10 let nevystrčí růžky. A s tou si Drizzle beztak neporadí :-)

  • 9. 2. 2011 15:36

    Pavel Stěhule

    Já mám trochu jinou zkušenost. Řada programátorů si všimne problematických řádků, ale jednoduše je eliminuje klauzulí DISTINCT - dokonce jsem narazil na programátora, který DISTINCT psal všude - preventivně. Jinak bezezbytku souhlasím s tím, že neúplná reference je vážnější problém. V prostředí, pro které je Drizzle zamýšleno si myslím, že blokování kartézského součinu (při starém zápisu) má smysl. Velká část programátorů webu SQL nerozumí, používá jej mechanicky - a tohle může pomoci.

  • 11. 2. 2011 16:10

    jos (neregistrovaný) ---.tabor.telecom.cz

    dokonce jsem narazil na programátora, který DISTINCT psal všude

    vona je v tomhle se SQL legrace, místo toho, aby DISTINCT byl default i pro SELECT (protože v relační db by to tak mělo bejt), tak je to default jen u UNIONu

  • 4. 2. 2013 7:20

    romek (neregistrovaný) ---.homecredit.net

    asi nerozumím - select vrací výsledek dotazu podle filterovacích kriterií a spojovacích, to že výsledkem jsou shodné řádky není problém SELECT ale toho, kdo kriteria zapsal špatně, nebo nedokáže, nechce a nebo neumí správně pochopit