De ce să folosiți baza de date SQL? [închis] (Programare, Sql, Bază De Date, Proiectarea Bazei De Date, Structuri De Date)

martinthenext a intrebat.
a intrebat.

Nu sunt foarte sigur că stackoverflow este un loc pentru o astfel de întrebare generală, dar hai să încercăm.

Fiind expus nevoii de a stoca undeva datele aplicației, am folosit întotdeauna MySQL sau sqlite, doar pentru că așa se face întotdeauna. Cum se pare că toată lumea folosește aceste baze de date (majoritatea produselor software, framework-uri, etc.), este destul de greu pentru un dezvoltator începător ca mine să înceapă să se gândească dacă aceasta este o soluție bună sau nu.

Bine, să spunem că avem o logică orientată pe obiecte în aplicația noastră, iar obiectele sunt legate între ele într-un fel sau altul. Trebuie să mapăm această logică pe logica de stocare, deci sunt necesare și relațiile dintre obiectele bazei de date. Acest lucru ne conduce la utilizarea bazei de date relaționale, iar eu sunt de acord cu asta – ca să simplificăm, rândurile tabelelor din baza noastră de date vor trebui uneori să aibă referințe la rândurile altor tabele. Dar de ce să folosim limbajul SQL pentru interacțiunea cu o astfel de bază de date?

Interogarea SQL este un mesaj text. Pot să înțeleg că este mișto pentru a înțelege de fapt ce face, dar nu este o prostie să folosești nume de tabele și coloane text pentru o parte a aplicației pe care nimeni nu a văzut-o vreodată după implementare? Dacă ar fi trebuit să scrieți o stocare de date de la zero, nu ați fi folosit niciodată acest tip de soluție. Personal, aș fi folosit un bytecode „compilat pentru interogare db”, care ar fi fost asamblat o dată în cadrul unei aplicații client și transmis către baza de date. Și cu siguranță ar fi numit tabelele și colonele după numere de identificare, nu după șiruri ascii. În cazul unor modificări în structura tabelelor, aceste interogări pe octeți ar putea fi recompilate în conformitate cu noua schemă a bazei de date, stocate în XML sau ceva de genul acesta.

Care sunt problemele pe care le ridică ideea mea? Există vreun motiv pentru care să nu o scriu eu însumi și să folosesc în schimb baza de date SQL?

EDITARE Pentru a-mi clarifica mai bine întrebarea. Majoritatea răspunsurilor susțin că SQL, fiind o interogare text, ajută dezvoltatorii să înțeleagă mai bine interogarea în sine și să o depaneze mai ușor. Personal, nu am mai văzut oameni care să scrie interogări SQL de mână de ceva vreme. Toți cei pe care îi cunosc, inclusiv eu, folosesc ORM. Această situație, în care construim un nou nivel de abstractizare pentru a ascunde SQL, ne duce cu gândul dacă avem nevoie de SQL sau nu. V-aș fi foarte recunoscător dacă ați putea da câteva exemple în care SQL este folosit fără ORM în mod intenționat și de ce.

EDIT2 SQL este o interfață între un om și o bază de date. Întrebarea este de ce trebuie să îl folosim pentru interacțiunea aplicație/bază de date? Eu cer în continuare exemple de oameni care scriu/depanează SQL.

Comentarii

  • Când am citit titlul, am crezut că va fi o întrebare stupidă… dar de fapt este o idee foarte interesantă ! –  > Por Thomas Levesque.
  • Poate că întrebarea ar trebui să fie: „De ce să folosești SQL vs. interogare compilată în baza de date”? –  > Por Nelson Rothermel.
  • De obicei, eu scriu SQL de mână (recunosc, interogările mele nu sunt foarte complicate). –  > Por Paul Nathan.
  • @martinthenext. Re: „Încă cer exemple de ființe umane care scriu/depanează SQL”. Vorbești serios? –  > Por Juan Pablo Califano.
  • Grupul NoSQL Google este bun pentru acest tip de interogare </pun> de asemenea. –  > Por CurtainDog.
25 răspunsuri
Jay

Dacă tot ce trebuie să faceți este să stocați undeva niște date de aplicație, atunci un RDBMS de uz general sau chiar SQLite ar putea fi exagerat. Serializarea obiectelor dvs. și scrierea lor într-un fișier ar putea fi mai simplă în unele cazuri. Un avantaj al SQLite este că, dacă aveți o mulțime de informații de acest tip, toate sunt conținute într-un singur fișier. Un dezavantaj este că este mai dificil de citit. De exemplu, dacă vă serializați datele în YAML, puteți citi fișierul cu orice editor de text sau shell.

Personal, aș fi folosit un bytecode de tip „compilated db query”, care ar fi fost asamblat o dată în cadrul unei aplicații client și transmis către baza de date.

Acesta este modul în care funcționează unele API-uri de baze de date. Consultați SQL static și declarațiile pregătite.

Există vreun motiv pentru care să nu scriu eu însumi și să folosesc în schimb baza de date SQL?

Dacă aveți nevoie de multe funcții, la un moment dat va fi mai ușor să folosiți o RDMBS existentă decât să vă scrieți propria bază de date de la zero. Dacă nu aveți nevoie de multe caracteristici, o soluție mai simplă poate fi mai înțeleaptă.

Ideea produselor de baze de date este de a evita scrierea stratului de bază de date pentru fiecare program nou. Da, un RDMBS modern s-ar putea să nu fie întotdeauna perfect pentru fiecare proiect. Acest lucru se datorează faptului că au fost concepute pentru a fi foarte generale, astfel încât, în practică, veți obține întotdeauna caracteristici suplimentare de care nu aveți nevoie. Asta nu înseamnă că este mai bine să aveți o soluție personalizată. Mănușa nu trebuie să se potrivească întotdeauna perfect.

UPDATE:

Dar de ce să folosești limbajul SQL pentru interacțiunea cu o astfel de bază de date?

Bună întrebare.

Răspunsul la aceasta poate fi găsit în lucrarea originală care descrie modelul relațional Un model relațional de date pentru bănci mari de date partajate, , de E. F. Codd, publicat de IBM în 1970. Această lucrare descrie problemele legate de tehnologiile de baze de date existente la acea vreme și explică de ce modelul relațional este superior.

Motivul pentru utilizarea modelului relațional și, prin urmare, a unui limbaj de interogare logică precum SQL, este independența datelor.

Independența datelor este definită în lucrare astfel:

„… independența programelor de aplicații și a activităților terminale față de creșterea tipurilor de date și de schimbările în reprezentarea datelor”.

Înainte de modelul relațional, tehnologia dominantă pentru bazele de date a fost denumită modelul de rețea. În acest model, programatorul trebuia să cunoască structura pe disc a datelor și să parcurgă manual arborele sau graficul. Modelul relațional permite scrierea unei interogări în raport cu schema conceptuală sau logică, care este independentă de reprezentarea fizică a datelor de pe disc. Această separare a schemei logice de schema fizică este motivul pentru care folosim modelul relațional. Pentru mai multe informații pe această temă, aici sunt câteva slide-uri de la un curs de baze de date. În modelul relațional, folosim limbaje de interogare bazate pe logică, cum ar fi SQL, pentru a prelua date.Lucrarea lui Codd intră în mai multe detalii despre beneficiile modelului relațional. Citiți-l.

SQL este un limbaj de interogare care este ușor de tastat pe calculator, spre deosebire de limbajele de interogare utilizate de obicei în lucrările de cercetare. Lucrările de cercetare folosesc în general algebra relațiilor sau calculul relațional pentru a scrie interogări.

Pe scurt, folosim SQL pentru că se întâmplă să folosim modelul relațional pentru bazele noastre de date.

Dacă înțelegeți modelul relațional, nu este greu de înțeles de ce SQL este așa cum este. Așadar, practic, trebuie să studiați mai în profunzime modelul relațional și elementele interne ale bazelor de date pentru a înțelege cu adevărat de ce folosim SQL. Altfel, poate fi un pic de mister.

UPDATE 2:

SQL este o interfață între un om și o bază de date. Întrebarea este de ce trebuie să îl folosim pentru interacțiunea dintre aplicație și baza de date? Încă cer exemple de ființe umane care scriu/depanează SQL.

Pentru că baza de date este o bază de date relațională, ea înțelege doar limbajele de interogare relaționale. La nivel intern, aceasta utilizează un limbaj asemănător cu algebra relațională pentru a specifica interogări pe care le transformă apoi într-un plan de interogare. Așadar, noi ne scriem interogarea într-o formă pe care o putem înțelege (SQL), iar baza de date preia interogarea noastră SQL și o transformă în limbajul său intern de interogare. Apoi ia interogarea și încearcă să găsească un „plan de interogare” pentru a o executa. Apoi, execută planul de interogare și returnează rezultatul.

La un moment dat, trebuie să codificăm interogarea noastră într-un format pe care baza de date să îl înțeleagă. Baza de date știe doar cum să convertească SQL în reprezentarea sa internă, de aceea există întotdeauna SQL la un moment dat în lanț. Acest lucru nu poate fi evitat.

Atunci când folosiți ORM, nu faceți decât să adăugați un strat peste SQL. SQL este încă acolo, doar că este ascuns. Dacă aveți un strat de nivel superior pentru a traduce cererea în SQL, atunci nu trebuie să scrieți SQL direct, ceea ce este benefic în unele cazuri. Uneori nu avem un astfel de strat capabil să efectueze tipurile de interogări de care avem nevoie, așa că trebuie să folosim SQL.

Comentarii

  • În cele din urmă, el se întreabă că, dacă SQL este conceput pentru ca oamenii să acceseze bazele de date, de ce îl folosesc computerele și nu un sistem mai bine conceput pentru computere? –  > Por RCIX.
  • Calculatoarele nu sunt încă interesate de propriile date. –  > Por Lealo.
Donnie

Toată lumea pe care o cunosc, inclusiv eu, folosește ORM

Ciudat. Toată lumea pe care o cunosc, inclusiv eu, încă scrie cea mai mare parte din SQL de mână. De obicei, se ajunge la interogări mai strânse și mai performante decât cu o soluție generată. Și, în funcție de industria și aplicația dvs., această viteză face contează. Uneori foarte mult. da, uneori folosesc LINQ pentru o operațiune rapidă și murdară în care nu-mi pasă cum arată SQL-ul rezultat, dar până acum nimic automatizat nu bate SQL-ul reglat manual pentru situațiile în care performanța față de o bază de date mare într-un mediu cu încărcare mare contează cu adevărat.

Comentarii

  • +1 – și cu o schemă de proiectare decentă, SQL devine mai ușor de utilizat. –  > Por wlangstroth.
  • @Fogle – este adresat în mod special celor două ediții ale sale care cer exemple de oameni care încă scriu manual SQL în loc să folosească un ORM / interogări generate automat. –  > Por Donnie.
  • @RP – Cred că, de fapt, spunem același lucru aici. ORM-urile vor face o mulțime de lucruri de bază, iar lucrurile de bază sunt cele mai multe lucruri. În timpul cât am lucrat cu Hibernate, a trebuit să desfac poate 1 sau 2 interogări și, retrospectiv, ar fi trebuit să renunț la interogări și să gestionez acea parte de date (chestii sensibile la timp) cu o coadă prio în memorie. –  > Por CurtainDog.
  • +1: În timp ce ORM-urile fac interogările ușoare și mai ușoare, se pare că (cel puțin pentru mine) fac interogările dificile și mai dificile. –  > Por SingleNegationElimination.
  • Utilizarea ORM-urilor tinde, de asemenea, să producă o mulțime de interogări în comparație cu o interogare scrisă de mână. –  > Por wmercer.
Milan Babuškov

Având în vedere faptul că ați folosit MySQL și SQLite, vă înțeleg perfect punctul de vedere. Majoritatea SGBD-urilor au caracteristici care ar necesita o parte din programare din partea dvs., în timp ce dvs. le primiți gratuit de la baza de date:

  • Indicii – puteți stoca cantități mari de date și puteți totuși să filtrați și să căutați foarte rapid datorită indicilor. Desigur, ați putea să vă implementați propria indexare, dar de ce să reinventați roata

  • integritatea datelor – utilizarea unor caracteristici ale bazei de date, cum ar fi cheile străine în cascadă, poate asigura integritatea datelor în întregul sistem. Trebuie doar să declarați relația dintre date, iar sistemul se ocupă de restul. Desigur, ați putea implementa constrângerile în cod, dar este mai mult de lucru. Luați în considerare, de exemplu, ștergerea, unde ar trebui să scrieți cod în destructorul obiectului pentru a urmări toate obiectele dependente și a acționa în consecință

  • capacitatea de a avea aplicații multiple scrise în limbaje de programare diferite, care funcționează pe sisteme de operare diferite, unele chiar distribuite în rețea – toate folosind aceeași aceleași date stocate într-o bază de date comună

  • implementarea extrem de ușoară a model de observator prin intermediul declanșatorilor. Există multe cazuri în care doar unele date depind de alte date și nu afectează aspectul de interfață a aplicației. Asigurarea coerenței poate fi foarte dificilă sau poate necesita multă programare. Desigur, puteți implementa un comportament de tip trigger cu ajutorul obiectelor, dar acest lucru necesită mai multă programare decât o simplă definiție SQL.

Comentarii

  • Un mare hop în ceea ce privește aplicațiile multiple. Mulți dezvoltatori sunt obișnuiți cu aplicațiile web sau cu alte cazuri în care există o corespondență directă 1 la 1 între aplicație și baza de date. În multe situații de întreprindere, acest lucru nu este valabil. Aveți o bază de date care poate avea 2, 3 sau chiar o duzină de aplicații, toate lucrând cu aceleași date. Unul dintre cele mai frecvente scenarii pe care le-am văzut este cel al aplicației de procesare în două părți și al aplicației de raportare. Adesea scrise de grupuri diferite, în limbi diferite. Încercarea de a face ca acest lucru să funcționeze cu ORM-uri este foarte dificilă. SQL simplu ușurează lucrurile. –  > Por Christopher Cashell.
  • Sunt de acord, de ce să reinventăm roata? Este exact ceea ce ar trebui să faceți atunci când creați o bază de date separată și unică – interacțiune între aplicație și bază de date, de fiecare dată când creați o nouă aplicație. –  > Por Lealo.
MBCook

Există câteva răspunsuri bune aici. Voi încerca să adaug și eu doi cenți.

Îmi place SQL, pot gândi în el destul de ușor. Interogările produse de straturile de deasupra BD (cum ar fi cadrele ORM) sunt de obicei hidoase. Ele selectează tone de chestii suplimentare, se alătură la lucruri de care nu aveți nevoie etc.; toate acestea pentru că nu știu că nu doriți decât o mică parte din obiectul din acest cod. Atunci când aveți nevoie de performanțe ridicate, veți ajunge adesea să intrați și să folosiți cel puțin câteva interogări SQL personalizate într-un sistem ORM doar pentru a accelera câteva blocaje.

De ce SQL? Așa cum au spus și alții, este ușor pentru oameni. Este un bun numitor comun minim. Orice limbaj poate face SQL și poate apela clienți de linie de comandă, dacă este necesar, iar aceștia sunt aproape întotdeauna o bibliotecă bună.

Este ineficientă analizarea SQL? Oarecum. Gramatica este destul de structurată, astfel încât nu există tone de ambiguități care să îngreuneze munca analizatorului. Adevărul este că analiza SQL nu presupune practic nimic.

Să presupunem că executați o interogare de tipul „SELECT x FROM table WHERE id = 3”, apoi o faceți din nou cu 4, apoi cu 5, la nesfârșit. În acest caz, este posibil să existe un cost suplimentar de analiză. Acesta este motivul pentru care aveți declarații pregătite (așa cum au menționat și alții). Serverul analizează interogarea o singură dată și poate schimba 3, 4 și 5 fără a fi nevoie să reanalizeze totul.

Dar acesta este un caz trivial. În viața reală, este posibil ca sistemul dvs. să unească 6 tabele și să trebuiască să extragă sute de mii de înregistrări (dacă nu mai mult). Poate fi o interogare pe care o lăsați să ruleze pe un cluster de baze de date timp de ore întregi, pentru că acesta este cel mai bun mod de a face lucrurile în cazul dvs. Chiar și în cazul unei interogări care durează doar un minut sau două pentru a fi executată, timpul de analizare a interogării este practic gratuit în comparație cu extragerea înregistrărilor de pe disc și sortarea/agregarea/etc. Cheltuielile de transmitere a ext „LEFT OUTER JOIN ON” sunt de doar câțiva octeți în comparație cu transmiterea octetului special codificat 0x3F. Dar atunci când setul de rezultate este de 30 MB (ca să nu mai vorbim de mai mult de un gigacalorii), acei câțiva octeți în plus nu au nicio valoare în comparație cu faptul că nu trebuie să vă încurcați cu un obiect special de compilare a interogărilor.

Mulți oameni folosesc SQL pe baze de date mici. Cea mai mare cu care interacționez eu are doar câteva zeci de giga. SQL este folosit pe orice, de la fișiere mici (cum ar putea fi micile baze de date SQLite) până la clustere Oracle de dimensiunea unui terabyte. Având în vedere puterea sa, este de fapt un set de comenzi surprinzător de simplu și mic.

Comentarii

  • „SELECT x FROM table WHERE id = 3” Aceste comenzi SQL nu sunt, de asemenea, conectate la cei mai buni algoritmi găsiți, indiferent de tipul de date, de exemplu. –  > Por Lealo.
Michael Borgwardt
  • Este un standard omniprezent. Aproape toate limbajele de programare au o modalitate de a accesa bazele de date SQL. Încearcă asta cu un protocol binar proprietar.
  • Toată lumea îl cunoaște. Puteți găsi cu ușurință experți, iar noii dezvoltatori îl vor înțelege de obicei într-o oarecare măsură, fără a fi nevoie de instruire
  • SQL este foarte strâns legat de modelul relațional, care a fost explorat temeinic în ceea ce privește optimizarea și scalabilitatea. Dar încă necesită frecvent modificări manuale (crearea de indici, structura interogărilor etc.), care sunt relativ ușoare datorită interfeței textuale.

Comentarii

  • 1) Îmi cer scuze dacă am înțeles ceva greșit, dar de ce folosiți cuvântul proprietary? Mă gândeam la o soluție open-source, de exemplu. 2) 3) Se pare că este un lucru bun pentru dezvoltatori să aibă interogări textuale pentru că sunt ușor de înțeles. Dar cum rămâne cu acei dezvoltatori care petrec mult timp cu optimizarea interogărilor? Merită acest lucru? Nu cred că o interfață de aplicație bună pentru interogări în cod de octet, precum cea despre care am scris, ar fi fost atât de greu de înțeles. Dezvoltatorii și-ar dori mai mult viteza decât simplitatea învățării, cred eu. –  > Por martinthenext.
  • @martinthenext – Problema cu acest lucru este interoperabilitatea. SQL este text și poate fi copiat/lipit, revizuit, etc. cu ușurință. Cu o versiune compilată, aveți nevoie de o aplicație. Integrați una în fiecare bază de date, creați una externă care să funcționeze în toate bazele de date? Cum rămâne cu sistemele de operare diferite sau chiar cu modificările de caracteristici între sistemele de baze de date și fiecare versiune? SQL nu are niciuna dintre aceste probleme… până când ajungeți la SQL builders 🙂 –  > Por Nelson Rothermel.
  • …probabil că este același motiv pentru care XML este folosit atât de mult. XML nu este foarte eficient, dar textul este mai ușor de lucrat cu el decât cu un format binar oarecare. Un fișier XML corupt este mai ușor de reparat (cel puțin de către un om) decât un fișier binar, etc. –  > Por Nelson Rothermel.
  • @martinthenext: asta sună ca și cum ai crede că optimizarea interogărilor este necesară doar pentru că este un format textual. Nimic nu ar putea fi mai departe de adevăr. Optimizarea interogărilor (și a structurii BD) se referă la structura și conținutul semantic al BD și al interogărilor. Un format binar ar face pur și simplu imposibilă acest tip de optimizare fără instrumente suplimentare. –  > Por Michael Borgwardt.
ChrisW

Dar de ce să folosești limbajul SQL pentru interacțiunea cu o astfel de bază de date?

Cred că din același motiv pentru care folosiți un limbaj lizibil pentru oameni (cod sursă) pentru interacțiunea cu compilatorul.

Personal, aș fi folosit un bytecode de tip „compilated db query”, care ar fi fost asamblat o dată în interiorul unei aplicații client și transmis către baza de date.

Aceasta este o caracteristică existentă (opțională) a bazelor de date, numită „proceduri stocate”.


Editați:

V-aș fi foarte recunoscător dacă ați putea da câteva exemple în care SQL este folosit fără ORM în mod intenționat, și de ce

Când am implementat propriul meu ORM, am implementat cadrul ORM folosind ADO.NET: iar folosirea ADO.NET include folosirea instrucțiunilor SQL în implementarea sa.

Erwin Smout

După toate editările și comentariile, ideea principală a întrebării dumneavoastră pare să fie : de ce natura SQL este mai aproape de a fi o interfață om/bază de date decât de a fi o interfață aplicație/bază de date ?

Iar răspunsul foarte simplu la care întrebare este: pentru că exact asta a fost menit să fie inițial.

Predecesorii lui SQL (QUEL fiind probabil cel mai important) au fost concepuți pentru a fi exact asta: un limbaj de interogare, adică unul care nu conținea nici un fel de INSERT, UPDATE, DELETE.

Mai mult, se dorea a fi un limbaj de interogare care să poată fi utilizat de orice utilizator, cu condiția ca acesta să cunoască structura logică a bazei de date și, evident, să știe cum să exprime această structură logică în limbajul de interogare pe care îl utiliza.

Ideile inițiale din spatele QUEL/SQL erau că o bază de date era construită folosind „orice mecanism imaginabil”, că baza de date „reală” putea fi cu adevărat orice (de exemplu, un singur fișier XML gigantic – deși „XML” nu era considerat o opțiune validă la acea vreme) și că ar exista „un fel de mecanism” care să înțeleagă cum să transforme structura reală a acelui „orice” în structura relațională logică așa cum era percepută de utilizatorul SQL.

Faptul că, pentru a realiza efectiv acest lucru, este necesar ca structurile de bază să se preteze la „vizualizarea lor relațională”, nu era înțeles la fel de bine în acele vremuri ca acum.

Comentarii

  • XML nu exista la acea vreme. –  > Por mikerobi.
  • De asemenea, nu este sql cea mai completă laungă a tuturor manipulărilor de date pe care le poți face? Și dacă nu ai asta – cum construiești aplicații (conectate la baze de date)? Aceste aplicații ar trebui să folosească de fiecare dată un nou laungage indivudual. Ar fi ca și cum ați dezvolta un nou laungage Java de fiecare dată când creați o nouă aplicație (și ați include doar ceea ce este necesar în programul respectiv). –  > Por Lealo.
  • @lealo Ideea acestui răspuns a fost că SQL a ajuns să fie așa cum este pentru că a fost proiectat în primul rând cu gândul la tipul de utilizator care stă la o consolă și introduce comenzile direct în SGBD. Că acesta nu este cel mai potrivit tip de interfață pentru un programator care scrie programe care se adresează SGBD-ului, este destul de evident. Astfel, avem situația relativ ciudată în care limbajele de programare „tehnice, de nivel inferior” trebuie să recurgă la un limbaj „de nivel superior/la nivel de utilizator final” pentru a realiza manipularea datelor din baza de date. Ar fi putut fi altfel, dar pur și simplu nu este … –  > Por Erwin Smout.
  • … După cum observați corect, acest lucru ar fi dus probabil la „o altă” serie de limbaje: limbajul destinat integrării cu COBOL care face ca interfața de date reală să arate ca în COBOL, limbajul destinat integrării cu C care face ca interfața de date reală să arate ca în C)ish, etc. etc. etc. etc. (Păreți să presupuneți că acest lucru ar fi fost în mod necesar și prin definiție un lucru rău, dar eu nu sunt de acord (adică sunt mult mai puțin sigur de acest lucru decât păreți voi) .) –  > Por Erwin Smout.
  • Nu, nu trebuie să „reinventezi” algoritmii, deoarece algoritmii sunt definiți în termeni de matematică, iar matematica se aplică indiferent de limbajul care îi implementează. Deci nu există „reinventare”, ci doar „reimplementare” într-o anumită măsură. Și nu, acest lucru nu este neapărat un lucru rău. „Algoritmii” de adresare a memoriei sunt reimplementați tot timpul. Atunci când descoperim că „One Meg va nu mai este nu este suficient pentru nimeni”, atunci când descoperim că „16 Meg nu vor fi suficienți” (trecerea mainframe-ului de la MVS la MVS/XA), atunci când descoperim că 32 de biți nu sunt suficienți, etc. etc. –  > Por Erwin Smout.
Mark Byers

Da, este enervant să trebuiască să scrii instrucțiuni SQL pentru a stoca și recupera obiecte.

De aceea, Microsoft a adăugat lucruri precum LINQ (interogare integrată în limbaj) în C# și VB.NET pentru a face posibilă interogarea bazelor de date folosind obiecte și metode în loc de șiruri de caractere.

Cele mai multe alte limbaje au ceva similar, cu diferite niveluri de succes în funcție de abilitățile limbajului respectiv.

Pe de altă parte, este util să știi cum funcționează SQL și cred că este o greșeală să te ferești complet de el. Dacă folosiți baza de date fără să vă gândiți, puteți scrie interogări extrem de ineficiente și puteți indexa incorect baza de date. Dar, odată ce înțelegeți cum să utilizați corect SQL și v-ați reglat baza de date, aveți la dispoziție un instrument foarte puternic și testat pentru a găsi extrem de rapid exact datele de care aveți nevoie.

Comentarii

  • Mi se pare că declarațiile LINQ sunt traduse ulterior în SQL, iar întreaga interacțiune cu db se face așa cum s-a făcut întotdeauna. Aceasta este, fără îndoială, o metodă mișto de a nu folosi SQL șchiop, dar nu elimină întreaga problemă cu interfața cu baza de date despre care scriam. –  > Por martinthenext.
  • @martinthenext: Cu LINQ to SQL, dacă se schimbă baza de date (de exemplu, se schimbă numele unei coloane), puteți ajusta fișierul DBML. Nu este necesar să modificați codul. –  > Por Mark Byers.
blissapp

Cel mai mare motiv pentru care folosesc SQL este raportarea ad-hoc. Acel raport pe care utilizatorii dvs. de afaceri îl doresc, dar nu știu încă dacă au nevoie de el.

neoblitz

SQL este o interfață între un om și o bază de date. Întrebarea este de ce trebuie să îl folosim pentru interacțiunea aplicație/bază de date? Încă mai cer exemple de ființe umane care scriu/depanează SQL.

Eu folosesc mult sqlite chiar de la cele mai simple sarcini (cum ar fi înregistrarea jurnalelor mele de firewall direct într-o bază de date sqlite) până la sarcini analitice și de depanare mai complexe în cercetarea mea zilnică. Așezarea datelor mele în tabele și scrierea de interogări SQL pentru a le prelucra în moduri interesante mi se pare cel mai natural lucru în aceste situații.

În ceea ce privește întrebarea dvs. despre motivul pentru care este încă folosit ca interfață între aplicație/bază de date, acesta este raționamentul meu simplu:

  1. Există aproximativ 3-4 decenii de cercetări serioase în acest domeniu, începând din 1970, cu lucrarea fundamentală a lui Codd despre algebra relațională.Algebra relațională constituie baza matematică a SQL (și a altor SQL-uri), deși SQL nu urmează în totalitate modelul relațional.

  2. Forma „text” a limbajului (pe lângă faptul că este ușor de înțeles de către oameni) este, de asemenea, ușor de analizat de către mașini (de exemplu, folosind un analizator gramatical ca lex) și este ușor de convertit în orice „bytecode” folosind orice număr de optimizări.

  3. Nu sunt sigur că dacă făcând acest lucru în alt mod s-ar fi obținut convingător avantaje convingătoare în cazurile generice. În caz contrar, ar fi fost probabil descoperit și adoptat în cele 3 decenii de cercetare. SQL oferă probabil cele mai bune compromisuri atunci când se face legătura între oameni/baze de date și aplicații/baze de date.

Întrebarea care devine atunci interesantă de pus este: „Care sunt beneficiile reale ale utilizării SQL în orice alt mod „non-text”?”. Voi căuta pe Google pentru acest lucru acum:)

ConcernedOfTunbridgeWells

SQL este o interfață comună utilizată de platforma SGBD – întregul scop al interfeței este ca toate operațiunile bazei de date să poată fi specificate în SQL fără a fi nevoie de apeluri API suplimentare. Aceasta înseamnă că există o interfață comună pentru toți clienții sistemului – software de aplicații, rapoarte și instrumente de interogare ad-hoc.

În al doilea rând, SQL devine din ce în ce mai util pe măsură ce interogările devin mai complexe. Încercați să utilizați LINQ pentru a specifica o îmbinare cu 12 căi a cu trei condiții bazate pe predicte existențiale și o condiție bazată pe un agregat calculat într-o subinterogare. Acest tip de lucru este destul de ușor de înțeles în SQL, dar este puțin probabil să fie posibil într-un ORM.

În multe cazuri, un ORM va face 95% din ceea ce vă doriți – majoritatea interogărilor emise de aplicații sunt operațiuni CRUD simple pe care un ORM sau un alt mecanism generic de interfață cu baza de date le poate gestiona cu ușurință. Unele operații se realizează cel mai bine folosind cod SQL personalizat.

Cu toate acestea, ORM-urile nu reprezintă totul în ceea ce privește interfața cu baza de date. Cartea lui Fowler, Patterns of Enterprise Application Architecture, are o secțiune destul de bună despre alte tipuri de strategii de acces la baza de date, cu o discuție despre meritele fiecăruia.

Există adesea motive întemeiate pentru a nu utiliza un ORM ca principal strat de interfață cu baza de date. Un exemplu bun este acela că bibliotecile de baze de date ale platformei, cum ar fi ADO.Net, fac adesea o treabă suficient de bună și se integrează bine cu restul mediului. S-ar putea să constatați că avantajul utilizării unei alte interfețe nu depășește cu adevărat beneficiile aduse de integrare.

Cu toate acestea, motivul final pentru care nu puteți ignora SQL este că, în cele din urmă, lucrați cu o bază de date dacă realizați o aplicație de bază de date. Există multe, multe povești WTF despre greșeli în codul aplicațiilor comerciale făcute de persoane care nu au înțeles corect bazele de date. Un cod de bază de date prost gândit poate cauza probleme în foarte multe feluri, iar faptul de a crede cu ușurință că nu trebuie să înțelegeți cum funcționează SGBD este un act de orgoliu care va veni să vă muște într-o zi. Mai rău, va veni și va mușca un alt biet amărât care va moșteni codul tău.

Jeff Schumacher

Deși vă înțeleg punctul de vedere, limbajul de interogare SQL are un loc, în special în aplicațiile mari cu multe date. Și ca să subliniez un lucru evident, dacă limbajul nu ar exista, nu i s-ar putea spune SQL (Structured Query Language). Avantajul de a avea SQL față de metoda pe care ați descris-o este că SQL este, în general, foarte ușor de citit, deși unii chiar împing limitele interogărilor lor.

Sunt întru totul de acord cu Mark Byers, nu ar trebui să vă protejați de SQL. Orice dezvoltator poate scrie SQL, dar pentru ca aplicația dvs. să funcționeze cu adevărat bine cu interacțiunea SQL, este necesară înțelegerea limbajului.

Dacă totul a fost precompilat cu bytecode, așa cum ați descris, nu mi-ar plăcea să fiu cel care trebuie să depaneze aplicația după ce dezvoltatorul inițial a plecat (sau chiar după ce nu a văzut codul timp de 6 luni).

CurtainDog

Cred că premisa întrebării este incorectă. Faptul că SQL poate fi reprezentat ca text este irelevant. Majoritatea bazelor de date moderne ar compila interogările doar o singură dată și le-ar pune în cache oricum, astfel încât aveți deja efectiv un „bytecode compilat”. Și nu există niciun motiv pentru care acest lucru nu s-ar putea întâmpla în ceea ce privește clientul, deși nu sunt sigur că cineva a făcut-o.

Ați spus că SQL este un mesaj text, ei bine, eu mă gândesc la el ca la un mesager și, după cum știm, nu trageți în mesager. Adevărata problemă este că relațiile nu sunt o modalitate suficient de bună de organizare a datelor din lumea reală. SQL este doar un ruj de buze pe porc.

Juan Pablo Califano

În prima parte, se pare că vă referiți la ceea ce se numește de obicei impedanța de cartografiere obiect – relațională. Există deja o mulțime de cadre pentru a atenua această problemă. Există, de asemenea, și compromisuri. Unele lucruri vor fi mai ușoare, altele vor deveni mai complexe, dar în cazul general acestea funcționează bine dacă vă puteți permite stratul suplimentar.

În a doua parte, se pare că vă plângeți de faptul că SQL este text (folosește șiruri de caractere în loc de id-uri, etc.)… SQL este un limbaj de interogare. Orice limbaj (de calculator sau de altă natură) care este destinat să fie citit sau scris de oameni este orientat spre text. Assembly, C, PHP, oricare ar fi el. De ce? Pentru că, ei bine… are sens, nu-i așa?

Dacă doriți interogări precompilate, aveți deja proceduri stocate. Instrucțiunile pregătite sunt, de asemenea, compilate o singură dată, din mers, IIRC. Cele mai multe (dacă nu toate) driverele de baze de date vorbesc cu serverul de baze de date folosind oricum un protocol binar.

Comentarii

  • Am scris un comentariu mare la postarea ta și apoi l-am postat ca o editare. De fapt, nu mă plâng de SQL, ci mă întreb de ce avem nevoie de el – un limbaj suplimentar pentru interfața dintre OM și BAZA DE DATE, deoarece în majoritatea cazurilor avem nevoie de o interacțiune APLICAȚIE/ BAZA DE DATE. –  > Por martinthenext.
  • Nu există o interacțiune APLICAȚIE/ BAZĂ DE DATE fără implicarea unui om. Nu încă. –  > Por Lealo.
Keith Nicholas

da, textul este un pic ineficient. Dar obținerea efectivă a datelor este mult mai costisitoare, așa că sql-ul bazat pe text este rezonabil de nesemnificativ.

Powerlord

SQL a fost creat pentru a oferi o interfață care să permită efectuarea de interogări ad-hoc într-o bază de date relațională.

În general, majoritatea bazelor de date relaționale înțeleg o anumită formă de SQL.

Bazele de date orientate pe obiecte există și (probabil) folosesc obiecte pentru a face interogări… dar, din câte am înțeles, bazele de date OO au mult mai multe supraînțelesuri, iar bazele de date relaționale funcționează foarte bine.

Bazele de date relaționale vă permit, de asemenea, să operați într-o stare „deconectată”. Odată ce aveți informațiile pe care le-ați cerut, puteți închide conexiunea la baza de date. Cu o bază de date OO, trebuie fie să returnați toate obiectele legate de cel curent (și cele cu care sunt legate… și cele… etc…), fie să redeschideți conexiunea pentru a prelua noi obiecte pe măsură ce acestea sunt accesate.

În plus față de SQL, aveți și ORM-uri (object-relational mappings) care mapează obiectele în SQL și invers. Există câteva dintre acestea, inclusiv LINQ (.NET), MS Entity Framework (.NET), Hibernate (Java), SQLAlchemy (Python), ActiveRecord (Ruby), Class::DBI (Perl) etc…

nvogel

Un limbaj de baze de date este util pentru că oferă un model logic pentru datele dvs. independent de orice aplicații care îl utilizează. Cu toate acestea, SQL are o mulțime de neajunsuri, nu în ultimul rând integrarea sa cu alte limbaje este slabă, suportul pentru tipuri este cu aproximativ 30 de ani în urma restului industriei și, oricum, nu a fost niciodată un limbaj cu adevărat relațional.

SQL a supraviețuit mai ales pentru că piața bazelor de date a fost și rămâne dominată de cei trei mega-vânzători care au un interes personal în a-și proteja investiția. Acest lucru se schimbă, iar zilele lui SQL sunt probabil numărate, dar modelul care îl va înlocui în cele din urmă probabil că nu a apărut încă – deși există o mulțime de concurenți în aceste zile.

Comentarii

  • Ouch. „Modelul care îl va înlocui în cele din urmă” are sosit. În 1969/1970. Se numește modelul relațional al datelor 🙂 –  > Por Erwin Smout.
Nelson Rothermel

Nu cred că majoritatea oamenilor înțeleg întrebarea dumneavoastră, deși cred că este foarte clară. Din păcate, nu am răspunsul „corect”. Aș presupune că este o combinație de mai multe lucruri:

  1. Decizii semi-arbitrare atunci când a fost proiectat, cum ar fi ușurința de utilizare, faptul că nu este nevoie de un compilator SQL (sau IDE), portabilitatea etc.
  2. S-a întâmplat să prindă bine la public (probabil din motive similare)
  3. Și acum, din motive istorice (compatibilitate, bine cunoscut, dovedit etc.) continuă să fie utilizat.
  4. Nu cred că cele mai multe companii s-au deranjat cu o altă soluție pentru că funcționează bine, nu este un mare gât de gâtuială, este un standard, bla, bla….

Paul Nathan

Unul dintre principiile de proiectare Unix poate fi spus astfel: „Scrieți programe care să gestioneze fluxuri de text, deoarece aceasta este o interfață universală.”.

Și cred că acesta este motivul pentru care folosim de obicei SQL în loc de un „byte-SQL” care are doar o interfață de compilare. Chiar dacă noi am fi făcut-o avea un byte-SQL, cineva ar scrie un „Text SQL”, iar bucla ar fi completă.

De asemenea, MySQL și SQLite sunt mai puțin complete decât, să zicem, MSSQL și Oracle SQL. Așadar, vă aflați încă în partea inferioară a bazinului SQL.

Venkat Sadasivam

De fapt, există câteva produse de baze de date non-SQL (cum ar fi Objectivity, Oracle Berkeley DB etc.) au venit, dar niciunul dintre ele nu a avut succes. În viitor, dacă cineva găsește o alternativă intuitivă pentru SQL, asta va răspunde la întrebarea dumneavoastră.

Comentarii

  • În timp ce SQL este regele incontestabil al accesului la bazele de date, nu cred că se poate spune „niciunul dintre ele nu a reușit” despre Berkeley DB. Nu, nu este la fel de generalist ca o bază de date SQL tipică (este un magazin de valori cheie), dar are un succes nebunesc. A fost folosită în mii de aplicații timp de ani de zile și este încă folosită intensiv în multe locuri. –  > Por Christopher Cashell.
Jay

Există o mulțime de sisteme de baze de date nerelaționale. Iată doar câteva dintre ele:MemcachedTokyo Cabinet

Comentarii

  • Dar am nevoie ca baza mea de date să fie relațională! Doar că nu vreau să folosească SQL. –  > Por martinthenext.
  • Cu siguranță puteți folosi o bază de date nerelațională, dar să vă structurați datele în orice mod doriți. Totuși, nu va avea nicio integritate automată sau funcții de actualizare/eliminare în cascadă. –  > Por Jay.
J. Polfer

În ceea ce privește găsirea unei baze de date relaționale care să nu folosească SQL ca interfață principală, cred că nu veți găsi așa ceva. Motivul: SQL este o modalitate excelentă de a vorbi despre relații. Nu-mi dau seama de ce este o mare problemă pentru dumneavoastră: dacă nu vă place SQL, puneți o abstracțiune peste el (cum ar fi un ORM), astfel încât să nu trebuiască să vă faceți griji în privința lui. Lăsați abstracțiunea să se ocupe de asta. Ajungeți în același loc.

Cu toate acestea, problema pe care o aveți de fapt menționează aici este deconectarea obiect-relație – problema este cu relația în sine. Obiectele și tușele relaționale nu se pretează întotdeauna la o relație 1-1, motiv pentru care un dezvoltator poate fi frustrat de o bază de date. Soluția este de a utiliza un alt tip de bază de date.

Comentarii

  • Nu sunt de acord cu cea de-a doua propoziție. SQL este un mod cu adevărat jalnic de a „vorbi despre relații”! În atât de multe privințe, SQL nu reușește în totalitate să ofere ceea ce trebuia să ofere modelul relațional. –  > Por nvogel.
  • @David – Sugestii cu privire la o modalitate mai bună? –  > Por J. Polfer.
Patrick Honorez

Pentru că de multe ori, nu poți fi sigur că (citându-te) „nimeni nu a văzut vreodată după desfășurare”. Știind că există o interfață ușoară pentru raportare și pentru interogare la nivel de set de date este o cale bună pentru evoluția aplicației dumneavoastră.
Aveți dreptate, că există și alte soluții care pot fi valabile în anumite situații: XML, fișiere de text simplu, OODB…
Dar existența unui set de interfețe comune (cum ar fi ODBC) este un avantaj imens pentru viața datelor.

Lealo

Cred că motivul ar putea fi algoritmii de search/find/grab la care este conectat sql laungage-ul. Amintiți-vă că sql a fost dezvoltat timp de 40 de ani – și scopul a fost atât în ceea ce privește preformanța, cât și în ceea ce privește firescul utilizatorului.

Întrebați-vă care este cel mai bun mod de a găsi 2 atribute. Acum, de ce să investighezi de fiecare dată când vrei să faci ceva care să includă acest lucru de fiecare dată când îți dezvolți aplicația. Presupunând că obiectivul principal este dezvoltarea aplicației dumneavoastră atunci când dezvoltați o aplicație.

O aplicație are asemănări cu alte aplicații, o bază de date are asemănări cu alte baze de date. Prin urmare, ar trebui să existe un „cel mai bun mod” în care acestea să interacționeze, din punct de vedere logic.

De asemenea, întrebați-vă cum ați putea dezvolta o aplicație mai bună, doar pentru consolă, care să nu utilizeze laungage sql. Dacă nu puteți face acest lucru, cred că trebuie să dezvoltați un nou tip de interfață grafică, care să fie chiar mai ușor de utilizat în mod fundamental decât cu o consolă – pentru a dezvolta lucruri din ea. Iar acest lucru ar putea fi de fapt posibil. Dar, în continuare, cea mai mare parte a dezvoltării de aplicații se bazează pe consolă și pe tastare.

Apoi, când vine vorba de laungage, nu cred că se poate face un laungage de text mult mai simplu în mod fundamental decât sql. Și nu uitați că fiecare cuvânt din orice lucru este legat în mod inseparabil de înțelesul său – dacă eliminați înțelesul, cuvântul nu poate fi folosit – dacă eliminați cuvântul, nu puteți comunica înțelesul. Nu ai cu ce să-l descrii (și poate că nici nu poți să te gândești la el, pentru că nu ar fi conectat la nimic altceva la care te-ai gândit înainte…).

Deci, practic, cei mai buni algoritmi posibili pentru manipularea bazei de date sunt atribuiți cuvintelor – dacă îndepărtați aceste cuvinte, va trebui să atribuiți aceste manipulări cu totul altceva – și ce ar fi acela?

bomberdini

cred că puteți folosi ORM

dacă și numai dacă cunoști noțiunile de bază de sql.

altfel rezultatul acolo nu este cel mai bun