Přeskočit na hlavní obsah

MySQL 5.0 díl.1

Od verze 5.0 je možné využívat nových vlastností, které nabízí skutečnou správu dat v databázi.

Jednotlivé vlastnosti rozepíši do vlastních dílů.

V prvním díle se budu věnovat referenčním integritám. Referenční integritu bylo možné využívat již dříve. Respektive od doby, kdy MySQL podporovala typ tabulky InnoDB.

Proč vůbec databáze používá tuto vlastnost? Pokud začnu pracovat s daty v databázi, zjistím, že některé se přímo vážou na jiné. Dříve se používal způsob uchování těchto vazeb v aplikační úrovni.
Nevýhody, které to sebou přinášelo je hned několik:

  • programátor musel stále mít v paměti, která data jsou propojena a podle toho provozoval akční dotazy

  • při změně aplikace nad databází se znovu musely tyto vazby naprogramovat

  • při provedení UPDATE se museli projít všechny vazby a upravit hodnoty

  • a tak dále...



Při použití referenčních integrit v MySQL tyto nepříjemnosti odpadnou.

Jak jsem již psal na začátku, pro využití referenčních integrit musíte použít takový typ tabulky, který danou vlastnost podporuje. Osobně jsem volil nejlepší možnou variantu a to InnoDB.

Lepší než další povídání bude malý příklad:

Mám tabulku uživatelů a tabulku návštěvnosti. Dejme tomu, že u návštěvnosti budu uchovávat informace o počtu návštěv za každý den.

CREATE TABLE uzivatele (
login varchar(10) NOT NULL,
heslo varchar(255) NOT NULL,
jmeno varchar(100) NOT NULL,
prijmeni varchar(100) NOT NULL,
PRIMARY KEY(login)
)ENGINE=InnoDB;
CREATE TABLE uzivatele_navstevnost (
uzivatel varchar(10) NOT NULL,
datum date NOT NULL,
pocet int NOT NULL default '0',
PRIMARY KEY(uzivatel, datum)
)ENGINE=InnoDB;


Vše se zdá být v pořádku. Ale co se stane ve chvíli, kdy některý uživatel změní login? Co se stane ve chvíli, kdy některého uživatele smažu?
Nyní mám dvě možnosti, buď v aplikaci budu udržovat vztah uzivatele:login vs. uzivatele_navstevnost:uzivatel nebo použiji referenční integritu.

ALTER TABLE uzivatele_navstevnost
ADD CONSTRAINT fk_uzivatel_uzivatele
FOREIGN KEY(uzivatel) REFERENCES uzivatele(login)
ON UPDATE CASCADE ON DELETE RESTRICT;


Co jsem v podstatě udělal? Vytvořil jsem cizí klíč v tabulce uzivatele_navstevnost s nazvem fk_uzivatel_uzivatele. Nyní, pokud provedu UPDATE loginu v tabulce uzivatele, změní se mi login uživatele i v tabulce uzivatele_navstevnost. Pokud se pokusím smazat uživatele z tabulky uzivatele, dotaz skončí s chybou. Důvodem je definování DELETE RESTRICT. Zde je jasné, že vlastnost pro DELETE přepíši na CASCADE.

Samotný význam referenčních integrit není usnadnit práci vývojářům při manipulaci s daty, ale udržet data ve správné formě.
Vlastnosti pro UPDATE a DELETE pro cizí klíč jsou následující:

  • CASCADE - provede změny ve sloupci podle změny v referenčním sloupci

  • RESTRICT - znemožní upravit či smazat data

  • SET NULL - při nastaveni refenečního sloupce na NULL či smazání, nastaví se sloupec cizího klíče na NULL (zde samozřejmě je třeba, aby cizí klíč měl možnost obsahovat NULL)



Na předchozím příkladu jsem ukázal možnost vytvoření referenční integrity mezi dvěmi tabulkami, ale existuje možnost vytvoření takovéto integrity v zájmu jedné tabulky.

Příklad:

Budu mít tabulku zaměstnanců, která navíc obsahuje vztah nadřízený-podřízený.

CREATE TABLE zamestnanci (
osobni_cislo int NOT NULL,
jmeno varchar(100) NOT NULL,
prijmeni varchar(100) NOT NULL,
nadrizeny int default NULL,
PRIMARY KEY(osobni_cislo),
CONSTRAINT fk_nadrizeny_zamestnanci
FOREIGN KEY(nadrizeny) REFERENCES zamestnanci(osobni_cislo)
ON UPDATE CASCADE ON DELETE SET NULL
)ENGINE=InnoDB;


S definicí referenčních integrit navíc souvisí i správný návrh databáze. K tomuto problému lze říci jen jedno: mít zkušennosti.

V příštím díle se budu věnovat opět typu InnoDB a další vlastnosti a to transakčnímu zpracování.

Komentáře

Populární příspěvky z tohoto blogu

Jak si v IT vydělat hodně peněz?

Na začátek by bylo dobré, abych objasnil samotný titulek, který může na někoho působit jako červený hadr. Článek nebude o obecných pravidlech, ale bude vyprávět můj vlastní příběh, na kterém vám zkusím ukázat, jak se dá docílit úspěchu, či alespoň správně nastartovat svojí vlastní kariéru v IT.

I když se z názvu článku dá dedukovat, že se vše bude točit kolem peněz, není tomu tak. Alespoň ze dvou třetin určitě ne. Ale to už předbíhám, pojďme to raději vzít hezky popořadě...

Kdybychom měli mluvit o roce 2017 jako o přelomové době, nejspíše to nebude pravda. I když pro někoho to může být rok plný úspěchů a štěstí v podobě narození zdravých dětí, svatby či první velké lásky, tak z pohledu lidstva se jedná o rok, který jen kopíruje předešlé a v oblasti technologií nás posouvá stejným tempem jako rok předtím.

Jsem naprosto přesvědčen o tom, že i když se současná doba tak nenazývá, tak prožíváme dobu, která jednou bude označena za revoluční, a to zejména díky vynálezu internetu, který je st…

Jak by se firmy neměly chovat k programátorům?

Každý, kdo pracuje v IT oboru, se jistě již setkal s různými „geniálními nápady“, od kterých si firma slibovala zlepšení produktivity či snížení nákladů. Ať už je to zavedení agilních principů, striktní kontrola práce či zavedení nové a skvělé metodiky, o které si „šéf“ přečetl včera na internetu. Jsou z toho skutečně tak nadšení i samotní vývojáři? A bude nový nápad fungovat?
K napsání tohoto článku mě navedly různé programátorské diskuze, kde si lidé stěžovali na firmu, kde pracují. Příklady, které zde uvedu, jsou z reálné praxe. Ať už jsem je zažil jako řadový programátor, či jako šéf týmu.
I když je poptávka po programátorech tak vysoká, že Vás headhunteři nahánějí i ve chvílích, kdy o to opravdu nestojíte, tak i přes to je mnoho lidí, kteří se bojí opustit svoje současné zaměstnání.
Čeho se nejčastěji bojíme? Je to samozřejmě nejistota, kterou si často omlouváme větami jako: „Tady mám své pohodlí, co když to jinde mít nebudu?“ nebo „I když mě to v práci štve a nebaví, tak mě ale…

Jak jsem technologicky postavil startup

Tento příběh pojednává o technologiích, nástrojích a vůbec o všem, co jsem potřeboval k tomu, abych byl schopen, postavit startup na zelené louce.

Každý správný příběh začíná stejně: "Jednou jsem...."

Kapitola první: Nápad
Jednou jsem se setkal s člověkem, který měl nápad na produkt, který se v průmyslu zatím nevyskytuje. I přes prvotní skepsi, kdy jsem si říkal: "Tohle už přeci dávno v průmyslu existuje, ne?", jsem došel ke zjištění, že nikoli.

Tím jsem se dostal ke svému prvnímu poučení. Průmysl je technologicky dost zabržděný. Osobně se domnívám, že těch důvodů, proč tomu tak je, je několik. Za prvé je to fakt, že většina lidí, kteří se pohybují v tomto odvětví jsou často konzervativní a za správné považují pouze léty osvědčené věci. Druhým důvodem je to, že jakákoli změna znamená riziko. Ať už z pohledu finanční ztráty tak i z pohledu stability výroby. No a třetím a nejzásadnějším důvodem je to, že ač zde máme spousty technologických vymožeností, narážíme na to,…