| VyÜlo v t²denφku: | CHIPweek |
| ╚φslo: | 9/96 |
| Datum: | 27. ·nora 1996 |
| Strana: | 25 |
| Rubrika/kategorie: | Principy poΦφtaΦov²ch sφtφ |
| Modul: | V²voj v²poΦetnφho modelu |
| Dφl: | 7 |
Zkusme si nejprve naznaΦit, v Φem spoΦφvala ona änep°φliÜ velkß vhodnost" modelu file server /pracovnφ stanice pro n∞kterΘ aplikace. P°edstavme si jako p°φklad databßzovou aplikaci, napsanou v n∞kterΘm b∞₧nΘm databßzovΘm prost°edφ pro osobnφ poΦφtaΦe standardu IBM PC (nap°φklad FoxPro, FoxBase, dBase apod.). Na konkrΘtnφm databßzovΘm produktu p°itom a₧ tak nezßle₧φ, d∙le₧itΘ je naopak to, aby Ülo o databßzi vyvinutou p°edevÜφm pro prost°edφ samostatn²ch a vzßjemn∞ nepropojen²ch osobnφch poΦφtaΦ∙. TakovΘto databßze se samoz°ejm∞ Φasem p°izp∙sobily existenci lokßlnφch sφtφ a mo₧nosti sdφlenφ centrßln∞ umφst∞n²ch soubor∙ (tj. umφst∞n²ch na file serverech), dokßzaly tuto mo₧nost vyu₧φt, ale jejich samotnß podstata se ji₧ nezm∞nila: tato podstata spoΦφvß v tom, ₧e veÜkerΘ zpracovßnφ dat v databßzi se provßdφ jedin²m programem, kter² b∞₧φ p°φmo na poΦφtaΦi (pracovnφ stanici) u₧ivatele. Rozdφl je vlastn∞ jen v tom, kde jsou umφst∞na vlastnφ data tvo°φcφ änßpl≥" databßze: zda v souboru, kter² se nachßzφ takΘ na u₧ivatelov∞ poΦφtaΦi (a ten pak v∙bec nemusφ b²t zapojen do sφt∞), nebo v souboru umφst∞nΘm centrßln∞ na file serveru. Z pohledu samotnΘ databßzovΘ aplikace p°itom nemusφ b²t rozdφl mezi ob∞ma p°φpady zase a₧ tak patrn² - dφky snaze lokßlnφch sφtφ uΦinit mechanismus sdφlenφ soubor∙ na file serveru co mo₧nß nejmΘn∞ viditeln² si tato aplikace m∙₧e myslet, ₧e zpracovßvß lokßlnφ soubory, p°esn∞ji data umφst∞na v lokßlnφch souborech. V praxi ovÜem musφ databßzovß aplikace p°eci jen brßt do ·vahy n∞kterΘ Φist∞ technickΘ aspekty - nap°φklad to, ₧e k obsahu sdφlenΘho souboru m∙₧e chtφt p°istupovat vφce zßjemc∙ souΦasn∞, a musφ b²t tudφ₧ aplikovßny vhodnΘ strategie a mechanismy, °eÜφcφ takovΘto situace (nap°. formou uzamykßnφ cel²ch soubor∙ nebo jejich Φßstφ).
Nynφ si ale uv∞domme, jak bude naÜe databßzovß aplikace skuteΦn∞ fungovat: p°edstavme si, ₧e mß n∞co najφt v datovΘm souboru velikosti kup°. 10 megabyt∙, kter² musφ cel² prohledat. K tomuto prohledßnφ p°itom musφ dojφt tam, kde samotnß databßzovß aplikace b∞₧φ, tj. na u₧ivatelov∞ poΦφtaΦi. Je-li ale datov² soubor sdφlen², tj. nachßzφ-li se ve skuteΦnosti na centrßlnφm file serveru, musφ b²t nejprve p°enesen po sφti na u₧ivatel∙v poΦφtaΦ. No a to p°edstavuje nemalou zßt∞₧ pro p°enosovΘ cesty, zajiÜ¥ujφcφ propojenφ mezi file serverem a jednotliv²mi pracovnφmi stanicemi. Zßt∞₧ takovΘho rozm∞ru, kterß dokß₧e velmi snadno p°er∙st mo₧nosti a p°enosovΘ schopnosti danΘ sφt∞, a stßt se v²razn²m ·zk²m mφstem, kterΘ tΘm∞° znemo₧nφ praktickΘ vyu₧φvßnφ databßzov²ch aplikacφ v²Üe popsanΘho typu - a obecn∞ pak vÜech druh∙ aplikacφ, kterΘ zpracovßvajφ velkΘ objemy dat jinde, ne₧ se tato data nachßzφ. Podstata problΘmu je p°itom prßv∞ v tom, ₧e ke zpracovßnφ dochßzφ na jinΘm mφst∞, ne₧ kde jsou data skuteΦn∞ ulo₧ena, a v d∙sledku toho jsou nutnΘ obrovskΘ p°enosy dat po sφti. P°enosy, kterΘ ji₧ na prvnφ pohled musφ vzbuzovat pochybnosti o svΘ opodstatn∞nosti - proΦ n∞kam p°enßÜet cel² desetimegabytov² soubor, kdy₧ nßs z n∞j zajφmß nap°φklad jen jeden jedin² byte?
V praxi se samoz°ejm∞ p°enßÜφ po sφti p°eci jen o n∞co vφce dat, proto₧e ob∞ Φßsti aplikace se musφ n∞jak dorozumφvat a dßvat si najevo, co vlastn∞ po sob∞ cht∞jφ a co si posφlajφ. NicmΘn∞ po°ßd p∙jde o velmi malΘ objemy dat, a jejich konkrΘtnφ velikost je navφc pln∞ v moci tv∙rc∙ p°φsluÜnΘ aplikace, rozd∞lenΘ do dvou Φßstφ.