Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
FlappyFavi, hra Flappy Bird v ikoně Favicon. Nefunguje na mobilech.
Byly vyhlášeny výsledky (YouTube) 28. ročníku D.I.C.E. (Design, Innovate, Communicate, Entertain) Awards: Hrou roku 2024 je Astro Bot.
Všem na AbcLinuxu vše nejlepší k Valentýnu aneb Dni lásky ke svobodnému softwaru (I love Free Software Day, Mastodon, 𝕏).
Vývojáři openSUSE Tumbleweed oznámili, že u nových instalací se ve výchozím stavu přechází z AppArmor na SELinux. Uživatelé, kteří chtějí zůstat na AppArmor si mohou AppArmor vybrat v instalátoru.
Hector "marcan" Martin skončil jako vedoucí projektu Asahi Linux aneb Linux na Apple Siliconu. Projekt ale pokračuje dál.
PostgreSQL byl vydán ve verzích 17.3, 16.7, 15.11, 14.16 a 13.19. Řešena je zranitelnost CVE-2025-1094 s CVSS 8.1 a více než 70 chyb.
Dnes je Světový den rádia. Použili jste někdy GNU Radio?
Před 33 lety, ve čtvrtek 13. února 1992, se tehdejší Česká a Slovenská Federativní Republika oficiálně (a slavnostně) připojila k Internetu.
Byla vydána nová verze 9.10 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Zdravím! Měl bych jeden dotaz. Mám zboží o různých parametrech (např. u jednho druhu zboží se měří průměr a délka, u druhého průměr1, průměr2 a délka,....) Jak nacpat zboží do jedné tabulky? Děkuji za pomoc! TU.
Viděl jsem v praxi takovouto "prasarnu", ale jejím příznivcem nejsem:
tabulka bude vypadat cca takto:
int id_zbozi
varchar nazev
.
.
.
varchar parametry
a potom v parametrech budeš zaznamenávat více hodnot a oddělovat je od sebe nějakých oddělovačem - např středník nebo |
Takže záznam do pole parametry vložíš např toto: "delka=55cm|prumer=10cm|vaha=10kg" - zpět z toho to dostaneš např pomocí php funkce explode
select p.* from Pračky, PrideleniTagu pt where pt.id_pracky = p.id_pracky and pt.id_tagu in (1,2,3,4,5) group by p.id_pracky having count(pt.id_tagu) = 5
Mňa by zaujímalo, či LDAP podporuje aj hľadanie typu väčší-menší - napríklad keby som chcel vylistovať všetky práčky so šírkou do 45cm (malá kúpeľňa :)), ako by som urobil query? S LDAPom som nikdy nerobil a dogooglil som sa len ku podmienkam na ekvivalenciu a wildcard, čo na takýto prípad IMO nestačí.
Muhehe o LDAPu jsem kdysi hodně věděl, ale dělat v něm katalog zboží je ... podle mého názoru trošku silná káva. Ne že by to nešlo, to samozřejmě ano, ale je dobré si uvědomit, že např. v LDAPu nepodržíte referenční integritu, budete muset hodně zapracovat na objectclassech apod. Ale když se udělá dobré mapování a architektura (objednávky v SQL, katalog v LDAP, konekce ke dvěma různým serverovým službám) ... proti gustu žáný dišputát.
nepodržíte referenční integrituA na co bych ji měl potřebovat?
hodně zapracovat na objectclassechV SQL zase na tabulkách.
A na co bych ji měl potřebovat?
Na takovou drobnost jakou je rozšíření katalogu o objednávkový systém. Dělat jej v LDAPu je trošku nepraktické a pracné.
Změnou zadání můžu vždy sabotovat jakékoliv řešení.Vítej ve skutečném světě
Tak to už je lepší udělat si číselník parametrů a pak tabulku, kde bude odkaz na zboží, na parametr a pak jeho hodnota. Na zobrazování to stačí, ale vyhledávat je prasárna.
- OO s overloadingom operatorov result = Katalog.search (Katalog.dlzka >= 1000 && Katalog.hmotnost < 200) - textovými konštantami a štruktúrami jazyka result = Katalog.search ('dlzka' => { '>=', 1000 }, 'hmotnost' => { '<', 200) - OO s metódami (fuj) result = Katalog.search (Katalog.dlzka.greater_or_equal_then (1000).and (Katalog.hmotnost.less_then (200))Nevraviac o tom, že len niektoré ORM podporujú tento typ namapovania. A výsledné SQL? Od načítania celých tabuliek a porovnávania v používanom jazyku, cez tie lepšie, ktoré vytiahnu Katalog (buď cez dynamický in alebo fetch per id) podľa prieniku (dlzka >= 1000) a (hmostnost < 200) až po tie najlepšie, ktoré majú k dispozícii "fetch_from_sql"
Pretože ORM nástroje prácu z DB iba zjednodušujú, nezefektívňujú.V mnoha případech ji dokonce zneefektivňují (z pohledu efektivnosti dotazů).
Asi záleží na tom, jaké ORM
SELECT * FROM produkt INNER JOIN atribut ON atribut.id_produktu = produkt.id WHERE atribut.jmeno = 'delka' AND atribut.hodnota > 100 ;
Jiste, ale pokud chceš hledat podle vice parametru, tak pripojujes tu tabulku mnohokrat a to je svinstvo. Vim dost o cem mluvim, dělám s tímto datovým modelem denne :(
a co třeba nějak takto (odzkoušeno na MySQL)
SELECT product_id, count(param_id) as params_count FROM `param_table` WHERE ( param_id = 1 and param_value >= 150) OR ( param_id = 2 and param_value > 150) group by product_id HAVING params_count = 2
param_id je ID parametru
CREATE TABLE `param_table` ( `product_id` int(11) NOT NULL, `param_id` int(11) NOT NULL, `param_value` varchar(50) NOT NULL );
protože mysql dělá konverzi typů, dá se to takto použít, pak jenom podle param_id vybrat vhodný operátor.
jenom doplním, že v klauzuli HAVING params_count = 2
se musí params_count rovnat počtu zadaných parametrů
Ale je celkem protivné, že ty dotazy se pak nevejdou na obrazovkuTo lze řešit VIEWama.
tak pripojujes tu tabulku mnohokrat a to je svinstvo
Proč?
Jak u tohodle řešit když ty hodnoty nejsou vždy jen čísla? Aby tam byly sloupečky ciselna_hodnota, textova_hodnota atd s tim ze vyplneny bude vzdy jen jeden mi prijde zvlastni ;)
a navíc mohou být hodnoty v různých jednotkách a musí fungovat vyhledávání (třeba hledat všechno menší než 5cm; ale některé položky to mají zadáno v mm a jiné v cm :) To se udělá další tabulka s jednotkama a s převodama mezi nima a pak do tý tabulky s odkazama na zboží, parametr a hodnotou se přidá ješte odkaz na jednotku.
Co si o tom myslí zkušenější? ;)
A když je vyhledávání prasárna tak jak na to líp? ;)
Tiskni
Sdílej: