Gherry:

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.

Inseamna ca acel programator de .NET nu are destula experienta (ca sa ma exprim mai "elegant") - un programator bun mai intai isi va gandi un domain model, si doar dupa aceea va gandi un data model pentru a persista acel model - incepand cu acel punct daca are nu are suficienta experienta si are norocul sa aiba un database programmer prin preajma va colabora cu acesta pentru a ajunge la o structura a bazei de date normalizata (sau mai putin normalizata) care sa satisfaca cat mai bine cerintele aplicatiei, inclusiv sa fie extensibila, flexibila etc. ... (normal, daca nu are de-a face cu o baza de date legacy pe care nu o poate modifica..)

Gherry:

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?

Probabil putine - insa realitatea (trista) e ca multe proiecte sunt punctuale/custom pentru firme mici, dureaza cateva luni si gata - cum se descurca clientul cu aplicatia dupa aia deseori programatorul nu mai afla..

Gherry:

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

Multi clienti nu stiu ce e aia o baza de date - deseori ei doar constata ca o anumita aplicatie nu le mai satisface cerintele (prea lenta, prea multe bug-uri, prea greu de intretinut etc.), si atunci decid sa angajeze o firma pentru a le produce o noua aplicatie, deseori de la zero, eventual cu migrarea datelor existente..

Gherry:

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

Asta asa e - insa deseori problema e a managerilor, care nu inteleg rolul unui database dev./admin intr-o firma de software/outsourcing..

Normal, o parte din problema e si la programatori, care desori percept un database server doar ca un storage, o galeata in care persista datele pana cand user-ul va avea nevoie din nou de ele, pe cand un database developer percepe un database server ca o platforma de dezvoltare mult mai complexa, care poate ingloba o parte din business logic, validare, securitate etc..