Společnost IBM představila novou generaci svých serverů: IBM Power11.
Multiplatformní digitální pracovní stanice pro práci s audiem Ardour byla postavena na GTK2. Vývojáři neplánovali její portaci na GTK3 nebo GTK4. Naopak, v lednu loňského roku si vytvořili vlastní fork GTK2 s názvem YTK. Ten v únoru letošního roku přestal být volitelným a nově byla zcela odstraněna podpora GTK2.
Byla vydána nová verze 6.4 linuxové distribuce Parrot OS (Wikipedie). Jedná se o linuxovou distribuci založenou na Debianu a zaměřenou na penetrační testování, digitální forenzní analýzu, reverzní inženýrství, hacking, anonymitu nebo kryptografii. Přehled novinek v příspěvku na blogu.
Společnost initMAX pořádá sérii bezplatných webinářů věnovaných novému Zabbixu 7.4. Podrobnosti a registrace na webu initMAX.
… více »Byla vydána verze 7.0 open source platformy pro správu vlastního cloudu OpenNebula (Wikipedie). Kódový název nové verze je Phoenix. Přehled novinek v poznámkách k vydání v aktualizované dokumentaci.
E-mailový klient Thunderbird byl vydán ve verzi 140.0 ESR „Eclipse“. Jde o vydání s dlouhodobou podporou, shrnující novinky v upozorněních, vzhledu, správě složek a správě účtů. Pozor, nezaměňovat s průběžným vydáním 140.0, které bylo dostupné o týden dříve.
Organizace Video Games Europe reprezentující vydavatele počítačových her publikovala prohlášení k občanské iniciativě Stop Destroying Videogames.
Společnost Raspberry Pi nově nabzí Raspberry Pi Camera Module 3 Sensor Assembly, tj. samostatné senzorové moduly z Raspberry Pi Camera Module 3.
Cathode Ray Dude v novém videu ukazuje autorádio Empeg Car (později Rio Car) z let 1999–2001. Šlo o jeden z prvních přehrávačů MP3 do auta. Běží na něm Linux. Vyrobeno bylo jen asi pět tisíc kusů, ale zůstala kolem nich živá komunita, viz např. web riocar.org.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.7.
Dotaz jsem taky nepochopil. Ale řekněme, že by mohlo být odpovědí už výše uvedené:
select auta.*, paliva.nazev_palivo from tabulka_auta auta, tabulka_paliva paliva where auta.id_palivo = paliva.id_palivo;
Průserem je, pokud některé auto nemá zadané palivo - pak se takové auto nevypíše. Pro tyto případy je lépe použít dotaz:
select auta.*, paliva.nazev_palivo from tabulka_auta auta left join tabulka_paliva paliva using (id_palivo);
Kapitálním průserem by bylo, pokud by snad mnohem rychlejší databáze neuměla left join (nevím):
select auta.*, paliva.nazev_palivo from tabulka_auta auta, tabulka_paliva paliva where auta.id_palivo = paliva.id_palivo union all select auta.*, null from tabulka_auta auta where auta.id_palivo is null;
No a pak, jestli se vám takto složitý dotaz na získání takto jednoduché informace nelíbí, doporučuji view. Jestli vaše databáze view neumí (nevím), zkuste nějakou méně rychlou.
Samozřejmostí při takovém datovém návrhu by měly být cizí klíče - to jen pro sichr, aby vám nějaký nezodpovědný jedinec nezadal do databáze k nějakému auto neexistující palivo, či snad, nedejbobe, nesmazal palivo, na které ještě pořád některé z vašich aut jezdí:
create table tabulka_auta ( .... id_palivo int4 references tabulka_paliva(id_palivo) on update cascade on delete cascade ....
"SELECT id_vyrobce,nazev_vyrobce FROM tb_vyrobce ORDER BY nazev_vyrobce ASC"
. Hle a tady ke kartezkemu součinu nedochází a jména jednotlivých výrobců se neopakují!!
B)U druhého select.boxu je to jasné, na základě vybraného výrobce volám ty modely, kt. mají specifické id ze select.boxu prvního, pomocí WHERE!
C)Třetí select.box se naplňuje řádky z tb_obsah, dotaz je úplně stejný jako u prvního select.boxu: "SELECT id_obsah, nazev_obsah FROM tb_obsah ORDER BY nazev_obsah ASC"
A ZDE DOCHÁZÍ K TOMU KARTÉZKÉMU SOUČINU - PROČ?
$query="SELECT id_obsah, nazev_obsah, id_palivo, nazev_palivo FROM tb_obsah_motoru,tb_palivo ORDER BY nazev_obsah";
$query="SELECT id_obsah, nazev_obsah FROM tb_obsah_motoru ORDER BY nazev_obsah";
Sice to zatim naplní jenom select.box - obsah motoru, ale zato správně(jeden udaj - jedna radka), pouze řádek po řádku
value
z option
do proměnné $carMaker
$carMaker
(což je číselná hodnota, kt. koliduje s hodnotou id_vyrobce v tb_vyrobce) se dosadí do dotazu na model a to v "SELECT id_model, nazev_model FROM tb_model WHERE vyrobce_id=$carMaker ORDER BY nazev_model ASC
". A tím diferencuji modely, kt. se načtou zase do select.boxu - opakuje se zápis proměnné do $carModelnázev sloupce datova hodnota references jmeno_tabulky(název_sloupce, z jiné tabulky?-nevím)on update cascade on delete cascade
create table TBL2( ... COL2 <typ> references TBL1(COL1) ... );znamená, že hodnota sloupce
COL2
musí odpovídat některé hodnotě sloupce COL1
v tabulce TBL1
(nebo být NULL
- podle okolností). Zápis
create table TBLB( ... foreign key (COLB1,...,COLBn) references TBLA(COLA1,...,COLAn) ... );znamená, že v každém řádku tabulky
TBLB
musejí hodnoty sloupců COLB1,...,COLBn
odpovídat hodnotám sloupců COLA1,...,COLAn
v některém řádku tabulky TBLA
.
Přidáte-li 'on update cascade
', při změně odkazovaných hodnot v tabulce TBLA
se odpovídajícím způsobem změní i shodné hodnoty v tabulce TBLB
(jinak byste dostal chybu "violation of foreign key ...
"). Analogicky 'on delete cascade
' při smazání řádku v tabulce TBLA
smaže odpovídající řádky v TBLB
a 'on delete set null
' nastaví hodnoty na NULL
.
No a ještě bych měl jednu připomínku k textu, který jsem napsal včera: v tomto konkrétním případě bych použil nikoli cascade
, ale no action
- pak nejde smazat žádné palivo, na které v databázi některé auto jezdí.
K vašemu stylu zápisu sql dotazů: dlouho jsem ani z příspěvků nechápal, jak dovedete v tak primitivním dotazu vyrobit karteziánský součin - mě se to nestává, vyrobím něco podobného jen zcela vyjímečně. Proti podobným chybám můžu doporučit, abyste vždy zadával všechny všechny tabulky, ze kterých taháte byť i jediný sloupec a dával jim vždy aliasy:
select a.*, b.sloupec2 from tabulka1 a left join tabulka2 b using(klic);
Při takovém stylu zápisu je možnost vzniku kartezského součinu nižší - při překlepech bývá takto zapsaný dotaz nefunční, neproběhne.
Aut, která takto v databázi evidujete, asi nebude mnoho, karteziánský součin vám pouze znepříjemní výstupy. V databázi s milióny záznamů je karteziánský součin mnohem větší legrace - vede to k dotazům, které server není schopen zvládat.
tb_obsah.id_obsah
myslíte, že "povedeny" kartézký součin, lze využit k útoku, je to vůbec možné? teda asi jo, ale to musi utočnik znat strukturu db, a když už ji zna, tak je většinou již uvnitř.
Tiskni
Sdílej: