Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia AI asistenta Lumo.
Amazon koupil společnost Bee zaměřenou na nositelnou osobní AI aktuálně nabízející náramek Pioneer (YouTube) s mikrofony zaznamenávající vše kolem [𝕏, LinkedIn].
Společnost Teufel nedávno představila svůj první open source Bluetooth reproduktor MYND.
Byla vydána verze 4.2 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Anton Carniaux, právní zástupce Microsoft France, pod přísahou: Microsoft nemůže garantovat, že data z EU nepředá do USA bez EU souhlasu, musí dodržovat americké zákony.
Byl vydán Mozilla Firefox 141.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Lokální AI umí uspořádat podobné panely do skupin. Firefox na Linuxu využívá méně paměti. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 141 je již k dispozici také na Flathubu a Snapcraftu.
NÚKIB upozorňuje na kritickou zranitelnost v SharePointu. Jedná se o kritickou zranitelnost typu RCE (remote code execution) – CVE-2025-53770, která umožňuje neautentizovaný vzdálený přístup a spuštění kódu, což může vést k úplnému převzetí kontroly nad serverem. Zranitelné verze jsou pouze on-premise verze a to konkrétně SharePoint Server 2016, 2019 a Subscription Edition. SharePoint Online (Microsoft 365) není touto zranitelností ohrožen.
Společnost Valve zpřísnila pravidla pro obsah, který je možné distribuovat ve službě Steam. Současně řadu her ze Steamu odstranila. V zásadách a pravidlech přibylo omezení 15: Obsah, který by mohl porušovat pravidla a normy stanovené zpracovateli plateb a souvisejícími sítěmi platebních karet a bankami nebo poskytovateli připojení k internetu. Sem spadají zejména určité druhy obsahu pouze pro dospělé.
Dle analytics.usa.gov je za posledních 90 dnů 6,2 % přístupů k webových stránkám a aplikacím federální vlády Spojených států z Linuxu.
Jak si zobrazit pomocí Chrome a na Chromiu založených webových prohlížečích stránky s neplatným certifikátem? Stačí napsat thisisunsafe.
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: