liviu.costea:

Trebuie sa stie sa faca proceduri stocate, functii, viewuri. Asta ar fi necesar pentru toti programatorii.

Apoi ar fi bine ca sa stie sa si optimizeze o procedura stocata, sa citeasca un plan de executie, sa stie cand sa adauge un index si de ce, cand si cum sa foloseasca o tabela temporara. Cei care se cred de nivel intermediar/avansat ar trebui sa stie astea.

Iar in ultima parte sa fie la punct cu noutatile aduse de orice versiune noua de server sql, de exemplu in sql server 2005 poti faci join cu o functie tvf, in 2008 s-a introdus table value parameters etc.

De fapt eu as vrea ca .net developerul sa fie si database developer daca se poate (dar nu dba).

ce distractie va fi pe capul celor care raman in firma atunci cand un astfel de om pleaca in alta parte..

capcana in care cad foarte des oamenii care stiu si una si alta consta in faptul ca nu mai respecta intocmai arhitectura si fac uneori compromisuri scriind anumite bucati de cod in parti unde nu ar trebui sa fie asa ceva.. sa vezi ce bestial va fi cand trebuie sa adaugi functionalitati noi unui astfel de proiect.. goodluck with that..

plus de asta Diana a punctat foarte bine aspectul legat de acel "frame of mind" care ar trebui sa fie diferit la un database developer fata de unul .NET (DAL si BLL constituie un punct de inflexiune in felul cum se aboredeaza in mod optim majoritatea problemelor de cele 2 parti ale acestor layere)

Gherry:

ce distractie va fi pe capul celor care raman in firma atunci cand un astfel de om pleaca in alta parte..

Asta e problema tuturor firmelor ... si depinde f. mult de oferta de pe piata ...

Gherry:

capcana in care cad foarte des oamenii care stiu si una si alta consta in faptul ca nu mai respecta intocmai arhitectura si fac uneori compromisuri scriind anumite bucati de cod in parti unde nu ar trebui sa fie asa ceva.. sa vezi ce bestial va fi cand trebuie sa adaugi functionalitati noi unui astfel de proiect.. goodluck with that..

Compromisuri exista oriunde ... si asta vine inerent din schimbarea conditiilor de Business ...

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

ignatandrei:

Asta e problema tuturor firmelor ... si depinde f. mult de oferta de pe piata ...

Compromisuri exista oriunde ... si asta vine inerent din schimbarea conditiilor de Business ...

Si asta-i drept

La scoala, nu si in viata...

Deja cred ca nu mai putem vorbi de programatori de .NET in general. Si .NET si SQL devin din ce in ce mai vaste si mai complexe. Astfel incat pentru proiecte mai mari e nevoie de echipa...Ia vezi in MSDN, cate clase sunt numai pentru SMO - si cum calitatea documentatiei este in "(s)cadere libera"....

Asta poate in teorie sau in firmele ce-s ipermit sa plateasca oameni separat pt sql dot net de exemplu.

Vorbesc din propprie experienta aici la firmele din Romania majoritatea trebuie sa stii cel putin c#,sql si dhtml-> asta insemnad js,html css

si ceva despre xml xpath,xquery de astea

---

Secolul XXI ori va fi religios ori nu va fi deloc

crestinul:

Asta poate in teorie sau in firmele ce-s ipermit sa plateasca oameni separat pt sql dot net de exemplu.

Vorbesc din propprie experienta aici la firmele din Romania majoritatea trebuie sa stii cel putin c#,sql si dhtml-> asta insemnad js,html css

si ceva despre xml xpath,xquery de astea

stim cu totii ca angajatorul roman ar vrea sa angajeze un singur om care sa ii rezolve toate aspectele la toate proiectele si sa le faca si repede si sa fie si competitive.. genul de firme care subcontracteaza de la altii si la randul lor angajeaza oameni care sa le faca treaba si isi fac banii prin reduceri de costuri si angajare de forta de munca mai ieftina (si implicit mai prost pregatita) in loc sa vina cu o idee inovatoare, creativa sau cu un proiect propriu, in opinia mea nu prea au ce cauta pe piata..
cat despre uberprogramatorul care le stie pe toate si e la zi cu toate tehnologiile astea sa fie el sanatos, eu unul vreau sa imi fac treaba bine dar in acelasi timp vreau sa mai fac si altceva in viata in afara de servici..

Gherry:

stim cu totii ca angajatorul roman ar vrea sa angajeze un singur om care sa ii rezolve toate aspectele la toate proiectele si sa le faca si repede si sa fie si competitive.. genul de firme care subcontracteaza de la altii si la randul lor angajeaza oameni care sa le faca treaba si isi fac banii prin reduceri de costuri si angajare de forta de munca mai ieftina (si implicit mai prost pregatita) in loc sa vina cu o idee inovatoare, creativa sau cu un proiect propriu, in opinia mea nu prea au ce cauta pe piata..

Atita timp cit programatorul roman este mai ieftin decit unul american/european de vest, optiunea outsourcing este viabila...
Ma rog, nu e aducatoare de profit ca in anii 2000-x ...

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

ignatandrei:

Atita timp cit programatorul roman este mai ieftin decit unul american/european de vest, optiunea outsourcing este viabila...
Ma rog, nu e aducatoare de profit ca in anii 2000-x ...

e viabila dar nu e nici creativa si nici productiva (cel putin nu pe termen lung).. in loc sa invatam sa gandim si sa intelegem piata si consumatorii si sa intuim cererea ca apoi sa ii raspundem aducand solutii complexe si inovatoare (chestii care intr-adevar aduc bani si recunoastere dar imiplica si un oarecare risc si responsabilitate) noi invatam sa multumim cat mai bine pe cei care stiu sa faca asta si le implementam ideile lor.. nu vreau sa supar pe nimeni dar ma tem ca vom ajunge si noi la sloganul "noi muncim nu gandim"..
Outsourcing-ul a fost mana cereasca la inceput dar dupa cum ai spus si tu profiturile au inceput sa scada si vor continua sa faca asta insa nu mi se pare o solutie foarte buna sa raspundem situatiei incercand sa invatam cate putin din fiecare astfel incat acelasi om sa poata acoperi un numar mai variat si mai mare de proiecte.. se va pierde calitatea iar atunci implicit se vor pierde si contractele de outsourcing. vom inceta sa fim competitivi..

anyway, mii de scuze pt offtopic-ul masiv care l-am facut aici (doar 2 comentarii din 7 le-am scris la subiect.. ), ggciubuc sper ca nu o sa ma injuri prea tare

Gherry:

in loc sa invatam sa gandim si sa intelegem piata si consumatorii si sa intuim cererea ca apoi sa ii raspundem aducand solutii complexe si inovatoare (chestii care intr-adevar aduc bani si recunoastere dar imiplica si un oarecare risc si responsabilitate) noi invatam sa multumim cat mai bine pe cei care stiu sa faca asta si le implementam ideile lor.. nu vreau sa supar pe nimeni dar ma tem ca vom ajunge si noi la sloganul "noi muncim nu gandim"..

Mda... dar eu de abia mai tin pasul cu noile tehnologii ...d-apoi sa fac ce zici tu. Si, pe urma, cred ca asta e treaba businessului ... iar cel mai usor a fost de implementat ceea ce a fost facut afara ( vezi trilulilu, colegi.ro, etc. ) in speranta ca vor fi cumparati ...
Dar , intr-adevar, scuze de offtopic...

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

Diana:

... si cum calitatea documentatiei este in "(s)cadere libera"....

OT: O sa fur aceasta expresie e super.

Si ce ar trebui sa stie o sa vorbesc de ce ar trebui sa stie la noi in shop , care desi MS orinetati nu sintem lock pe SQL Server adica ce facem noi trebuie sa mearga din cutie pe SQL Server, Oracle, DB2, Postgre si lista e deschisa . 
SQL standard (TSQL si alte dialecte daca le stie aduce la numitor comun super dar citi stiu) si concepte DB, view, table etc. Nu creere stored procedures (sau functions), neinteresant mai ales daca trebuie sa stii 4-5 limbaje pentru ele (daca stii toate super dar citi stiu acuma). ADO/ODBC ar fi bine, ADO.Net super. Nu LINQ si Entity, nu isi merita banii ca nu fac fatza. Administrare de baza de baze , adica conexiune backup restore, etc. Engleza si sa fie capabil sa inteleaga un help nu numai sa il citeasca. C# si dezvolatare profesionista adica unit testing, code  analysys etc.

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

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.

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

Gherry:

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.

1. hai sa nu acuzam doar programatorii de .NET , ci programatorii in general. In definitiv , cei de VB6 ce au ?
2. Tabele de validare - mda... Daca e ceea ce ma gindesc eu, sunt tabele care valideaza , de ex., ca o adresa de email e valida. Decizia de a tine in BD sau in aplicatie care sa fie updatata depinde de o decizie si de conditiile aferente
3. Asta cu Adresa 2 si telefon2 este OK ... in anumite imprejurari . Dar nu cred ca se refera la punctul 2

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

ignatandrei:

1. hai sa nu acuzam doar programatorii de .NET , ci programatorii in general. In definitiv , cei de VB6 ce au ?

lol

ignatandrei:

2. Tabele de validare - mda... Daca e ceea ce ma gindesc eu, sunt tabele care valideaza , de ex., ca o adresa de email e valida. Decizia de a tine in BD sau in aplicatie care sa fie updatata depinde de o decizie si de conditiile aferente

tabele de validare sunt acele tabele care se folosesc in cazul unor campuri cu un numar relativ mic si finit de valori care inevitabil se vor repeta de multe ori, pt a evita typo-urile. ex: prefixul de nume, judetele unei tari, etc. unii programatori pun asta in lista unui combo sau intr-o enumerare cand ar putea sa o tina intr-un tabel fapt ce odata implementat da mai multa flexibilitate (pt ca introducerea unei inregistrari intr-un tabel e mai simpla decat modificarea unei enumerari) - bine, mai nou se foloseste xml-ul pt asa ceva dar tot mai viabila mi se pare solutia cu tabelul..

ignatandrei:

3. Asta cu Adresa 2 si telefon2 este OK ... in anumite imprejurari . Dar nu cred ca se refera la punctul 2

intr-adevar nu se refera la punctul 2.