K pohledům se vracíme ještě jednou; tentokrát si ukážeme jejich roli při abstrakci datové vrstvy.
16.12.2005 06:00 | Petr Zajíc | přečteno 19557×
Také dnes se budeme v našem seriálu věnovat pohledům. Podíváme se na to, jak nám mohou usnadnit život v konkrétních případech. Trochu mě k napsání tohoto dílu seriálu vedla diskuze v minulém díle, kde jste si přáli více příkladů na pohledy. A také jste chtěli vědět, jak mohou pohledy pomoci v situacích, kdy potřebujeme určitou mezivrstvu, abstrakci mezi aplikací a databází.
Tento otřepaný slogan se dá použít samozřejmě taky na databáze. Je přirozenou podstatou věci, že v naprosté většině databází bude docházet k výměně dat, většinou dost časté. Co je ale potřeba zároveň říci je to, že měnit se budou rovněž požadavky uživatelů na data, která mají databáze poskytovat okolnímu světu. Přičemž za "uživatele" je v této souvislosti potřeba považovat kohokoli, kdo má s daty něco do činění – od programátora po managera.
Uveďme si proto postupně několik příkladů, z nichž – jak alespoň doufám – vynikne síla použití pohledů jako mezivrstvy. Věřím, že další příklady si pak budete moci vymyslet a aplikovat sami.
Mějme třeba tabulku obsahující osobní data nějaké té skupiny lidí:
create table lidi (jmeno
varchar (20), narozendne date);
S následujícícmi daty:
insert into lidi (jmeno,
narozendne) values ('Jarda', '19700101');
insert into lidi (jmeno, narozendne) values ('Jana', '19751231');
insert into lidi (jmeno, narozendne) values ('Petr', '19801010');
Z ní budete chtít vytáhnout jméno člověka a jeho věk. S pomocí pohledů na to můžete jít nějak takhle:
create view vwVek
as
select jmeno, year(now())-year(narozendne) as vek from lidi;
Data z pohledu pak zabudujete do jedné či více aplikací, sestavíte potřebný kód (možná v PHP či v jiném programovacím jazyce) a je to. Takže ve finále máte:
Pozn.: Někteří programátoři si v této souvislosti zvykli označovat pohledy používané v jednotlivých aplikacích (nebo částech projektu) nějakým prefixem. Takže by to mohlo vypadat ve stylu vw_Personalistika_vek nebo podobně. Já jsem zastáncem krátkých jmen pohledů, ale jisté je jedno: zaveďte si systém, a toho se pak držte.
Jednoho dne se ale zjistí, že dotaz je sémanticky špatný. Když se někdo narodí na silvestra, hned následující den mu už pohled vrátí jeden rok věku, stejně jako člověku, který se narodil téhož roku, jenomže na nový rok. Takže nezbude, než milý pohled lehce přepsat ve stylu:
select jmeno,
case when dayofyear(now())>=dayofyear(narozendne) then
year(now())-year(narozendne)
else
year(now())-year(narozendne)-1
end as vek
from lidi
Teď už bude program porovnávat nejen letošní rok s rokem narození člověka, ale bude se rovněž zabývat zbylou částí data. (Hrátky s daty nejsou námětem tohoto článku, takže příklad vezměte s rezervou). Co se ale v tomto případě stane s naším projektem?
Z toho všeho je jasně vidět, že vhodným použitím pohledů si můžeme ušetřit mnoho práce při sestavování prakticky jakéhokoli databázového projektu.
Možná namítnete, že předchozí příklad nebyl zase až tak přesvědčivý. Že šlo o chybu na straně logiky aplikace, kvůli níž by se tak jako tak muselo něco předělat, a že by se tomu všemu dalo vyhnout vhodným uplatněním zlatého pravidla "Dvakrát měř, jednou řež". To může být pravda, existuje však řada dalších příčin, kvůli nimž budete muset nakonec sáhnout na pohledy. Jednou z častých je změna struktury databáze.
Ideální databáze nikdy nemění svou strukturu; ale to je v praxi k vidění málokdy. Často to bývá tak, že z různých důvodů bývá nutné strukturu tabulek měnit. Schválně ukážu učebnicový příklad. Máte tabulku, která zachycuje výdej položek ze skladu:
create table pohyb
(zbozi varchar(50), datum datetime, odebral varchar(20));
s daty
insert into pohyb
(zbozi, datum, odebral) values ('Šrouby', '20051201','Hřebík
František');
insert into pohyb (zbozi, datum, odebral) values ('Matice',
'20051202','Matičný Karel');
insert into pohyb (zbozi, datum, odebral) values ('Podložky',
'20051202','Hřebík František');
insert into pohyb (zbozi, datum, odebral) values ('Podložky',
'20051202','Podložný Josef');
a pohled, v němž si budete přát zachytit pohyby seřazené podle data a odběratele:
create view vwPohyb
as
select datum, odebral, zbozi from pohyb order by datum, odebral;
časem ale zjistíte, že bude praktické mít pro odběratele vlastní tabulku:
create table odberatele
(id int not null auto_increment, jmeno varchar(20) not null, primary
key (id));
insert into odberatele (jmeno) select distinct odebral from pohyb;
alter table pohyb add odberatelid int;
update pohyb join odberatele on pohyb.odebral = odberatele.jmeno set
pohyb.odberatelid = odberatele.id;
alter table pohyb drop column odebral;
Pozn.: Koho to zajímá, pro toho dodáme, že tento postup je součástí procesu, jemuž se říká normalizace databáze a který by se měl udělat předtím, než se databáze skutečně naplní a pustí do ostrého provozu. Rovněž zde uvedený příklad je školácký – žádný zkušený databázový expert by nenavrhl tabulku pohyb tak špatně. Berte to ale jako příklad věci, která se v té či oné podobně v praxi stává.
Co se ale stalo s naším pohledem? Ten přestal fungovat, protože pole odebral se v naší databázi již nevyskytuje. Naštěstí je pomoc snadná, pohled lze upravit:
alter view vwPohyb
as
select pohyb.datum, pohyb.zbozi, odberatele.jmeno as odebral
from pohyb join odberatele on pohyb.odberatelid = odberatele.id
order by pohyb.datum, odberatele.jmeno;
Protože má tento pohled stejnou logiku jako předchozí, aplikace, která z něj těží opět může zůstat beze změny. Existuje ještě celá řada situací v nichž může být dobrý nápad použít pohledy - a v aplikacích se odkazovat na ně – namísto prostého výběru dat z tabulek. Jednou z nich může být potřeba specifického řazení, které jsme již v tomto seriálu probírali. Pohledy tedy mají své místo nejen jako zkratky k datům, ale i jako abstrakční vrstva „vřazená“ mezi aplikace a data. Největším problémem pak často zůstává donutit se důsledně používat pohledy namísto přímých dotazů do tabulek, ale to už je otázka disciplíny nebo interních pravidel pro psaní kódu.