Portál AbcLinuxu, 11. května 2025 06:05
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:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.