salut
avem un soft .NET winform si am vrea sa adaugam si posibilitatea de a lucra si cu un alt sgbd,avem de ales intre Postgres si MySql.multumesc pentru orice parere
Sau cu toate
Daca folositi un ORM (Entity Framework sau altul) query-urile ar trebui sa fie transparente pt programator si sa se ocupe el de diverse diferente care pot aparea intre bazele de date.
var blog = db.Blogs
.OrderBy(b => b.BlogId)
.First();
Si acesta sintaxa o sa fie tradusa de orm pt bazele de date indiferent ce sunt
Aplicatia ta va trebui sa aibe insa driverele de baze de date pt ce baza de date vrei sa folosesti
2 Likes
Când aleg un tech, urmez raționamentul:
if X are ceva ce îmi este necesar dar nu este în Y :
alege X
else:
alege ce îmi este (mai) familiar
Fix la DB ar trebui să fie mai simplu: folosești ORM.
2 Likes
Eu as vota pentru Postgres cu Entity Framework.
Grija ca ai multe variante de postgres, specializate ori pe scalabilitate, ori pe redundanta, ori pe performanta ori pe diferite tipuri de date. (e.g. time series sau GIS) Sunt si solutii precum Yugabyte care este postgres dar scaleaza orizontal si include Hasura, ceea ce iti permite sa faci api-uri graphql direct din DB.
CockroachDb are o oferta foarte generoasa la baza de date gazduita in free tier.
Ah, Winform, daca iti trebuie ceva local sqlite iti ajunge, n-are rost sa pui altceva.
2 Likes
Eu m-am lămurit cu ORM-urile, sunt inutil de complicate și overhead-ul este înfiorător (timpi de procesor + RAM consumat în neștire). Mai ales la o aplicație desktop, vrei ca aplicația să fie sprintenă și să nu consume RAM aiurea.
Abordarea mea este să implementez in-house o clasă-wrapper abstractă minimală peste protocoalele de engine-uri SQL care mă interesează și să folosesc direct SQL. Până la urmă, mare brânză nu ai de făcut, select-uri, insert-uri, update-uri si delete-uri.
Poate uneori câte un join. Dacă devine prea complicat, uneori este preferabil să folosești proceduri stocate sau chiar mai multe query-uri urmate de post-procesarea datelor în aplicație. Că dacă faci pe deșteptul și creezi un cârnat de join-uri pe două pagini, după câteva zile nu te ajută nici mama ORM-urilor să înțelegi mizeria pe care singur ai creat-o.
9 Likes
se vede cine a lucrat pe high traffic; primul pas e sa elimi orm-ul 
7 Likes
- e expus public (website)? / ruleaza desktop/embedded?
- cate date are de ronțăit in medie? cati utilizatori concurenti?
- acum ce storage engine / persistenta aveti?
- care e cel mai complex usecase de retrieve date de care stiti acuma?
2 Likes
Da, am avut și cazuri de high traffic, și cazuri în care resursele erau limitate, de exemplu o aplicație industrială care trebuia să ruleze pe Raspberry Pi și avea de stocat zeci de mii de intrări în log.
3 Likes
in my mind, log == text data == (distributed) filesystem plus metadata (prove me wrong 
)
3 Likes
Well… normal mergea și text chior, problema e că clientul voia să poată și să facă diverse filtrări prin el (după dată, după indexul mașinii - că sunt mai multe mașini care trimit date către GPIO-rile Rasbperry-ului - etc).
S-a rezolvat simplu cu SQLite, doar că nu trebuia să folosesc SQLAlchemy. Inițial am crezut că e din cauză de Python, dar nu, era din SQLAlchemy.
3 Likes
.net e mai special cu linq
2 Likes
Aplicatia e scrisa acum mai bine de 10 ani cand nu erau la moda orm-uri,foloseste Ado .NET (4.7) ,ruleaza in mare parte in reteau locala dar si pe un server web,caz in care conexiunea la baza de date se face prin VPN.Are si o mica extensie web pentru accesarea anumitor functii si de pe mobil,pentru extensie s-a folosit .NET Core 3.1.Cea mai mare tabela are cam 100.000 de inregistrari,useri concurenti<100.momentan folosim Firebird 3 ca sgbd,nu sunt probleme cu performanta,problema cea mare este ca ne-am lovit de acest bug in conectorul NET Core ceea ce face imposibil sa migram la NET Core 6 iar suportul pt 3.1 se termina luna viitoare,de aceea ne am gandit sa mai adaugam un sgbd.aplicatia se distribuie la clienti si erau candva niste limitari pe treaba asta la mysql cu aplicatii comerciale.multumesc
Cred ca nu conteaza deloc ce baza de date folosesti in cazul tau. MySQL iarasi are foarte multe variante, vitess, mariadb, percona, titaniumdb…
@serghei domain modelul il poti crea in cod, din cod poti genera migrarile, poti scrie teste, poti genera mock data (AutoFixture/JFixture). Daca pur si simplu faci query-uri fara ca modelul sa fie legat de datele din cod o sa ajungi sa faci un query si dupa iei tot ce primesti si il filtrezi inca o data in backend si cele doua structuri vor diferi.
La .net posibil mai ai smecherie cu auto-complete pe tipurile de date la query-uri cu linq.
1 Like
Parerea mea (de nespecialist), ar fii sa testezi daca acele query-uri pe care le foloseste aplicatia, merg pe mysql sau postgre.
Vedeti daca folositi vreun fetture mai special din baza de date curenta si daca are corespondenta in altele.
Eu folosesc MySQL pe o aplicatie care toaca din 5 in 5 minute fisiere de pe diverse echipamente si nu am avut probleme de performanta la baza
1 Like
Cand am vazut titlul am zis ca e o discutie de acum 15 ani 
Asta e ca tab vs spaces.
Altfel ca baze interesante va recomand datomic.
3 Likes
PostgreSQL are mult mai multe facilitati si comportament mult mai ok decat MySQL. Alegerea e a no-brainer.
Un articol din 2013: Do Not Pass This Way Again - The Grimoire Unele lucruri s-au mai inbunatatit, dar prea putine.
1 Like
Dacă nu e imensă și dacă vrei să o distribui împreună cu aplicația poate mai bine merge spre sqlite: SQLite Home Page
3 Likes
Eu m-am lamurit cu cei care isi fac orm-ul propriu pe genuchi, pe un proiect serios de echipa, clasa ta wrapper ajunge un orm, hight traffic mai degrapa resolve cu catching si sitem design nu scriind quer-uri de mana.
1 Like
Right. De ce să fie simplu când poate fi complicat?
De ce să consumăm 1M de RAM pentru un recordset de 10.000 de inregistrări când putem consuma 1G de RAM?
Și în cele din urmă tot de mână scrii query-urile, numai că în loc sa scrii un string de 100 de caractere ajungi să scrii un cârnat de funcții dubioase care fac fix același lucru, doar că mult mai complicat și infinit mai greu de înțeles ulterior.
4 Likes
Un ORM iti dupleaza sau tripleaza consumul de ram, insa nu ai treaba sa tii 10k rows in ram, poate pt catching si in cazul asta un server de 1gb ram e 5$, simplu sau complicat e relativ, de ex hype ca Go e simplu asta pt ca lasa mult boilerplate la derzvoltator si ei se spala pe mana cu marketing one liners.
Ne e vb neaparat de quer-uri cat de vb de mapari row-object si parametri, cu toate securitatea necesara si check-urile ca nu pui un nume de coloane gresit, bine daca ai un mapper automat atunci au 40% dintr-un ORM.
1 Like