salutare, me again;

intrebare legata de best practices:

cand vine vorba de scris CRUD-ul pt un tabel imi place sa scriu o singura procedura care sa contina toate operatiile si adaug un parametru care selecteaza operatia ce va fi executata din cele existente, si unul care sa returneze informatii suplimentare despre felul cum a decurs operatia.

totusi, vad ca in general lumea scrie cate o procedura separata pt fiecare operatie (chestie care mie imi displace)

intrebari: merita sa renunt la stilul meu si sa incep a scriu o multime de proceduri? (de ce?) ce dezavantaje gasiti la modul in care scriu CRUD-ul?

thx.

PS pt administratorii site-ului: cred ca ar fi binevenita o sectiune "Best Practices" in care sa punem discutiile ce analizeaza probleme de acest gen (moduri diferite de a rezolva o problema cu avantajele si dezavantajele fiecaruia)

Salut,
Parerea mea este ca o singura procedura stocata este mai greu de manage-uit atat petnru tine (daca tu ai experienta in scrierea de astfel de proceduri), poate pentru cei care au preluat sau vor prelua codul SP scris de tine cat si pentru SQL. Daca procedura ar fi impartita in 4 procdeduri pentru fiecare operatie in parte, SQL ( vb de 2005) ar putea sa iti faca planul de executie mai optim si mai scurt ceea ce ar duce la o performanta mai buna.
Oricum si eu sunt deacord cu PS- ul tau :) Ar fi interesanta o sectiune de Best Practices ;)


Daniel.

---

MCP (C Sharp)
Software Engineer,
Cluj Napoca

O sa scriu un exemplu concret iar apoi ar fi fain sa luam cateva exemple de probleme care pot sa apara si sa vedem cum se trateaza in fiecare din cele doua abordari. si la sfarsit tragem concluziile

ideea este ca eu am inceput sa lucrez cu procedurile stocate si SQL acum vreo 3 ani si nu am avut ca documentatie decat o carte publicata prin 2002 (nici nu pot spune ca am stat sa caut) asa ca mi-am format acest stil de a le scrie - care a functionat destul de bine (nu am avut probleme dar nici proiecte foarte complexe nu au fost); intre timp am aflat de business objects, CodeSmith, recomandarile celor de Microsoft, etc... asa ca ma gandeam ca ar fi un moment bun sa-mi revizuiesc obiceiurile si sa vad ce pastrez si ce schimb )

Cum gestionezi drepturile?
Adica anumiti useri -au drepturi de insert,
alti au dreptul de update si poate alti au drepturi numai de delete

step:

Cum gestionezi drepturile? Adica anumiti useri -au drepturi de insert, alti au dreptul de update si poate alti au drepturi numai de delete

sincer sa fiu inca nu m-am lovit de problema asta (dar urmeaza ), insa daca vad un exemplu (sau macar niste guide line-uri) despre cum rezolva prin cealalta metoda o sa gasesc o solutie similara si prin metoda mea.

la o prima vedere ma gandesc sa implementez in baza de date un sistem mai flexibil (si implicit mai complex) in care sa tin intr-un tabel drepturile care le are fiecare categorie de useri iar in tabelul de useri un camp care sa spuna in ce categorie apartine userul; totodata la fiecare procedura se introduce un parametru suplimentar @user_name si inainte de orice altceva se verifica daca userul respectiv are voie sa faca operatia continuta in parametrul @operatie

in felul acesta clientul poate sa mute foarte usor userii dintr-o categoria in alta (se poate merge chiar si mai departe si cu ceva cod suplimentar si cateva tabele sa ii oferim tool-uri care sa ii permita sa isi defineasca el categorii noi)

acum ramane de vazut cand e mai bine sa se faca verificarea: in procedura sau separat, inante de apelul ei

Gherry:

salutare, me again;



cand vine vorba de scris CRUD-ul pt un tabel imi place sa scriu o singura procedura care sa contina toate operatiile si adaug un parametru care selecteaza operatia ce va fi executata din cele existente, si unul care sa returneze informatii suplimentare despre felul cum a decurs operatia.

totusi, vad ca in general lumea scrie cate o procedura separata pt fiecare operatie (chestie care mie imi displace)

Ca motiv pot sa iti spun despre
    1.usurinta de a mentine codul  - e mai usor sa fie sparte
    2. usurinta de a lucra -e mai usor ca 4 programatori sa lucreze la 4 proceduri decit 4 la aceeasi SP
    3. Daca ai o conventie de notare - e usor de identificat
    4. Pentru Delete nu trebuie sa treci toate cimpurile, ci doar ID-ul ( ma rog, last wins ....)

Pe de alta parte, parerea mea ar fi una care nu se aliniaza la Best Practices, ci e un pic pe linga : pentru tabele cu multe cimpuri, faci o PS de insert cu cimpurile principale( de pilda, pentru un user cu NumeDeLogare + Parola), o  PS de delete cu ID -  iar pentru update folosesti direct cod ....

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

eu am niste ps care au implementat si insertul si update ul , dar numai unde userii au aceleasi drepturi si pt inssert si pt update

de ex
CREATE Procedure dbo.sab_sp_AddBC_FV

(@ID int out,
@bciBC int = Null,
@bciNr int = Null,
@sarja int =null)
AS

SET NOCOUNT ON
if @id is null
begin
Insert into tblBCIntermediar(bciBC,bciNr,bcdsarja)
VALUES (@bciBC,@bciNr,@sarja)
If @@error<>0 return
select @id=scope_identity()
return
end

Update tblBCIntermediar
Set
bciBC = Case When @bciBC is null then bciBC else @bciBC end,
bciNr = Case When @bciNr is null then bciNr else @bciNr end
Where bciID = @id


dar numai atunci cand cei care fac insert ,pot sa faca si update.

pe partea de delete- folosesc de fapt -anulare - adica un camp pe care il marchez -
si aici intotdeauna este o procedura separata

Gherry:

la o prima vedere ma gandesc sa implementez in baza de date un sistem mai flexibil (si implicit mai complex) in care sa tin intr-un tabel drepturile care le are fiecare categorie de useri iar in tabelul de useri un camp care sa spuna in ce categorie apartine userul; totodata la fiecare procedura se introduce un parametru suplimentar @user_name si inainte de orice altceva se verifica daca userul respectiv are voie sa faca operatia continuta in parametrul @operatie

Deci tu chiar te gindesti serios sa rescrii intregul modul de securitate SQL Server doar pentru a-tzi apara stilul de scriere a procedurilor?
Cum ai adresa probelemele triviale de securitate de genul @user este membru al unui grup Windows care are drept la operatie? Sau si mai fain, cind @user are explicit drept la operatie dar este membru al unui grup care are denied dreptul la operatie? Sau derivarea drepturilor implicite din alte drepturi explicite? Obiectia lui Step este extrem de valida si as vedea in ea un argument extrem de important impotriva stilului care incerci sa-l aperi.

Singurul argument favorabil care as putea sa-l gasesc la stilul tau este refolosirea acelui 80% din codul oricarei proceduri care se ocupa de detalii minore de genul erori (blocuri TRY/CATCH sau validare @@error etc), validari de parametrii etc. Ori aceasta poate fi adresata mult mai elegant prin generarea procedurilor pe baza unor template-uri care sa genereze separat cele 3 proceduri.

---

http://rusanu.com

Uite un tool misto care genereaza proceduri CRUD separate petnru fiecare operatie.

http://www.ssmstoolspack.com/

 

Daniel.

---

MCP (C Sharp)
Software Engineer,
Cluj Napoca

aflorin27:

De cealalta parte a baricadei sunt cei care nu folosesc deloc proceduri stocate. Eu as fi pentru asa ceva.

Si se pare ca nu sunt chiar singurul: http://www.developertutorials.com/tutorials/mysql/stored-procedures-are-evil-060906/page1.html

Eu am invatat sa le pretuiesc in momentul in care aveam o aplicatie care era "distribuita" pe > 200 de PC -uri ... la care nu aveam conexiune tot timpul, dar se conectau la ~ 50 SQL Server-e .
Era rapid si usor de schimbat procedurile stocate - dar ingrozitor de mentinut/updatat  aplicatia ( ma rog, VB6 - prietenii stiu de ce...)

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

ignatandrei:

aflorin27:

De cealalta parte a baricadei sunt cei care nu folosesc deloc proceduri stocate. Eu as fi pentru asa ceva.

Si se pare ca nu sunt chiar singurul: http://www.developertutorials.com/tutorials/mysql/stored-procedures-are-evil-060906/page1.html

... ma rog, VB6 - prietenii stiu de ce ...

Unul din prietenii VB6 nu stie de ce ! Poate detaliezi !

ignatandrei:

...
Eu am invatat sa le pretuiesc in momentul in care aveam o aplicatie care era "distribuita" pe > 200 de PC -uri ... la care nu aveam conexiune tot timpul, dar se conectau la ~ 50 SQL Server-e ...

Sa inteleg ca stilul acesta de - virgula - dezvoltare (proceduri stocazte pentru CRUD) nu este disponibil si in VB6 ?
Sa inteleg ca VB6 te opreste pe tine - ca programator - sa dezvolti un "smart client" ?

rremus:

Deci tu chiar te gindesti serios sa rescrii intregul modul de securitate SQL Server doar pentru a-tzi apara stilul de scriere a procedurilor?
Cum ai adresa probelemele triviale de securitate de genul @user este membru al unui grup Windows care are drept la operatie? Sau si mai fain, cind @user are explicit drept la operatie dar este membru al unui grup care are denied dreptul la operatie? Sau derivarea drepturilor implicite din alte drepturi explicite?

Eu eram ferm convins ca vorbim despre situatii care nu sunt acoperite de userii de windows de ex: intr-un magazin pot sa fie in acelasi timp mai multi agenti de vanzari care iregistreaza operatiile pe acelasi calculator caz in care ar fi aberant sa creem conturi de win pt fiecare si sa ii punem sa dea switch user de fiecare data.. nu toti clientii au chef sa faca conturi de win pt fiecare user. sau daca avem o aplicatie care lucreaza pe web sunt curios cum rezolvi problema folosind exclusiv modul de securitate SQL Server.. eu zic ca sunt o multime de exemple in care nu se poate rezolva problema asa cum sugerezi tu.

aflorin27:

De cealalta parte a baricadei sunt cei care nu folosesc deloc proceduri stocate. Eu as fi pentru asa ceva.

mie mi-au placut foarte mult procedurile stocate pt ca nu prea am incredere in cei care folosesc baza si ma ajuta sa o protejez mai bine.. personal nu am gasit inca nici o baza care sa fi lucrat in continuu 5 ani de zile si sa aibe datele asa cum trebuie, dimpotriva: totdeauna trebuia sa stau sa repar bazele inainte sa lucrez cu ele.

dar asta era acum 3 ani cand nu stiam inca de DAL si BLL

personal nu mi se pare ok sa scriu cod SQL in clase, deci ala incerc pe cat posibil sa il inlocuiesc cu proceduri.. (acum nu stiu cat e de bine sau de rau insa pare mai natural asa)

cretzu:

Uite un tool misto care genereaza proceduri CRUD separate petnru fiecare operatie.

http://www.ssmstoolspack.com/

 
Daniel.

Momentan testez CodeSmith-ul pt asa ceva dar o sa arunc o privire si pe ala, thx