Dotaz: Mysql problem s cizim klicem

[Stoupa]

Zdravim, mam tabulky v databazi

CREATE TABLE `komentare` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `id_ukolu` int(11) DEFAULT NULL,
  `id_projektu` int(11) DEFAULT NULL,
  `id_uzivatele` int(11) NOT NULL,
  `popis` text COLLATE utf8mb4_czech_ci NOT NULL,
  `datum` datetime NOT NULL,
  `zmena` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`id`),
  KEY `id_ukolu` (`id_ukolu`),
  KEY `id_uzivatele` (`id_uzivatele`),
  KEY `id_projektu` (`id_projektu`),
  CONSTRAINT `komentare_ibfk_4` FOREIGN KEY (`id_projektu`) REFERENCES `projekty` (`id`),
  CONSTRAINT `komentare_ibfk_1` FOREIGN KEY (`id_uzivatele`) REFERENCES `uzivatele` (`uid`) ON DELETE CASCADE,
  CONSTRAINT `komentare_ibfk_2` FOREIGN KEY (`id_ukolu`) REFERENCES `ukoly` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_czech_ci;

CREATE TABLE `projekty` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `vedouci` int(11) NOT NULL,
  `nazev` varchar(30) COLLATE utf8mb4_czech_ci NOT NULL,
  `popis` text COLLATE utf8mb4_czech_ci NOT NULL,
  `zacatek` date NOT NULL,
  `konec` date NOT NULL,
  `hotovo` tinyint(1) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `vedouci` (`vedouci`),
  CONSTRAINT `projekty_ibfk_2` FOREIGN KEY (`vedouci`) REFERENCES `uzivatele` (`uid`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_czech_ci;

CREATE TABLE `ukoly` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `id_projektu` int(11) NOT NULL,
  `nazev` varchar(30) COLLATE utf8mb4_czech_ci NOT NULL,
  `popis` text COLLATE utf8mb4_czech_ci NOT NULL,
  `zacatek` date NOT NULL,
  `konec` date NOT NULL,
  `hotovo` tinyint(1) NOT NULL DEFAULT '0',
  `id_predka` int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `id_projektu` (`id_projektu`),
  CONSTRAINT `ukoly_ibfk_1` FOREIGN KEY (`id_projektu`) REFERENCES `projekty` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_czech_ci;
  

Kde tabulka komentare ma dva cizi klice id_projektu a id_ukolu. Ovsem pri pridavani komentare do databaze prikazem

insert into komentare values('','','','1','asfas','2012-02-28 07:28:00','')

dostavam chybu

Chyba v dotazu: Cannot add or update a child row: a foreign key constraint fails (`bakp_db`.`komentare`, CONSTRAINT `komentare_ibfk_2` FOREIGN KEY (`id_ukolu`) REFERENCES `ukoly` (`id`) ON DELETE CASCADE)

Nevite nekdo kde by mohl byt problem? Co jsem procital internet tak jsem narazil na vyroky, ze cizi klic muze byt nabyvat hodnoty null.

---

---

Odpovědi

[Filip Jirsák]

Vy tam nevkládáte NULL, ale prázdný řetězec. MySQL to kupodivu povolí a asi jej převede na nějaké číslo. Předpokládám, že jste chtěl spíš provést

INSERT INTO komentare (id, id_ukolu, id_projektu, id_uzivatele, popis, datum, zmena)
  VALUES (DEFAULT, NULL, NULL, 1, 'asfas', '2012-02-28 07:28:00', DEFAULT)

nebo

INSERT INTO komentare (id_uzivatele, popis, datum)
  VALUES (NULL, NULL, 1, 'asfas', '2012-02-28 07:28:00')

když už tam máte nadefinované ty výchozí hodnoty.

Jinak nechápu, proč se tam všude snažíte nacpat řetězce, když to mají být čísla. Výchozí hodnota pro sloupec zmena taky vypadá dost podivně a s velkou pravděpodobností by tam spíš mělo být NULL.

[Stoupa]

Dekuji moc mi to pomohlo.

[Šangala]

Doplnění ke konverzi:
Implicitní konverze textu na číslo zařídí, že nečíselný řetězec (respektive neobsahující zleva nějakou číselnou reprezentaci) je nula - tedy i prázdný řetězec.

[Šangala]

Abych předešel další debatě o implicitní konverzi .
Je to dle nastavení serveru, případně dle nastaveni uživatelského(session) sql_mode, pokud je nastavení takové, jak bylo vždy u MySql zvykem,tedy ne-striktní--volné, tak je při konverzi na číslo z hodnot '' nebo 'kuk' nebo '1kuk' vyvolán jen warning (v prvních dvou případech 1366, tedy nekorektní hodnota, v posledním případě 1265, tedy ořezání dat.)
Pokud je nastaven rozumnější režim (například pomocí: set @@session.sql_mode='STRICT_ALL_TABLES';), tak jsou všechna tato varování již chybami (stávající nastavení lze zjisti přes select @@sql_mode;).

[Kit]

Častou chybou je chybná práce s timestampem. Chybně:

insert into komentare values('','','','1','asfas','2012-02-28 07:28:00','');

lépe:

insert into komentare values('','','','1','asfas',now(),'');

Nejlépe asi funguje datový typ timestamp, který se aktualizuje při každé změně záznamu. Ovšem i to je potřeba si řádně rozmyslet, protože vždy to vhodné není.

Je možné, že podobná programátorská chyba způsobila včerejší nefunkčnost systému na vydávání občanských průkazů. SQL databáze takové chyby už dlouho nedělají.

[Filip Jirsák]

Pak by se hodilo mít now() jako default pro daný sloupec, případně ho rovnou plnit nějakým triggerem a zakázat jeho změnu. Ale nevím, co z toho je řešitelné v MySQL.

[Kit]

Tohle funguje:

create table pruchod(jmeno varchar(255), created TIMESTAMP DEFAULT NOW());

Po updatu sloupce jmeno se created nezmění.

[Filip Jirsák]

Jistě, nemyslel jsem si, že je na tom MySQL zas tak špatně Šlo mi spíš o to, aby tu hodnotu nebylo možné při insertu nastavit na jinou nebo updatem změnit. Ale na takhle silné kontroly na straně databáze si uživatelé MySQL zpravidla nehrají.

[Šangala]

Definice sloupce v MySQL (bo nelze použít fce v default při create table):

Iniciliazicae na NOW() a při každém UPDATE nastavení na NOW()
`name_changedat` TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
nebo
`name_changedat` TIMESTAMP;

Jen iniciliazicae na NOW()
`name_createdat` TIMESTAMP DEFAULT CURRENT_TIMESTAMP

Jen UPDATE na NOW() (ale funkční to bude jen tehdy je-li povoleno NO_ZERO_DATE)
`name_createdat` 0 ON UPDATE CURRENT_TIMESTAMP

(samozřejmě platí, že nějaký sloupec musí být změněn, tj. musí dojít ke změně nějaké hodnoty řádku)

Ovšem jak při insert, tak i u update lze hodnotu explicitně přepsat.

[Šangala]

Aha, beru zpět na základě příspěvku a odzkoušení, že nelze použít funkce, evidentně alespoň NOW() funguje.
Ale pomoci update lze hodnotu přepsat, aby to nebylo možné, musel by se použít trigger.

[Kit]

Dá se využít GRANT a pohledy, ale na to si uživatelé MySQL zpravidla nehrají.