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 | czytane 20100×
RELATED ARTICLES
KOMENTARZE
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í.
Svět se mění a my s ním
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:
- Tabulku lidi obsahující data
- Aplikaci, která z této tabulky čerpá, a
- Pohled, který toto čerpání zajišťuje.
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?
- Tabulka obsahující data zůstala nezměněna
- Aplikace, která z této tabulky čerpá zůstala rovněž nedotčena
- Změnil se jen a pouze pohled, který zprostředkovává spojení mezi
aplikací a daty.
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.
Role pohledů při změně struktury dat
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.