> Poate ne spui si noua pe ce te bazezi in aceste afirmatii si care ar fi
> urmatorele clasate indiferent de cat de departe sunt. Nu de alta, dar sa
> stim, daca va fi cazul, ce sa alegem si de ce sa ne ferim.
> Parerea mea, subiectiva, fara alte informatii decat cele din acest
> thread, este ca un program care foloseste un file server pt a accesa si
> partaja fisiere, fara a folosi un motor de baze de date performant, nu
> poate fi o optiune viabila decat pt volume mici de date, indiferent cat
> de complet ar fi programul. Despre securitate cred ca nici n-are rost sa
> mai vorbim.
>
Acum 10 ani lucram in RENEL (FRE Ploiesti). In toamna lui 94 a fost
dat in exploatare sistemul de autocitire cu care sunteti cred destul
de obisnuiti: vine omul la ghiseu, declara indexul, i se face factura
pe loc si o plateste. Nu vine i se face ulterior o factura din oficiu.
Periodic (odata la cateva luni) trec cititorii si si noteaza indexul
real al abonatului.
La vremea respectiva Ploiestiul avea cam 90000 de abonati si pentru
fiecare aveam in baza de date informatii din ultimii 3 ani (indecsi,
facturi, schimbari de adresa..etc.).
Faceti voi socoteala sa vedeti cam ce dimensiuni avea baza de date..
Tehnologia? Servere cu SO Novell Netware 3.10, 486 @ 50 MHz, 16 MB
memorie..facut ulterior un upgrade la 32. statii de lucru 386 la 25
sau 33 MHz, cu 4 sau 8 MB RAM. Retea Ethernet pe cablu coaxial.
Aplicatie dezvoltata in Foxpro de DOS (2.5 parca, ulterior cred ca pe
2.6). Tehnologia folosita bineinteles "file-sharing", cu tot ceea ce
presupune ea (locking si alte fineturi). Si tineti cont de faptul ca
se lucra cu vreo 10 case simultan, iar emiterea unei facturi inseamna
sa cauti istoricul acelui om din baza de date (adica toate citirile si
facturile din trecut), sa verifici cu un algoritm destul de complex
daca se incadreaza consumul lui declarat intr-un model de consum ce
tinea cont de perioada anului , sa emiti factura si sa o incasezi.
Totul in 1-2 minute pe abonat.
Acum scuzati vorba lunga, dar toamna asta am fost invitat la un
parastas. Destul de cu staif, si a fost facut la un club in Ploiesti.
Cu comanda de colaci facuti la patiserie, cu batistute si tot ce
trebuie. Cei de la patiserie nu prea pricepeau ei de ce sa faca acel
colac cu aluat de cozonac, stafide, si sa scrie pe el ca pe un tort.
Parastasul asta a fost un chef monstru - cred ca v-ati prins ca e
vorba de parastasul acelui program care a fost scos la pensie in
toamna acestui an, dupa 11 ani de exploatare (si adaptari pe
parcurs...). si care a functionat impecabil cu toata tehnologia
"file-sharing" veche de 15 ani. Pentru ca acel produs a fost
"proiectat" si "executat" de o echipa interdisciplinara (analisti,
programatori, eu eram la vremea respectiva administratorul lor de
retea). S-a facut tunning la accesul la baza de date. In 1995, la un
an dupa ce programul a fost dat in exploatare (si dupa ce se
realizasera economii de peste un miliard de lei in decurs de un an!!!)
ne-am pus problema sa realizam o varianta pentru Windows si cu baze de
date SQL. Am facut teste cu Oracle (cred ca sunt singurul de aici ce
ma pot mindri ca am instalat Oracle 7, si inca ala de Netware) si SQL
Server ce tocmai aparuse pe piata. Si concluzia noastra a fost ca nu
se merita sa facem trecerea la acea tehnologie. Nu exista un spor de
viteza din testele noastre (query-uri facute in Foxpro si in Oracle pe
baze de date cu miliaone de inregistrari), iar pentru aplicatia
windows era nevoie de schimbat tot: servere mult mai puternice,
schimbat toate statiile, rescris toata aplicatia (pe alta platforma de
dezvoltare). Totul in ideea de a generaliza aplicatia din Ploiesti pe
judetul Prahova. Asa ca in 96 (in ianuarie 96 devenisem sef de
serviciu) ne-am limitat la a crea infrastructura necesara (statii si
servere bune, chair daca erau Sprint - discuri SCSI, unitati
magneto-optice de 3.5" 650 MB, RAID 5 pe servere cu controlere DPT,
imprimante matriciale de mare viteza - costa 10 milioane o imprimanta
atunci, dar mai sunt in exploatare si azi - trecerea de la o retea pe
coaxial de 15 useri din Oficiul de calcul la o retea twisted pair in
toate sediile RENEL, licente Windows , Visual Studio, Backoffice -
cred ca am fost printre primii din Romania cu licenta Backoffice OLP
pentru 100 de useri). Proiectul software a fost demarat in 97 dar din
pacate nu a mai fost finalizat pina la plecarea mea din RENEL in 98.
In paranteza fie spus, unul din motivele pentru care am plecat e ca nu
am gasit intelegerea necesara sa fie alocat un prapadit de miliard
(din cele 37 de miliarde alocate pentru o retea de "radio-trunking")
pentru realizarea unei retele wireless in 2.4 GHz la nivelul judetului
Prahova, care ar fi legat cele 11 centre de distributie RENEL si cele
cateva zeci de statii de inalta tensiune. Mircea Ciocan cred ca are si
el ceva amintiri din perioada respectiva (firma lui ar fi trebuit sa
realizeze reteaua). Din pacate proiectul a murit in stadiul de vis,
iar de tragere fibra pe stalpii RENEL a fost vorba mult mai tarziu.
Acum ca tot v-am retinut atentia asa de mult as vrea sa trag si o
concluzie. Nu va hazardati sa emiteti judecati de valoare numai pe
chestii din astea folclorice ("se stie ca file-sharing suxx si SQL is
the way"). Aveti mai sus un exemplu de aplicatie care a functionat
bine pe volume mari de date in "file-sharing", si cred ca putem gasi
impreuna niste contra-exemple in care o baza de date relationala prost
proiectata (structura neoptimizata, indecsi inexistenti sau prost
definiti/utilizati) si niste query-uri ciudate pot ingenunchia aproape
orice baza de date SQL. De aia in sectorul IT meseria de DBA este
destul de banoasa (un bun DBA poate creste viteza de raspuns al
aplicatiei si scadea timpii de executare a cererilor, ceea ce pentru
majoritatea businessurilor asta inseamna BANI).
Din pacate la partea cu securitate nu prea am contra-argumente,
trebuie sa te bazezi pe mecanismele oferite de sistemul de operare.
Ender
_______________________________________________
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
