Gherry:

cine se zgarceste la tarate pierde la faina din punctul meu de vedere la o firma care are deja 2 dezvoltatori .NET si majoritatea aplicatiilor dezvoltate folosesc bd atunci ar fi aberant ca al treilea programator angajat sa fie tot pe .NET (eu zic ca atata timp cat lucrezi cu BD al doilea programator angajat ar tb sa fie database developer si apoi se pot angaja pe partea de .NET in functie de resurse)

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..