ARCHIV

MySQL (50) - Pohledy podruhé

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 | Články autora | přečteno 20078×

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í:

S následujícícmi daty:

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:

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:

1. Tabulku lidi obsahující data
2. Aplikaci, která z této tabulky čerpá, a
3. 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:

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?

1. Tabulka obsahující data zůstala nezměněna
2. Aplikace, která z této tabulky čerpá zůstala rovněž nedotčena
3. 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:

s daty

a pohled, v němž si budete přát zachytit pohyby seřazené podle data a odběratele:

časem ale zjistíte, že bude praktické mít pro odběratele vlastní tabulku:

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:

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.

Verze pro tisk

DISKUZE verze 20.12.2005 11:06 zdenek hejl   Re: verze 20.12.2005 22:10 Petr Zajíc Zobrazit označené Zobrazit vše Příspívat do diskuze mohou pouze registrovaní uživatelé.