Am gasit un curs bun pe partea de proceduri stocate in MySQL.
Am folosit in cateva situatii. Procedurile stocate sunt bune cat timp nu folosesti cursoare care sunt ingrozitor de lente 
In plus limbajul mi s-a parut destul de primitiv. De multe ori e mai simplu sa tragi datele in backend si sa le prelucrezi acolo.
3 Likes
Depinde am vazut ca procedurile stocate sunt foarte folosite in sisteme financiare, am mai vazut folosit si intr-o aplicatie dezvoltata in cadrul universitatii, eu personal am folosit pe vremea cand lucram in pentalog si facusem chestii destul de complicate cu proceduri stocate transact sql, sql server, si anume am migrat de pe o structura de baze de date pe alta datele pe acelas tip de server de baze de date sql server, aplicatia tinea evidenta la ingrediente pentru produse private label.
1 Like
Da,sunt folosite in sistemele financiare si nu numai. In principiu e ok sa arunci in partea de server prelucrarea masiva a datelor dar e foarte important sa vezi costul pentru ca sunt situatii (cel putin eu am avut) in care procedura se executa pe server mult mai lent decat echivalentul aceleiasi prelucrari a datelor in backend.
1 Like
Mda, nu sunt chiar un fan al sculelor Microsoft In plus m-am jucat la un moment dat cu tabele in-memory (in contextul unor proceduri stocate lente). Versus hard SSD nu era chiar asa mare diferenta numai ca riscul sa pierzi datele e mult mai mare…
Depinde Serviciul Local de Taxe si Impozite din Constanta foloseste SQL Server, am lucrat la firma care le face software, si datele cu toate bunurile si taxele celor din Constanta sunt stocate pe SQL Server, au un mic Data Center cu servere SQL Server in fiecare locatie, datele isi fac update intre locatii prin replicare, si desigur nu folosesc internet, folosesc o retea privata.
Nu aș folosi niciodată proceduri în MySQL/SQL server sau în baza de date fiindcă și așa baza de date este cea mai puțin scalabilă componentă din sistem. (cea mai scumpă de scalat cel puțin fiindcă ai nevoie ori de un cloud, ori de multe servere corect dimensionate pentru replicare, în cazul SQL server/Oracle și de licențe cu costuri astronomice)
Pentru lucruri simple nu are sens cu query builder-uri super faine în ziua de azi. Iar dacă ai proceduri în baza de date te-ai ars cu query builder-ul.
Ar trebui să droghezi un programator .NET să renunțe la LINQ fiindcă ție îți trebuie proceduri stocate. La fel și cu multe alte ORM-uri.
O mică excepție e dacă ai nevoie de date speciale, gen vectori, grafuri, coordinate gps și baza de date are deja o implementare excelentă pentru shortest path, distanță, percolare etc.
Adică select shortest_path(‘Cluj-Napoca’,‘Bucuresti’) from rute; ar fi ceva viabil, dar tot nu îmi place fiindcă ar utiliza resurse mai multe serverele cu baza de date. (primul motiv) Chiar dacă datele se procesează nativ, e mult mai ieftin un backend.
Algoritmul lui Djikstra în SQL :
http://www.artfulsoftware.com/infotree/qrytip.php?id=766
1 Like
2 Likes
Pentru Oracle
Sp sunt mandatory cand ai de facut prelucrari ACID in systeme financiare unde business logic este 99% in baza de date.
Limbajul la mysql/mariadb este “primitiv” versus pgsql sau tsql si chiar ciudat (handler) ce artificii a treb sa fac pt parcurgerea unui cursor nested in parcurgerea altui cursor … merge fast pana la urma dar ajungi sa faci “inutil” operatii/verificari in plus.
Corect, bazale de date SQL sunt mai greu scalabile pe orizontala fata de NOSQL insa ai marele avantaj ACID vs CRUD. Pana acum Postesql este f aproape de nosql acid prin introducerea campului cu tip de date JSON. Solutiile pt. implementarea scalabilitatii pe orizontala sunt replicarea master-master sau master-slave(s) (similara cu raid mirror unde operatiile dml si ddl le executi pe master si rapoartele pe slave-uri).
Nu in ultimul rand SP se refera si la triggere care oricat de blamate sunt ca viteza asigura systemului consistenta datelor si un eventual audit.
5 Likes
Ma alatur celor care recomanda scoaterea logicii din baza de date.
Am lucrat la mai multe sisteme in care a trebuit sa facem aceasta extractie din db in cod, pastrand fireste doar acele bucati care chiar trebuiau sa fie tranzactionale.
Problemele apar atunci cand se permite crearea sau mentinerea logicii in DB din motive de alocarea resurselor pe proiect (ex: “dba-ul e mai liber decat programatorii”), deadline-uri stranse (ex: “nu este timp sa testam unitar tot acest cod, iar procedurile stocate nu au nevoie de tdd => merge mai repede”), etc.
Nu intamplator arhitecturile de aplicatii au migrat de la monolit + acid la eventual consistency + microservicii. Trebuie (pt fiecare caz in parte) analizata solutia tehnica pentru a satisface intregile cerinte de business, iar uneori constrangerile sunt de asa natura incat sa se impuna anumite proceduri stocate. Dar ele trebuie sa fie exceptia, nu norma. La DevTalks am vorbit despre cum trebuie pus accentul pe continut si nu pe cod, pentru ca pana la urma noi scriem cod care sa serveasca acest continut spre utilizator. Daca se partitioneaza corect continutul, se pot obtine seturi de date mult mai mici care au nevoie sa fie tranzactionale, in rest putandu-se merge spre zona de distribuire si eventual consistency.
Total de acord ca anumite tipuri de business sunt inclinate sa foloseasca acid, dar haideti sa ne gandim ce inseamna pentru aplicatia noastra ca o tranzactie sa aiba 3-4-5 pasi toti inghesuiti in db si sa stam la coada pt a lucra cu acest db, versus un singur pas, cel de persistare, iar in rest sa facem polling sau sa folosim un alt mecanism prin care asteptam in afara bazei de date pentru un anumit status.
Sper ca m-am exprimat destul de clar, fiind pe fuga.
9 Likes
Event storming/sourcing all the way 
Alberto Brandolini - Transactions Redefined
1 Like
Ideal ar fi ca intreg business logic sa fie integrat in baza de date, deci aceasta sa se comporte ca un adevarat seif, cu intrari si iesiri controlate.
Dar de cele mai multe ori baza de date este folosita ca un simplu raft de pe care se iau sau se pun date, dupa bunul plac al softului conectat.
Desigur exista punctual si cauze obiective cum s-a spus, insa cred ca principala cauza este insusi SQL-ul, in sensul ca exista mai putini dezvoltatori buni in SQL decat in limbajele in care este dezvoltata aplicatia. In loc sa se caute solutii SQL compacte se prefera un fetch rapid ca sa se faca o prelucare bruta in limbajul aplicatiei. In acest context, ca SQL “ar fi greu” au aparut si solutiile indoielnice tip NoSQL care incep sa-si arate limitele.
1 Like
+1 pentru scosul logicii prea implicate din baza de date și pus în aplicație.
As adauga ca nu e neaparat nevoie ca procesarea sa fie facuta in totalitate de catre aplicatie, ci doar sub controlul ei, folosind query-uri mai mult sau mai putin complexe. De exemplu, sunt fan Dapper sau knex.js care sunt ORM-uri minimaliste. Sunt mai degraba tool-uri de construit query-uri si transformat obiecte usor, decat sisteme complexe precum ActiveRecord, SQLAlchemy sau ORM-ul din Django.
Nu prea mi-e clar de ce lumea zice ca e nevoie de proceduri stocate / triggere / lucrul in db pentru tranzactii cu operatiuni mai complexe, tho’. AFAIK tranzactii pot fi facute din aplicatia client. Si chiar tranzactii de lunga durata si complexitate mare - cateva zeci de minute si milioane de insert-uri.
Asta-i un lucru destul de dur de zis IMO, si as vrea sa te conving ca nu e adevarat. E mult hype pe partea de NoSQL ce-i drept, si unele produse populare care lasa de dorit intr-adevar[1], dar de’aici la a spune ca sisteme precum Redis, HBase sau BigTable sunt “indoielnice” e cale lunga. Sunt unelte specializate, pe care trebuie sa le folosesti la momentul potrivit si in scopul indicat. Daca te apuci sa folosesti Redis sa stochezi lista de clienti, o sa ai probleme “down-the-road”. Similar, pentru volume mari de date, nu vezi lumea sa foloseasca RDBMS-uri clasice[2]. Dar ca si produs ingineresc, sunt la acelasi nivel cu greii RDBMS-urilor. Iar cele care au rezistat si sunt cunoscute sunt bucati esentiale din infrastructura multor companii mari si mici.
OTOH, ai sisteme precum Spanner sau CosmosDB care adauga deajunse feature-uri ACID si relationale la un substrat NoSQL, cat sa fie candidati buni la a fi sursa de date centrala / adevar intr-un sistem informatic. Loc ocupat traditional de RDBMS-uri.
[1]Mongo :cough:
[2]Decat in setup-uri nebune, gen cel al celor de la Heap Analytics.
4 Likes
Ar mai fi încă un caz util pentru sp :
În cazul unei baze de date criptate gen cryptdb se poate lucra pe baza de date direct fără să fie necesară decriptarea cu proceduri stocate. Gen poți înmulți un câmp cu 10 sau incrementa fără decriptare.
Cu tranzacțiile nu sunt convins, se poate atiinge același lucru cu un api asincron și observabile (sau chiar promisiuni) între backend și db.
1 Like
De acord, posibil sa ai dreptate, te rog sa-mi spui cateva motive pentru a folosi NoSQL in afara de a evita cu orice pret SQL. Sau altfel spus cazuri in care s-a renuntat la un RDBMS pentru ca era mai buna o solutie de tip NoSQL. Thanks!
Atenție, subiectul se transformă în RDBMS vs NoSQL.
Eu sunt fan PostgreSQL, e și RDBMS și NoSQL. La MySQL, MyISAM și InnoDB îi știu toate bubele.
Dar sunt baze de date mult mai specializate gen Neo4j sau ArangoDB cu care nici un RDBMS nu poate concura.
Iar redis deja e în fiecare proiect unde trebuie scalabilitate și cache, no questions asked.
Sunt și baze de date care pot genera direct API-uri, care pot fi direct programate cu JS în loc de proceduri stocate.
2 Likes
cumva reget sa nu am fost la prezentarea ta, este undeva online?
… nu inteleg cum poti sa fi pro sau contra … pt. mine deciziile despre unde se proceseaza business logic sunt extrem de simple;
mentionezi 3-5 pasi “inghesuiti” in SP 
si “stai” dupa DB … dar oriunde le muti tot le “inghesui” si la fel “stai” sa termine daca ai nevoie de consistenta intr-un mediu concurential
hai sa luam un exemplu “clasic”:
- ai stoc comun magazinul online & fizic;
- comenzile online au 10 SKU in cos care ajung sa genereze in medie 15-20 de comenzi DML (insert&update);
- ai o medie de 3 case cu vanzare permanenta.
cum abodezi problema ca sa ai corect stocuri la raft, stocul blocat online si stocul rezervat online pt. o perioada de timp definita in care astepti sa faca plata clientul?
2 Likes
da este f. adevarat,
eu am in productie baza de date incriptate