Od fajl sistema do baza podataka i obratno

U jednoj firmi, čije poslovanje solidno poznajem, postoji poslovni informacioni sisitem rađen 2000-e godine i pomalo (ali baš pomalo) menjan i prilagođavan potrebama firme. Jedina krupna izmena je bila kada je uvođen PDV; ostalo su uglavnom intervencije na šminki, dodavanje novih izveštaja, otvaranje početnog stanja kod prelaska u narednu godinu,... Baza je SQL Server 2000, a front end je rađen u Access-u. Na klijentima je Windows XP, a instaliran Access 2002 Runtime; a trenutno se vrši prilagođavanje front end-a novijem Access-u 2007-ici. Operativni sistem na serveru je Windows 2000, a planira se prebacivanje na Small Business Server 2003 R2 paralelno sa uvođenjem Access 2007-ice na klijentima.

U drugoj firmi koja je slično koncipirana postoji poslovna aplikacija rađena u Cobol-u. Operativni sistem na serveru je SUSE, na klijentima je Windows XP, koji se preko telnet-a (dakle, ne preko ssh-a) kače na server i terminalskim pristupom (crni ekran, zelena slova) rade u aplikaciji. Ne postoji baza podataka; kao storage se koristi file system gde su u nekih 500-tinak fajlova smešteni svi podaci.

Manje-više ova dva gornja pasusa su nebitna, jer da bi se stvarno izvagalo koja je od ova dva poslovna informaciona sistema bolji trebalo bi dublje ući u analizu automatizacije posla u aplikacijama (razrešavanje elektronskog izvoda, razduženja-zaduženja raznih magacina (centralni, priručni, prodavnice, trgovački putnici,...), otpremnice,...). Meni praktično treba pregled u čemu je relacioni model (relaciona baza podataka) bolji od fajl sistema i obratno. Ja mogu da se setim dva-tri razloga (npr. referencijalni integritet, kontrola pristupa podacima (mada ne znam kako sve to funkcioniše pod Linux-om, ali mislim da ovo može kod njega da se podesi na nivou fajla),...), pa reko' ima ovde na forumu učenijih ljudi od mene...

Potpis

possibly the biggest joker among his local crowd and perhaps a future book author on that subject

Razlike u razvojnom alatu Cobol (koji ne znam koje se godine prestao razvijati) i Access 2007 su ipak ogromne i potrazi samo Features od novog Accessa i bice ti dovoljno.
Sto se tiche FileSystema i DB - takodje ogromne. Sto se tiche kontrole pristupa, na FSu minimalan nivo je nivo fajla dok sa bazom se taj nivo se moze spustiti na 'nivo podatka'. Takodje istovremen pristup podacima, indeksiranje istih, manipulacija velikim kolicinama podataka, pretrazivanje su na strani DB-a.

Potpis

:: Nemoj se svadjati sa budalom, ljudi cesto nece primjetiti razliku ::

Netreba zaboraviti ni postojanje dovoljno dobrog standardnog jezika za komunikaciju sa bazama podataka. Upotreba baze garantuje da se podaci iz nje mogu isčitati i kojekakvim univerzalnim alatima.

Fajl sistem takvo nešto nema i samu sadržinu fajla interpretira program koji mu pristupa i to tako kako taj program hoće. Primer je običan mp3 fajl kojeg WinAmp prikazuje na jedan način (svira ga), dok će taj isti mp3 Notepad otvoriti kao niz nerazumnih znakova.

Slična stvar bi bila i u ta dva sistema koja se pominju.

Predpostavimo da u oba sistema postoji evidencija o osnovim podacima o kupcima (ime, adresa, telefon). Prvi sistem to čuva u jednom fajlu, a drugi u jednoj tabeli. Ako hoću da napravim program koji će odštampati koverte za sve kupce, to ću lakše uraditi u drugom sistemu jer sa njim mogu da komuniciram standardnim jezikom. U slučaju prvog sistema sa fajlovima - prvo bih morao da utvrdim strukturu podataka, pa bih morao da parsiram fajl, i tek onda da se posvetim štampanju.

Da i ne spominjem da ovo sa kovertama može bez problema da odradi i sam MSWord za par minuta, uz uslov da mu se prosledi standardna baza podataka. Takvo nešto je nemoguće sa fajlovima

Potpis

"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

Razlika je dosta, u korist baza podataka, naravno.
Prva i vrlo praktična je pretraga koja ide čak i do 1:1 000 000 u korist baza podataka.

Sa druge strane:
Cobol iz prve poruke, pretpostavljam, ima 500 tabela a ne 500 slogova.

Neznam da li autora poruke zanima razlika između fajl sistema i baze podataka
- ili cobol baze i SQL Server 200 baze što mi je malo verovatnije.

Tek sad sam primetio ono - Cobol! Poveo me je naslov teme... mada... to ne menja u mnogome poentu mog predhodnog posta.

Potpis

"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

Cobol! Uff. Kuluk je to ...
Silom prilika sam morao pre dve-tri godine da se malo priucim,
kako bi (silom prilika) odrzavao neke stare aplikacije.

Kako sam pre tog slucaja stekao dosta iskustva sa modernim
RDBMS sistemima i OOP (najvise mrsio sa VB6 pa presao na .NET),
mogu iz mog ugla reci da je pisanje i odrzavanje programa
u cobol-u pravi kuluk.
Naravno ja sam samo priuceni "cobolas" i iznosim samo moje
skromno misljenje.

A onda, kad vidim par mojih puuuno starijih kolega koji su u
IT-u jos od pocetka sedamdesetih i kad ih vidim kako
dobro i lako plivaju u svemu tome i sa kojom lakocom
resavaju probleme u tom zastarelom okruzenju, opet se sve
svodi na to da "boj ne bije ljuto oruzje, vec srce u junaka". :-)

No, ja sam ipak 100% na strani RDBMS sistema, OOP pristupu
programiranja, i koriscenju modernih alata.

Evo par primera gde cu navesti koliko je cobol tezak za
rad.

Ono sto na primer zavrsis sa jednim SQL izrazom, u
cobolu to moze da naraste na vise desetina, ako ne i
stotina linija koda.

Ili, na primer kad se menja struktura baze podataka
(potencijalno uvek bolno kada je aplikacija u "pogonu"
i kad imas posla sa "zivim" podacima), opet kod RDBMS-a
sa par DDL DML SQL izraza se problem elegantno resava, dok
sa druge strane, u cobol okruzenju, mora se pisati poseban
program (procedura) za prebacivanje podataka iz file-a
jedne strukture u file sa novom strukturom podataka.

Moze se navesti jos gomila primera. Poenta je da su
moderni alati najvise doprineli povecanju produktivnosti.

Opet, ni cobol me nije ostavio ravnodusnim, sticuci iskustvo
i znanje naisao sam par puta na neke stvari koje su mi se
prilicno svidele. Na primer, ja sam radio u Acucorp ACU cobolu
(skoro ga kupio MICROFOCUS).
Ubijes se od pisanja programa (bukvalno ima puno da se pise)
i kad sve na kraju proradi, ti lepo prekopiras kompajlirani program +
runtime sistem (2-3 fajla) na flash drive i gde god da ga gurnes,
u bilo koji PC, (krenes od DOS masine, pa do zadnjeg aktuelnog Win-a)
to radi, ali bukvalno radi gde god da sam probao.
Plus, isto to razvojno okruzenje ima i runtime za Linux/Unix platforme i
koje sve ne platforme i to sto si kompajlirao npr. pod DOS-om,
isti taj program odmah radi i na ostalim platformama (JAVA slucaj jelte?).

Sto se tice cuvanja podataka, skoro svako (malo mladje)
cobol razvojno okruzenje raspolaze sa svojim internim
sistemom za cuvanje podataka, koji podrzavaju i primarne kljuceve
i indekse i zakljucavanje slogova, kriptovanje, kompresiju ....
Ima i ODBC drivera, pa mozes i iz ACCESS-a da citas
cobol datoteke. Moglo bi tu jos sto sta da se kaze i napise.

I jos nesto, cobol nije nimalo mrtav. Naprotiv, veoma je ziv.
Iz puke radoznalosti pomalo pratim sta se tu desava.
Ima cobola u kom mozes praviti aplikacije koje rade pod WIN32
i koje se na oko uopste ne razlikuju od bilo koje moderne windows
poslovne aplikacije.
Izasao je cobol i na internet, moze da pravi i dinamicki HTML,
moze da se poveze i sa svakim popularnim RDBMS sistemom.
Ima ga napravljenog za programiranje na .NET platformi.
Koga malo vise zanima nek pogleda sta rade MICROFOCUS,
IBM ili FUJITSU. Ne, cobol nije mrtav, ali je "cobolasa" sve
manje i racuna se da vec vlada nestasica malocas pomenutih.

Mozda je sve ovo malo otislo u off, mozda malo i udavih, ipak, nadam
se da ce ovo moje pisanije biti nekome od neke koristi.

Pozdrav,
Bojan

Tema je malo neobicna jer se trazi poredjenje neuporedivog. Suvise je velika razlika da bi se nesto moglo porediti.

Davno sam koristio cobol, programski jezik koji datira mislim od 1956 namenjen poslovnim aplikacijama. Posto se i danas koristi izgleda da je dobro dizajniran.

Ono sto mu daje prednost u trazenom slucaju je verovatno cena. Klijenti su pretpostavljam windows masine. Ali serveri su drugaciji. malo verovatno, ali recimo da su alikacije iste cene. Ali Linux server ne kosta nista. A windows server, pa sql server, pa access bogami kosta i to mnogo. Samo je pitanje da li toliko ulaganje dobro. Za velike firme se ne bi trebalo postavljeti to pitanje, ali za manje nema potrebe toliko se trositi.

Potpis

Pomozite Micro$oftu u borbi protiv piraterije, poklonite prijatelju Linux

Ono, jes' malo(?) neobična tema i bojim se da sam (i pored velikog truda) bio neprecizan. Svi ovi odgovori i iskustva mi znače, ali opet sve je to lični utisak. Dalje, argumenti tipa "DB je kud i kamo brži" ne stoje, jer da bi se to dokazao trebao bi mi identičan test-sistem za jedno i drugo okruženje sa istrom količinom podataka i sa zahtevom za istim izveštajem, pa onda "ko će pre", s tim da tu opet postoji problem oko toga kojim se načinom pristupa bazi/fajl sisitemu i koja "kašnjenja" on unosi u izveštaj...

Ona priča oko toga kojim se programom pristupa samom fajlu je skroz OK. Ali mi ni ona nije dovoljna... Ja sam mislio, najviše od ovih iskusnih koji su imali prilike da rade s tim (ako ima takvih), na to da li DB podržava nešto što FS ne može (i obratno, naravno).

Npr. ne znam kako se zove na sprskom onaj sisitem koji postoji kod savremenih DB-ova da se, pod određenim uslovima, jedna operacija ne izvrši ako se ne izvrše sve operacije iz zahtevanog skupa (bitno kod transfera novca gde se jednim upitom skidaju sredstva sa jednog računa, a drugim prebacuju deo na jedan, a trećim upitom na drugi računa, pa ako nestane struje tokom izvršenja prvog upita, onda nema para na prvom računu, a nisu prebačene na druga dva; da li sam dovoljno plastičan?). Ili slučaj referencijalnog integriteta gde se neki podatak iz tabele ne može izbrisati sve dok postoje zapisi koji referenciraju na njega (npr. ne možeš da izbrišeš stanje robe u magacinu, ako ta roba ima cenu u cenovniku). Ovi primeri mi sad padaju na pamet, a navodim ih jer sumnjam da bi oni mogli da se realizuju na FS-u (pre u middle layer-u, ali to je druga tema).

Potpis

possibly the biggest joker among his local crowd and perhaps a future book author on that subject

Transakcije! To je toliko normalno u bazama da se niko pre tebe nije ni setio da spomene :)

Potpis

"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

Verovatno ti ej nedoumic au tome dali korsititi fajl sistem ili sistembaze podataka. Relacioni model je izvodiv u obe varijante.

Ako je to pitanje, u stvari je svejedno. I SQL baz se u stvari svodi na fajl sistem. (skoro) Sve sto moze u jednom, moze i u drugom sistemu, samo je pitanje sta je za koju primenu zgodnije resenje.

Fajl sistem je generalno napusten zato sto je manje fleksibilan i manje univerzalan, a ne zato sto je manje funkcionalan. Za vecinu danasnjih potreba, server baze podataka je logicniji i prakticniji izbor. No, ako se zarad neke specificne potrebe, odlucis na fajl sistem, neces mnogo izgubiti na funkcionalnosti, imaces cak i relacioni model, i zakljucavanje na nivou sloga i transakcije... naravno, ne u Cobolu.

Osnovna prednost database servera je u univerzalnosti. Podaci ti postaju lako dostupni i primenljivi u raznim okruzenjima a to je nemerljiva prednost.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

U faj sistemu, tabele (podaci) nemaju nikakvu inteligenciju. Relacioni sistemi imaju inteligenciju na nivou tabela (podataka). U tome je kljucna razlika.
Sam si rekao:

Upravo si odgovorio na svoje pitanje. Relacioni sistemi podrzavaju transakcije i integritet podataka je deklarativne prirode a ne proceduralne.

Sta ovo znaci, deklarativno i proceduralno? Proceduralno je na nivou programskog koda, middle layer ili middle tier, ili sta bilo, uglavnom aplikacija vodi racuna o integritetu podataka. Deklaartivo znaci da je inteligenciaj na nivou podataka (tabele, baza). Kod relaqcionih sistema, jednostavno kazes pri definisanju tabela 'roba ne moze da bude u tabeli ULAz ako ne postoji u tabeli ROBA'. Gotova prica. Onda programeri ne moraju o tome da vode racuna, nego se fokusiraju na funkcije sistema, ono sto sistem treba zaista da radi. Ako malo razmislis, progarmirati integritet podataka ne doprinosi fukcionalnosti sistema. Toje samo preduslov da bi sistem uopste mogao da obavlja ono sta se od njega trazi. Integritet sistema je nezavisan od funkcija sistema. To ti je kao razlika izmedju motora u autu i volana. Jasno je da auto ne moze da ide bez motora. Ali stavi samo motor u auto, bez volana, takodje ne ide. Motor koji stavljas u auto mozes da stavis u brod ili u neku lokomotivu, ili cak da pokrece cekrk za zicaru ili pilanu. Motor ja dakle preduslov, nesto sto stvara rotacino kretanje. Rotaciono kretanje ce biti upotrebleno u neku svrhu (funkcija sistema) Volan je nesto sto ti omogucuje da upravljas autom, da ides gde hoces. Tako i u bazama podataka. Inegritet je nuzan preduslov. Aplikacija je volan. istu bazu mogu da koriste razne aplikacije. Dakle, aplikacija moze da bude i brod i pilana. A sve na istom motoru. Posto uspostavljanje i odrzavanje integriteta trazi mnogo programiranja, neko se setio da je na duzi rok jeftinije da progarmeri to ne moraju da rade, nego samo kazu 'artikl ne moze u magacin ako ne postoji na spisku artikala'. Ili kazes 'ne sme duplikat u tamo neko polje'. Ako aplikacija i propusti duplikat, baza ga nece prihvatiti => integritat podataka nije narusen.

Ima jedna situacija u Accesu kad se vidi prceduralni mentalite programera. Programira se unos necega gde se trazi jedinstven kljuc. 99% programera na formi za unos programira nesto kao "pre nego sto sacuvas rekord, proveri da li je vrednost za kljucno polje vec u tabeli, pa ako jeste, obustavi akciju cuvanja rekorda". Naravno, nema nista lose u proveri duplikata pre unosa. Da li bas? Ako u tabeli imas 2,000,000 rekorda ili 20 miliona, pa za svaki unos ides u tabelu i trazis nesto cega u 99% slucajeva nema, imas bespotrebnu komunikaciju izmedju aplikacije i baze. Kako god da je tabela lepo indeksirana, 2 miliona rekorda je dva miliona rekorda. Ispravno resenje: nemoj ni da proveravas da li je ponudjena vrednost duplikat. Ako jeste duplikat, sama baza ce da spreci unos i bez intervencije programera. Sta treba dakle programer da uradi? Nista. Da pokusa unos, pa kao se javi greska, da izvesti korisnika ili da mozda tek onda pronadje gde je duplikat i tako dalje. Ako u 99% slucajeva korisnik unosi ne-duplikat, nece se desiti nista, sve ide OK. U onom 1% baza ce se pobuniti i tek tada ce program morati da komunicira sa bazom, da trazi gde je duplikat i slicno. I kada je verovatnoca dupliakat velika, neka je 99%, ponovo komunikacija sa baziom je nepotreban, baza ce sama da odbaci unos i javice gresku. A sve zato sto je tabela sama po sebi 'inteligentna'. Ovo se ne desava u fajl sistemima. Aplikacija mora da brine ama bas o svemu.

U faj sistemu, tabele (podaci) nemaju nikakvu inteligenciju. Relacioni sistemi imaju inteligenciju na nivou tabela (podataka). U tome je kljucna razlika.

I jos jedna bitna prednost baza podataka: istovremeni rad više korisnika na podacima! Kod fajl sistema, pa čak i kod Cobola, kada neko upisuje nešto u fajl/tabelu onda je ona cela zaključana. To nije slučaj kod modernih SUBP, problem može nastati tek kada se pokuša istovremena izmena istog sloga (što je mnogo ređa situacija).

I još jedna: baze podataka mnogo brže rade u mrežnom okruženju, jer se selekcije rade na serveru i mrežom putuju samo potrebni podaci. A u Cobolu se moraju prevući svi podaci na klijent pa se tek tu izdvaja šta mi treba, što zna biti jako sporo sa velikim tabelama. Čak i Access baza tako radi. To nije problem u tvom slučaju, kada se aplikacije izvršavaju na serveru, a radne stanice su samo terminali, ali ako se aplikacije pokreću na radnim stanicama onda počinje show!

I još svašta... triggeri, procedure,....

Da, da... Transakcije. Pomislio sam da se tako zove, ali sam je odbacio nošen mišlju da se (koliko znam) ta reč kod nas češće koristi kod prenosa novca... Ili sam ja to "zadojen" rečnikom silnih finansijskih i računovodstvenih stručnjaka(?) oko sebe... O:)

Potpis

possibly the biggest joker among his local crowd and perhaps a future book author on that subject

Nis pogresio, transakcije u relacionim bazam i dolaze od potreba da se relacionim sistemima podrzavaju novcane transakcije. U relacionim sistemima podaci su razbijeni u nekoliko tabela. ceto to kroisniku ne izgleda logicno, ali na tome se zasniva cela prica. E sad zamisli klasicnu transakciju u knjigovodstvu, gde se jedan racun razdzuje i drugi se zaduzuje. Tu imas bar dva koraka -1) skini pare sa racuna A i 2) stavi te iste pare na racun B. Zamisli da racunar krene to da radi, i posle koraka 1) nestane struje. Meni skinute pare sa racuna, a nisu prebacene na racun elektrodistribucije. Pa em nemam pare em ce da mi odseku struju. Da se to ne bi desilo, cela prica se posmatra kao jedna transakcija u sistemu baze podataka. Ako su svi koracui prosli, tek se onda sve upise u bazu (COMMIT). Ako bilo sta nije proslo, cela transakcija se ponistava (ROLLBACK).

Naravno da se ovo moze postici i ne-relacionim sistemiam, sa manje ili vise programiranja, na nivou aplikacije. Cak i u relacionim sitemima moras da kazes gde pocinje transakcija i gde se zavrsava. Verovatno da je jednostavnije programirati transakcije u relacionim sitemima.

Imam utisak da niko nije dovoljno naglasio osnovnu stvar :
kod baza podataka postoji SERVER koji ume da radi standardne operacije sa velikom količinom podataka, i koji je optimizovan, dakle brz, i istestiran. I ti kad pišeš klijentsku aplikaciju koristiš njegovu ogromnu postojeću funkcionalnost (tako što mu pristupaš po SQL sintaksi) i tako oslobađaš sebe od razmišljanja o mnogim standardnim problemima (recimo, umesto da implementiraš izvršenje neke obrade unutar transakcije, samo kažeš serveru - ej, ovi upiti su unutar transakcije, ili umesto pretraživanja 3 tabela algoritmom sa 5 petlji, okineš SQL upit od 6 linija).
Znači, da, teorijski sve možeš sam, ako odeš dovoljno daleko, možda ćeš isprogramirati nešto što liči na RDBMS, ali čemu to ?
Sa aspekta čoveka koji pravi info sistem korišćenje gotovih RDBMSa je toliko zgodnije (sigurnije, jednostavnije, brže, kvalitetnije, a ne mora da bude skuplje), da i nema neke potrebe pričati o za i protiv.

Ako si iz nekog konkretnog razloga primoran da koristiš file system kao data storage, to je onda druga stvar. Inače, stvarno nema potrebe da razmišljaš o njemu, postoje mnogo korisnija, a takođe zanimljiva pitanja :).

Potpis

it works on my machine