|
|
abstrakce a modularita
|
9.12.2005 15:16
Johann von Nepomuk
|
hledal jsem v clanku slovo abstrakce nebo modularita a nenasel jsem. To me prekvapilo, nebot to ma byt ten hlavni duvod, proc se views vubec implementovaly.
Uvital bych, kdyby mohl autor tuto problematiku rozvest. V kazde diskuzi o DB to prijde na pretres, kdyz se mluvi o modularite ve spojitosti s SQL a relacnim modelem, ale priklady se nikde clovek nedovi. |
|
|
|
|
Re: abstrakce a modularita
|
9.12.2005 18:13
Petr Zajíc
|
| Tedy, pokud se vážně views implementovaly kvůli abstrakci a modularitě, pak nevím, jestli to za to vůbec stálo ;-(. Protože podle mého názoru mají opravdu spíš funkci zástupců na nějaká existující data či slouží jako virtuální tabulky. Jediné, co je podle mě v relačních DBMS opravdu modulární jsou tabulky jako takové, ale ne pohledy. Nevím, možná tou modularitou myslíme každý něco jiného... |
|
|
|
|
Re: abstrakce a modularita
|
10.12.2005 12:29
Petr Čermák
|
abstrakce - u velkych databazi potrebujete casto nejaka "spocitana" data. Na projektu dela vice lidi, projekt se sklada z vice casti. Ostatni casti/lide nepotrebuji vedet, jak jsou tato data spocitana a proto se uzivaji pohledy, aby odstinily od konkretni implementace.
Obdobne se pohledy uzivaji napriklad pokud pracujete nad databazi systemu, ke kteremu nemate pristup / spravuje jej nekdo jiny. Vase aplikace bude pouzivat pouze Vase pohledy a pri zmene teto databaze staci upravit pohledy, ne celou aplikaci.
Dalsim prikladem abstrakce je napriklad objektektove-relacni mapovani, kdy pohledy reprezentuji objekty stredni vrstvy a mapovani je pak o dost jednodussi.
Dalsi vyhodou pouzivani pohledu muze byt zvyseni vykonu. Kazdy chytrejsi db stroj dotazy ktere selekti pohled predkompiluje. |
|
|
|
|
Re: abstrakce a modularita
|
10.12.2005 14:36
Petr Zajíc
|
Aha
když to chápeme takhle, pak jsitě ano. Já jsem uvedené výhody ve vyspělých databázích přisuzoval vždycky spíš uloženým procedurám než pohledům, ale budiž. Jinak s tou předkompilací pohledů si nejsem jist, jak je na tom MySQL. Jak jste správně napsal, tak "každý chytřejší db stroj" to dělá; u MySQL si tím nejsem jistý.
S čím bych naopak v praxi moc nesouhlasil je tvrzení, že by měla mít každá aplikace svoje pohledy (ne že byste to snad tvrdil, že to je nejlepší, ale používá se to). Pak to totiž může dopadnout tak, že se bude mnoho pohledů duplikovat - a třeba MySQL pokud vím neupraví pohled(y), jestliže se změní podkladová tabulka. |
|
|
|
|
Re: abstrakce a modularita
|
10.12.2005 18:30
Johann von Nepomuk
|
...Vase aplikace bude pouzivat pouze Vase pohledy a pri zmene teto databaze staci upravit pohledy, ne celou aplikac ...
toto je ten typicky priklad, kdy aplikace je nejaky GUI-modul, ktery ma pevne zakomponovane sql-statemens, ktere se obraci pouze na pohledy a jak pisete, kdyz se zmeni databaze, tak se sahne do tech podledu a nemusi se sahat do toho GUI. To je ta abstrakce. (GUI _odhlizi_ od konkretni vystavby tabulek). Tento priklad je znamy.
Samozrejme, ze je to take soucasne modularni pristup, protoze GUI je modul, ktery je porad stejny a zmeny se provadi pouze na rozhrani. Me chybi spise ale priklady z aplikacni vrstvy. Napr. chci v ekonomicke aplikaci modularne resit problematiku zjistovani dispozicnich profilu ve vyrobnim podniku. Zde musim zjistovat kolik je fyzicky na sklade, kdy bude vyroba kolik protrebovat, kdy budou pravdepodobne naplneny otevrene objednavky, kolik je na ceste, kolik v konsignacnich skladech atd. Jak lze toto resit pomoci pohledu modularne?
Udela se nejaky intergalakticky pohled , ktery se bude upravovat pri zmene databaze? A zrovna tak napr. pri zmene strategie pri vyuziti konsignacnich skladu?
To byla tedy ma otazka. ten GUI je jasny. Ale jinak? |
|
|
|
|
Re: abstrakce a modularita
|
11.12.2005 13:45
Petr Zajíc
|
| Hmm... to je spíš na aplikační server, než na "holý" pohled v databázi. Jinak příklady v seriálu uvádím zcela záměrně co nejjednodušší, aby to bylo pro nováčky vstřebatelné. |
|
|
|
|
a co vykon
|
12.12.2005 23:54
Filip Krejčí
|
| Docela by mne zajimalo jaky dopad ma pouzivani pohledu na vykon. Prece jenom, pokud to spravne chapu tak vlastne pokud udelam dotaz na tabulku ktera je pohledem tak pohled samotny se musi nejak sesynchronizovat s ostatnim tabulkama ze kterych pochazi takze musi taky provest dotaz -> takze jsou zrejme provedeny dva dotazy ? nebo to je jinak ? jak se to synchronizuje ? je snizeni vykonu dani za tuto abstraktni vrstvu? |
|
|
|
|
Re: a co vykon
|
13.12.2005 12:22
Petr Zajíc
|
Chápete to správně. Dotaz musí databázové jádro pochopitelně přeložit na příkaz, jímž získá data z podkladových tabulek. Jestliže je navíc dotaz založen na dotazu, musí se to celé "kaskádově" vyřešit až k podkladovým tabulkám.
K výkonu: obecně platí, že to nějakou tu dobu potrvá, ale obecně rovněž platí, že pohled může být předkompilován. To znamená, že databáze už může "předem vědět", zda pro uspokojení tazatele použije průchod tabulkou, nějaký index nebo jejich kobminaci a podobně.
To platí obecně. V MySQL jsou pohledy čerstvou záležitostí, takže bych na jejich optimalizaci zas až tak moc nesázel. |
|
|
|
|
|
|
KOMENTARZE
|
|
Tylko zarejestrowani użytkownicy mogą dopisywać komentarze.
|
|
Szukanie oprogramowania
|
bootable [55]
linuxsoft.cz | Design:
www.megadesign.cz