Darko je postavio dva zanimljiva pitanja/teme. Nažalost (barem je to moje mišljenje) ova pitanja su proizvela mlaku reakciju. (Verovatno je to znak da su pitanja upravo zanimljiva samo meni :) )
Jedna od osnovnih ideja nastanka baza podataka je centralizacija podataka i njihova dostupnost raznim aplikacijama putem standardizovanog interfejsa. Drugim rečima - ideal je da istoj tabeli s podacima o radnicima pristupa i aplikacija za kadrovsku evidenciju i recimo aplikacija za evidenciju sitnog inventara u upotrebi.
Tako ću i ja poći od predpostavke da jednoj bazi podataka može da prisuta više aplikacija.
Uzeću za primer ono što može jako da zaboli, a to je obračun PDV-a.
Za izračunavanje PDV-a nam je dovoljno da znamo poresku osnovicu i stopu poreza (naravno i forumulu :) ). Ovo navodi na zaključak da je u bazi dovoljno čuvati samo ova dva podataka: poresku osnovicu i stopu poreza, dok se sve ostalo može izračunati.
Ovde u igru ulazi moja predpostavka da ove podatke koristi više programa, pa se tako iz jednog programa štamaju fakture, dok se iz drugog programa vrši mesečni obračun PDV-a i štampanje evidencije. Naravno da stvar bude komplikovanija ova dva programa su radili različiti programeri na različitim platformama. I pored sve sposobnosti ova dva programera, lako se može desiti da zbir obračunatog PDV-a po fakturama neodgovara PDV evidenciji koju prikazuje drugi program. Ključna stvar u nastanku ovakvog problema može biti zaokruživanje! Jedan programer je primenuo zaokruživanje po matematičkim pravilima dok je drugi programer zaboravio da izvrši zaokruživanje već je prikaz na 2 decimale rešio postavljanjem maske za štampanje.
(Digresija: Problem može da nastane i u bazi. Recimo da se radi o InterBase-u 6.0 i recimo da imamo kolonu čiji je tip podataka NUMERIC(10,2). Naravno ovo 2 bi trebalo da označava da ova kolona nemože da pohrani više od dve decimale... ali to nije slučaj sa IB6! On će bez problema u takvu kolonu upisati i podatak sa 3 decimale i kasnije ga takvog i prikazati!)
Da se vratim na temu... Da bi se izbegao problem neslaganja podataka iz dva programa iz priče, programeri su se dogovorili da prvi program izračuna PDV, pravilno ga zaokruži i da ga onda upiše u bazu. Drugi program prilikom obračuna u bazi ima dostupnu i osnovicu i stopu i PDV - milina, reklo bi se.
Ali... posao si širi - postoji potreba za remote fakturisanjem i pojavljuje se treći programer koji je na trećoj platformi napravio program za fakturisanje koji se od prvog razlikuje po tome što nije toliko kitnjast i lak za upotrebu, ali nije zahtevan po pitanju bandwidth-a i može se koristiti remote i sa najgorih modema! Pošto se i ovde u suštini radi o programu za fakturisanje i ovde je programer u obavezi da sračuna PDV, i da ga upiše u bazu pored osnovice i stope.
Ovde može doći do razlike u zaokruživanju zbog korišćenja različite platforme! Ako mi neverujete, setite se baga u originalnom Pentiumu pri računanju sa pokretnim zarezom, ili najnovijeg baga u programu Excel 2007! Nema garancije da dve platforme na isti način rade zaokruživanje. (Ne kažem da nebi trebalo da se računa na isti način, već samo da nebih smeo da se kladim da je to tačno.)
I recimo da do toga i dođe! I sada imamo apsurdnu situaciju da je prvi program u bazi prosledio:
Code:
INSERT INTO fakture (osnovica, stopa, pdv) VALUES (113, 18, 20.42)
dok je drugi program (odnosno treći) bazi prosledio:
Code:
INSERT INTO fakture (osnovica, stopa, pdv) VALUES (113, 18, 20.43)
Za istu osnovicu i za istu stopu su ova dva programa prosledila različite poreze!
Eto nam za čas posla anomalije u podacima. Problem smo napravili još prilikom uvođenja kolone sa izračunatim pdvom!
I šta nam ostaje kao izlaz iz ovog problema? Da matematiku obračuna poreza centralizujemo na jedno mesto! Neko će reći - application server koji se obraća bazi dok se ostali programi obraćaju njemu. Ali ovo se kosi sa osnovnom predpostavkom o upotrebljivosti baze, a to je da baza treba da bude dostupna SVIM programima (i to neposredno)!
Preostaje nam da matematiku obračuna pdva na neki način smestimo u bazu, bilo to procedurama, trigerima ili pogledima.
Naravno bilo bi lepo da neka buduća varijanta SQL standarda definiše i standardizovani "application server" koji bi bio neodvojivi deo samog database servera. (Kako bi to trebalo da izgleda? Nemam pojma - samo me je tok misli naveo na ovakav standardizovani application server.)
Iz gore iznetog sledi da i moj glas ide da se matematika smešta u bazu - što je nekada nemoguće uzimajući u obzir sadašnji tehnološki stadijumu baza podataka.
Drugi deo Darkovog pitanja se odnosio na "varijantnost" (prilagodljivost) aplikacije, odnosno baze. Darko je izneo mišljenje da svaki problem, ma koliko bio sličan nekom drugom problemu, zahteva posebnu aplikaciju/bazu. (@Darko Sudarov - Ispravi me ako sam pogrešio u interpretaciji.)
Ovde se delom slažem sa iznetim stavom. Zašto delom? Moraću da se vratim gotovo 40 godina u prošlost da bih izneo svoje viđenje.
Dakle... vraćam se u kraj šezdesetih i početak sedamdesetih godina, u godine kada je nastala ta divna tvorevina zvana relaciona teorija. Znamo da je otac te teorije slavni E.F. Codd, a posebno ću se osvrnuti na jedan od njegovih radova iz tog perioda "A Relational Model of Data for Large Shared Data Banks" što bi se po naški reklo "Relacioni model podataka za velike deljene baze podataka".
Kakvo je bilo hardversko-softversko okruženje u tom momenu. Kompjuteri su bili veliki i skupi, a programi malobrojni. Ovo znači da nije svako mogao sebi da priušti kompjuter. Posedovanjem kompjuta su se ponosile državne ustanove, banke, velike firme. Izdaci za hardver su bili ogromni i onaj ko je bio u stanju da ih plati, taj je hteo i da opravda investiciju i hteo nehteo morao je da ima programera u svom okruženju, jer bi bez programera tako skupa mašina bila neupotrebljiva.
Podaci su se gomilali, njihova obrada je bila sve komplikovanija, i traženo je rešenje problema organizovanja velike količine podataka.
Ovde ću potegnuti spomenuto Codd-ovo delo, odnosno samo jednu reč iz njegovog naslova, a ta reč je VELIKO!
Relacioni model je nastao kao rešenje za struktuiranje VELIKE količine podataka - ovde se neradi o personalnom imeniku sa brojevima telefona prijatelja i rodbine! Ovde se radi o VELIKOJ količini podataka.
I svaka institucija koja je posedovala taj skupi kompjuter je u isto vreme posedovala i database programera koji je isključivo za njihove potrebe primenjivao najnovija dostignuća u rešavanju struktuiranja podataka. Svaki od tih database programera je pravio bazu podataka i aplikacije isključivo za matičnu firmu i isključivo po zahtevima i potrebama matične firme. I naravno takva baza i takva aplikacija nisu bili primenljivi na bilo koju drugu organizaciju, jer je kako to već znamo svaka organizacija priča za sebe.
Jeste taj programer unutar firme koštao i jeste bio neupotrebljiv van firme, ali je ipak on i dalje koštao manje od tog skupog kompjuterea!
Naravno da ovo gore idealizujem i da u stvarnosti nije baš bilo ovako, ali se nadam da sam dočarao generalnu sliku ambijenta.
Ono što sam hteo da kažem je da je relaciona teorija napravljena u vremenu kada je svaka baza podataka bila namenski i ciljano pravljena za isključivo jednu organizaciju.
Naravno, jedan firma poput Forda se bavila proizvodnjom automobila ali se nije bavila proizvodnjom biciklova koliko god to delovalo slično ili ne. Programeri u Fordu su pravili bazu i programe za praćenje proizvodnje automobila i to isključivo po Fordovoj specifikaciji i nije ih bilo briga da li je taj program primenljiv u Mercedesu, a kamoli da li je taj program upotrebljiv u proizvodnji biciklova! Oni su radili za Ford i tu je prestajala njihova briga o prilagodljivosti programa.
Vremenom su kompjuteri ulazili u sve više organizacija i firmi i postajali sve jeftiniji, a samim tim je i cena rad programera počela značajno da utiče na troškove firme. Nije više bilo isplativo držati veliki tim programera u okviru firme, te su počele da nastaju i softverske firme koje su nudile svoje usluge.
E takvoj jednoj softverskoj firmi je bina priča o prilagodljivosti njenog programa! Program mora da bude extra fleksibilan da bi softverska firma od njegove eksploatacije imala što veću korist. Naravno ovo je sve više počelo da se kosi sa idejom o relacionoj teoriji jer je ona nastala iz potrebe da se struktuiraju VELIKE količine podataka, a počela je da se primenjuje u sve manjim i manjim projektima, što je neumitno dovelo do njene degradacije i stavljanja u podređeni položaj.
Kao što je Savkić rekao - softverskim kućama je bitno da se njihova baza i aplikacija vrte na raznim database platformama. To znači da takav jedan program nesme da iskorištava pogodnosti koje na primer nudi Oracle u odnosu na recimo PostgreSQL, kao što je na primer upotreba analitičkih funkcija u SELECT naredbama!
To je isto kao da auto Formule 1 vozite kroz grad koji je načičkan semaforima. Bez obzira koliko je taj auto brz, praktična brzina kretanja je 60 km na sat uz naravno povremene bljeskove u ubrzanju, zvuku i zadivljenim pogledima koje ostavljate za sobom.
Softver se jednostavno sve manje i manje pravi namenski, a sve više i više se pravi tako da zadovoljava što veći krug klijenata. To praktično znači da će isti softver za obračun sa kooperantima koristiti i u mlečnoj i u duvanskoj industriji uz nekakvu parametrizaciju unutrašnjeg ponašanja softvera.
Da li je ovo dobro? Mislim da nije, i mislim da je zaista svaki problem priča za sebe, i da kao takav zahteva specifični pristup i specifično rešenje. Nažalost, uslovi na tržištu su takvi da je ovakav stav osuđen ili na propast ili na korekciju i popuštanje.
Kao primer gore iznetog, navešću banalan problem strukturre konta glavne knjige u dve imaginarne firme.
U jednoj firmi se koriste konta dužine 6 cifara, dok se u drugoj firmi koriste konta dužine 8 cifara. Prvoj firmi bi prirodno odgovaralo da je konto definisan kao tip podataka CHAR(6) uz dodatni CHECK CONSTRAINT koji će proveriti da se konto isključivo sastoji od cifara i da je tačno dužine 6. Drugoj firmi prirodno odgovara da je konto definisan kao tip podataka CHAR(8) uz dodatni CHECK CONSTRAINT koji će proveriti da se konto isključivo sastoji od cifara i da je tačno dužine 8!
Da se radi o gore spomenutom Fordovom programeru, bilo bi mu nametnuto da koristi recimo 6 cifara i da ga baš briga što Mercedes koristi 10 cifara! Ali pošto program radi nezavisna softverska kuća, njoj je itekako stalo da isti program može da koristi i Ford i Mercedes i zato se ona odlučuje da je konto tipa VARCHAR(20) (za svaki slučaj da ima još mesta) i nema dodatnog CHECK CONSTRAINTA na dužinu konta već će dužinu konta određivati aplikaciju u zavisnosti od podešenog parametra. Na taj način se isti program može ponuditi većem broju kupaca.
Šta se na ovaj način gubi? Gubi se snaga baza podataka u osnovnoj validaciji prosleđenih podataka! Logika o dužini konta se silom prilika iz baze preselila u aplikaciju! Ako se podsetimo da baza treba da bude široko dostupna svakoj aplikaciji koja poželi da je koristi, kako će novo-napravljena aplikacija interpretirati konto dužine 20?! Kako će se ponašati? Koga taj novi programer da pita šta da radi sa takvim monstrumom od tipa?
Da stvar bude još gora - ovde se u priči radi o samo jednoj jedinoj koloni! A takvih VARCHAR(20), VARCHAR(50), VARCHAR(100) kolona ima stotine u složenijim aplikacijama.
I šta onda radi nezavisna softverska kuća? Jednostavno kaže - Ovoj našoj bazi možete da pristupate isključivo upotrebom naše aplikacije! Mi ćemo se potruditi da sprečimo pristup bilo kojoj drugoj aplikaciji, a ako saznamo da ste ipak na neki način upotrebili našu bazu sa nekim drugim programo, tada više ne odgovaramo za podatke u bazi!
Znači ubijen je osnovni smisao postojanja baze podataka, a to je njena dostupnost, i vraćamo se 40 godina u nazad kada je svaki program imamo svoje podatke koje je koristio u svom radu. Upravo je takva situacija dovela do potrebe da se izmisli sistem za DELJENJE podataka.
HUH.... čini mi se da sam se negde izgubio u poentiranju gornjeg teksta, ali mi ne zamerite ;)
Sve u svemu - tržište nas tera da pravimo univerzalne prilagodljive parametrizovane baze i aplikacije iako zdrava logika govori da to nije dobro, jer su takve aplikacije generalno teže za korišćenje i održavanje, podložnije su greškama i sprečavaju slobodu upotrebljivosti pohranjenih podataka.
"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo