Radicle byl vydán ve verzi 1.6.0 s kódovým jménem Amaryllis. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
Zemřel Scott Adams, tvůrce komiksových stripů Dilbert parodujících pracovní prostředí velké firmy.
Sdružení CZ.NIC vydalo novou verzi Knot Resolveru (6.1.0). Jedná se o první vydanou stabilní verzi 6, která je nyní oficiálně preferovanou a doporučovanou verzí, namísto předešlé verze 5. Více o Knot Resolveru 6 je možné se dočíst přímo v dokumentaci.
Byl vydán Linux Mint 22.3 s kódovým jménem Zena. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze, že nástroj Systémová hlášení (System Reports) získal mnoho nových funkcí a byl přejmenován na Informace o systému (System Information). Linux Mint 22.3 bude podporován do roku 2029.
Wine bylo po roce vývoje od vydání verze 10.0 vydáno v nové stabilní verzi 11.0. Přehled novinek na GitLabu. Vypíchnuta je podpora NTSYNC a dokončení architektury WoW64.
Byl vydán Mozilla Firefox 147.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Firefox nově podporuje Freedesktop.org XDG Base Directory Specification. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 147 bude brzy k dispozici také na Flathubu a Snapcraftu.
Asociace repair.org udělila anticeny těm nejhorším produktům představeným na veletrhu CES 2026. Oceněnými jsou například šmírující kamery Amazon Ring AI, chytrý běžecký pás od společnosti Merach, která otevřeně přiznává, že nedokáže zabezpečit osobní data uživatelů, případně jednorázové lízátko, které rozvibrovává čelisti uživatele a tak přehrává hudbu. Absolutním vítězem je lednička od Samsungu, která zobrazuje reklamy a kterou lze otevřít pouze hlasovým příkazem přes cloudovou službu.
Íránští protirežimní aktivisté si všímají 30% až 80% ztráty packetů při komunikaci se satelity služby Starlink. Mohlo by se jednat o vedlejší důsledek rušení GPS, kterou pozemní přijímače Starlinku používají k výpočtu polohy satelitů a kterou se režim rovněž snaží blokovat, podle bezpečnostního experta a iranisty Amira Rashidiho je ale pravděpodobnější příčinou terestrické rušení přímo satelitní komunikace Starlinku podobnou
… více »Evropská komise (EK) zvažuje, že zařadí komunikační službu WhatsApp americké společnosti Meta mezi velké internetové platformy, které podléhají přísnější regulaci podle unijního nařízení o digitálních službách (DSA). Firmy s více než 45 miliony uživatelů jsou podle DSA považovány za velmi velké on-line platformy (Very Large Online Platforms; VLOP) a podléhají přísnějším pravidlům EU pro internetový obsah. Pravidla po
… více »Tržní hodnota technologické společnosti Alphabet poprvé v historii přesáhla čtyři biliony dolarů (83 bilionů Kč). Stalo se tak poté, co Apple oznámil, že bude na poli umělé inteligence (AI) spolupracovat s dceřinou firmou Alphabetu, společností Google.
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 :(
Více joinů většinou není problém... dají se celkem lehce vygenerovat a při dobře udělaných indexech se databáze ani moc nezadýchá. Ale je celkem protivné, že ty dotazy se pak nevejdou na obrazovku...
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: