Wayback byl vydán ve verzi 0.3. Wayback je "tak akorát Waylandu, aby fungoval Xwayland". Jedná se o kompatibilní vrstvu umožňující běh plnohodnotných X11 desktopových prostředí s využitím komponent z Waylandu. Cílem je nakonec nahradit klasický server X.Org, a tím snížit zátěž údržby aplikací X11.
Byla vydána verze 4.0.0 programovacího jazyka Ruby (Wikipedie). S Ruby Box a ZJIT. Ruby lze vyzkoušet na webové stránce TryRuby. U příležitosti 30. narozenin, první veřejná verze Ruby 0.95 byla oznámena 21. prosince 1995, proběhl redesign webových stránek.
Všem čtenářkám a čtenářům AbcLinuxu krásné Vánoce.
Byla vydána nová verze 7.0 linuxové distribuce Parrot OS (Wikipedie). S kódovým názvem Echo. 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.
Vývojáři postmarketOS vydali verzi 25.12 tohoto před osmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell on Mobile, KDE Plasma Mobile, Phosh a Sxmo.
Byla vydána nová verze 0.41.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 5.5 (novinky) skriptovacího jazyka Lua (Wikipedie). Po pěti a půl letech od vydání verze 5.4.
Byla vydána nová verze 5.4.0 programu na úpravu digitálních fotografií darktable (Wikipedie). Z novinek lze vypíchnout vylepšenou podporu Waylandu. Nejnovější darktable by měl na Waylandu fungovat stejně dobře jako na X11.
Byla vydána beta verze Linux Mintu 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.
GNU Project Debugger aneb GDB byl vydán ve verzi 17.1. Podrobný přehled novinek v souboru NEWS.
Zkus toho o problému prozradit trošku víc.
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ř.
A ten alias, to je to "FROM dlouha_tabulka_1 t1, dlouha_tabulka_2 t2" s tím, že všude jinde v dotazu kromě FROM klauzule se použije už jen to t1 a t2.
Tiskni
Sdílej: