tudor.t:

Ai dreptate, insa din pacate cum zicea si Andrei, realitatea in multe firme e diferita - am lucrat in trei firme de soft pana acuma si in nici un caz nu exista cineva cu job-ul de db. admin sau db. developer (dedicat), chiar daca uneori e vorba de firme mari, de peste 100 de programatori - normal, existau persoane cu mai multa experienta in domeniul asta care pot da o mana de ajutor cand e nevoie, dar cam atat..

Cauzele nu sunt doar "financiare", ci si de alta natura - in multe firme de dezvoltare software se lucreaza de-a lungul timpului pe o multime de proiecte, in care server-ul de baze de date nu e intotdeauna acelasi, ci e ales de client si variaza de la un proiect la altul (SQL Server, Oracle, MySQL etc.); multe proiecte sunt de dimensiuni mici/medii iar dupa terminarea aplicatiei si predarea la client se intampla ca unii clienti sa nu mai considere necesar sa plateasca pentru servicii de mentenanta unde un db. admin s-ar dovedi util in optimizarea/intretinerea bazei de date - chiar daca parte ade data storage/retrieval nu a fost gandita optim, programatorii care au implementat-o nu ajung sa o vada ruland pe un volum semnificativ de date in productie, care deseori se acumuleaza doar dupa mai multi ani - asa ca eventualele probleme de performanta nu sunt vizibile imediat...

Alta cauza e si folosirea de O/RM-uri in multe proiecte .NET, a.i. pentru multe aplicatii de complexitate mica/medie, si care nu sunt asa "data intensive", si in care baza de date e folosita exclusiv de acea singura aplicatie, programatorul trebuie sa stie doar sa creeze structura bazei de date, fara sa mai aiba nevoie de stored procedures, functii, triggers, permissions etc - normal ca la un moment dat s-ar putea sa se loveasca de niste limite ale O/RM-ului, dar cand se intampla asta deseori proiectul e spre final si managementul nu va considera necesara angajarea unui database developer doar pentru cateva saptamani..

Faptul ca ai in echipa un db developer nu se vede in procedurile stocate sau in functii si nici in sintaxa de sql folosita ci in primul rand in diagrama bazei de date care nu tine cont de serverul folosit. Cati programatori de .NET ai intalnit care sa stie ca pe langa tabelele de date si cele de legatura mai exista si tabele de validare? Dupa cum ai zis sunt ORM-uri deci problema de servere diferite se rezolva relativ usor. daca un developer .NET pune intr-un tabel campul "tefeon2" sau "adresa2" o face pt ca s-a gandit ca sunt 2 telefoane sau 2 adrese insa un db developer bun nu cred ca va lua o astfel de decizie la fel de usor.
sunt curios cate din firmele respective se pot lauda cu produse care au acaparat si pastrat un procentaj decent dintr-o piata competitiva mai mult de 5 ani?
eu mi-am deschis un cont de card la BCR acum vreo 9 ani care, din cate stiu eu l-am inchis dupa vreo 5 ani dar am mers zilele trecute sa verific ca sa fiu sigur (sa nu am surprize cu vre-o factura aberanta adunata doar din penalizari) si nu au fost in stare sa ma gaseasca in baza de date.. nici macar vreo urma a contului nu au reusit sa gaseasca.. si i-am intrebat d c nu cauta dupa CNP si au spus ca ei la vremea respectiva nu stocau aceasta informatie
la romtelecom am avut probleme vreo 6 luni de zile cu facturile tot din cauza problemelor din baza de date..
deci sunt deja 2 exemple de companii nu tocmai mici care nu au fost in stare sa isi cumpere o baza de date facuta cum trebuie.

faptul ca pe o baza de date lucreaza o singura aplicatie nu este o scuza sa nu o faca bine; exista sanse considerabile sa mai existe aplicatii similare si, inevitabil, in timp vor exista migrari ale clientilor de pe o baza pe alta iar daca baza ta e mai bine pusa la punct si are mai multe feature-uri incorporate migrarile vor fi in directia ta. Nu poti opri un consumator sa treaca de pe o baza pe alta dar poti sa il convingi sa treaca pe a ta. plus de asta tendinta generala a bazelor de date este una de convergenta nu de izolare..

faptul ca "asta e situatia" nu inseamna ca trebuie sa o incurajam.. asta e tot ce zic.