Dlaczego nie kochasz SQL? [Zamknięte]

Ostatnio dużo słyszałem, że SQL to okropny język i wydaje się, że każdy framework pod słońcem jest dostarczany z warstwą abstrakcji bazy danych.

Jednak z mojego doświadczenia wynika, że ​​SQL jest często znacznie łatwiejszym, bardziej wszechstronnym i bardziej przyjaznym dla programistów sposobem zarządzania wprowadzaniem i wyprowadzaniem danych. Każda warstwa abstrakcji, której użyłem, wydaje się być wyraźnie ograniczonym podejściem bez realnych korzyści.

Co sprawia, że ​​SQL jest tak straszny i dlaczego warstwy abstrakcji bazy danych są cenne?

Jest to częściowo subiektywne. Oto moja opinia:

SQL ma styl języka pseudo-naturalnego . Wynalazcy wierzyli, że mogą stworzyć język podobny do angielskiego i że zapytania do bazy danych będą bardzo proste. Okropny błąd. SQL jest bardzo trudny do zrozumienia, z wyjątkiem trywialnych przypadków.

SQL jest deklaratywny. Nie możesz powiedzieć bazie danych, jak powinna działać, tylko czego chcesz w rezultacie. Byłoby to doskonałe i bardzo potężne - gdybyś nie musiał przejmować się wydajnością. Więc kończysz na pisaniu SQL - czytaniu planów wykonania - przeformułowaniu SQL próbując wpłynąć na plan wykonania i zastanawiasz się, dlaczego nie możesz sam napisać planu wykonania .

Innym problemem języka deklaratywnego jest to, że niektóre problemy są łatwiejsze do rozwiązania w sposób imperatywny. Więc albo piszesz go w innym języku (będziesz potrzebować standardowego SQL i prawdopodobnie warstwy dostępu do danych) lub używając rozszerzeń językowych specyficznych dla dostawcy, na przykład pisząc procedury składowane i tym podobne. Robiąc to, prawdopodobnie okaże się, że używasz jednego z najgorszych języków, jakie kiedykolwiek widziałeś - ponieważ nigdy nie został zaprojektowany do używania jako języka imperatywnego.

SQL jest bardzo stary . SQL został ustandaryzowany, ale za późno, wielu dostawców już opracowało swoje rozszerzenia językowe. Więc SQL znalazł się w dziesiątkach dialektów. Dlatego aplikacje nie są przenośne i jest jednym z powodów, dla których warto mieć warstwę abstrakcji DB.

Ale to prawda - nie ma wykonalnych alternatyw. Więc wszyscy będziemy używać SQL przez kilka następnych lat.

Oprócz wszystkiego, co zostało powiedziane, technologia nie musi być zła, aby warstwa abstrakcji stała się wartościowa .

Jeśli robisz bardzo prosty skrypt lub aplikację, możesz sobie pozwolić na mieszanie wywołań SQL w swoim kodzie, gdziekolwiek chcesz. Jeśli jednak wykonujesz złożony system, izolowanie wywołań bazy danych w oddzielnych modułach jest dobrą praktyką, a więc jest to izolowanie kodu SQL. Poprawia czytelność kodu, łatwość utrzymania i testowalność. Pozwala szybko dostosować system do zmian w modelu bazy danych bez zrywania wszystkich rzeczy wysokiego poziomu itp.

SQL jest świetny. Warstwy abstrakcji na nim sprawiają, że jest jeszcze większy!

Jednym z punktów warstwy abstrakcji jest fakt, że implementacje SQL są ze sobą mniej lub bardziej niekompatybilne, ponieważ standard jest nieco niejednoznaczny, a także dlatego, że większość dostawców dodała tam swoje własne (niestandardowe) dodatki. Oznacza to, że SQL napisany dla bazy danych MySQL może nie działać w podobny sposób z, powiedzmy, bazą danych Oracle - nawet jeśli „powinien”.

Zgadzam się jednak, że SQL jest o wiele lepszy niż większość dostępnych warstw abstrakcji. To nie wina SQL, że jest używany do rzeczy, do których nie został zaprojektowany.

SQL jest wypowiadany z kilku źródeł:

• Programiści, którym nie przeszkadza nic poza językiem imperatywnym.
• Konsultanci, którzy na co dzień mają do czynienia z wieloma niekompatybilnymi produktami opartymi na SQL
• Sprzedawcy nierelacyjnych baz danych próbują przełamać uścisk sprzedawców relacyjnych baz danych na rynku
• Eksperci zajmujący się relacyjnymi bazami danych, tacy jak Chris Date, uważają, że obecne implementacje SQL są niewystarczające

Jeśli trzymasz się jednego produktu DBMS, to zdecydowanie zgadzam się, że bazy danych SQL są bardziej wszechstronne i lepszej jakości niż ich konkurencja, przynajmniej do momentu, gdy napotkasz barierę skalowalności tkwiącą w modelu. Ale czy naprawdę próbujesz napisać następny Twitter, czy po prostu próbujesz uporządkować i spójnie niektóre dane księgowe?

Krytyka SQL często oznacza krytykę systemów RDBMS. Krytycy RDBMS zdają się nie rozumieć, że całkiem dobrze rozwiązują one ogromną klasę problemów komputerowych i że są tutaj, aby ułatwić nam życie, a nie utrudnić.

Gdyby poważnie podchodziło do krytykowania samego SQL, poparliby takie wysiłki jak Tutorial D i Dataphor.

To nie jest takie straszne. To niefortunny trend w tej branży, aby wyrzucić poprzednią niezawodną technologię, gdy pojawia się nowy „paradygmat”. Pod koniec dnia te frameworki najprawdopodobniej używają SQL do komunikacji z bazą danych, więc jak to może być TAK złe? To powiedziawszy, posiadanie „standardowej” warstwy abstrakcji oznacza, że ​​programista może skupić się na kodzie aplikacji, a nie na kodzie SQL. Bez takiej standardowej warstwy prawdopodobnie napisałbyś mniejszą warstwę za każdym razem, gdy tworzysz system, co jest stratą czasu.

SQL jest przeznaczony do zarządzania i zapytań o dane oparte na SET. Często jest używany do robienia więcej, a skrajne przypadki czasami prowadzą do frustracji.

Na rzeczywiste UŻYCIE SQL może wpływać tak duży wpływ na projekt bazy danych, że SQL może nie być problemem, ale projekt może - a kiedy wrzucisz starszy kod związany ze złym projektem, zmiany są bardziej wpływowe i kosztowne do wdrożenia ( nikt nie lubi wracać i „naprawiać” rzeczy, które „działają” i osiągają cele)

Stolarze mogą wbijać gwoździe młotkami, piłować tarcicę piłami i wygładzać deski strugami. MOŻNA „piłować” młotami i samolocikami, ale jest to frustrujące.

Nie powiem, że to straszne. Nie nadaje się do niektórych zadań. Na przykład: nie można napisać dobrego kodu proceduralnego za pomocą SQL. Kiedyś zmuszono mnie do pracy z manipulowaniem zbiorami w języku SQL. Zrozumienie tego zajęło mi cały weekend.

SQL został zaprojektowany z myślą o algebrze relacyjnej - właśnie tam powinien być używany.

Ostatnio dużo słyszałem, że SQL to okropny język i wydaje się, że każdy framework pod słońcem jest dostarczany z warstwą abstrakcji bazy danych.

Zwróć uwagę, że te warstwy po prostu konwertują własne pliki na SQL. W przypadku większości dostawców baz danych SQLjest to jedyny sposób komunikacji z silnikiem.

Jednak z mojego doświadczenia wynika, że ​​SQL jest często znacznie łatwiejszym, bardziej wszechstronnym i bardziej przyjaznym dla programistów sposobem zarządzania wprowadzaniem i wyprowadzaniem danych. Każda warstwa abstrakcji, której użyłem, wydaje się być wyraźnie ograniczonym podejściem bez realnych korzyści.

… Powód, dla którego właśnie opisałem powyżej.

Warstwy bazy danych niczego nie dodają , po prostu Cię ograniczają . Sprawiają, że zapytania są bezsprzecznie prostsze, ale nigdy nie są bardziej wydajne.

Z definicji w warstwach bazy danych nie ma niczego, czego nie ma SQL.

Co sprawia SQL, że są tak straszne i dlaczego warstwy abstrakcji bazy danych są cenne?

SQL jest fajnym językiem, jednak praca z nim wymaga trochę szaleństwa.

W teorii, SQL jest deklaratywna, czyli deklarujesz, co chcesz dostać, a silnik zapewnia to w najszybszy możliwy sposób.

W praktyce istnieje wiele sposobów sformułowania poprawnego zapytania (czyli zapytania, które zwraca poprawne wyniki).

Optymalizatory są w stanie zbudować zamek Lego z niektórych predefiniowanych algorytmów (tak, jest ich wiele), ale po prostu nie mogą tworzyć nowych algorytmów. Nadal potrzeba pomocy SQLprogramisty.

Jednak niektórzy ludzie oczekują, że optymalizator utworzy „najlepszy możliwy plan”, a nie „najlepszy plan dostępny dla tego zapytania przy danej implementacji SQLsilnika”.

A jak wszyscy wiemy, kiedy program komputerowy nie spełnia oczekiwań ludzi, wini się program, a nie oczekiwania.

Jednak w większości przypadków przeformułowanie zapytania może dać najlepszy możliwy plan. Są jednak zadania, w przypadku których jest to niemożliwe dzięki nowym i stale rozwijającym się ulepszeniomSQL tych przypadków liczba jest coraz mniejsza.

Byłoby jednak miło, gdyby dostawcy zapewnili niski poziom dostępu do funkcji, takich jak „pobierz zakres indeksu”, „pobierz wiersz za rowid” itd., Tak jak Ckompilatory pozwalają na osadzenie asemblera bezpośrednio w języku.

Niedawno napisałem artykuł na ten temat na moim blogu:

• Podwójne myślenie w SQL

Jestem wielkim orędownikiem ORM i nadal uważam, że SQL jest bardzo przydatny, chociaż z pewnością można z nim zrobić straszne rzeczy (jak wszystko inne). .

Postrzegam SQL jako superwydajny język, który nie ma priorytetów w zakresie ponownego wykorzystywania kodu ani łatwości konserwacji / refaktoryzacji.

Dlatego priorytetem jest błyskawiczne przetwarzanie. I to jest do zaakceptowania. Musisz tylko zdawać sobie sprawę z kompromisów, które dla mnie są znaczne.

Z estetycznego punktu widzenia, jako język czuję, że brakuje mu pewnych rzeczy, ponieważ nie ma on koncepcji OO i tak dalej - wydaje mi się, że jest to bardzo oldschoolowy kod proceduralny. Ale to zdecydowanie najszybszy sposób na zrobienie pewnych rzeczy, a to potężna nisza!

Powiedziałbym, że warstwa abstrakcji bazy danych zawarta we frameworku to dobra rzecz, ponieważ rozwiązuje dwa bardzo ważne problemy:

1. Dzięki temu kod jest odrębny. Umieszczając SQL w innej warstwie, która jest ogólnie bardzo cienka i powinna zajmować się tylko podstawowymi zapytaniami i przekazywaniem wyników (w standardowy sposób), utrzymujesz swoją aplikację wolną od bałaganu SQL. Z tego samego powodu twórcy stron internetowych (powinni) umieszczać CSS i Javascript w osobnych plikach. Jeśli możesz tego uniknąć, nie mieszaj swoich języków .

2. Wielu programistów po prostu źle radzi sobie z używaniem SQL. Z jakiegoś powodu duża liczba programistów (zwłaszcza twórców stron internetowych) wydaje się bardzo, bardzo źle radzić sobie z używaniem SQL lub ogólnie systemów RDBMS. Traktują bazę danych (i SQL przez rozszerzenie) jak brudnego małego pośrednika, przez który muszą przejść, aby dostać się do danych. Prowadzi to do wyjątkowo słabo przemyślanych baz danych bez indeksów, tabel ułożonych na górze tabel w wątpliwy sposób i bardzo źle napisanych zapytań. Lub, co gorsza, starają się być zbyt ogólni (system ekspercki, ktoś?) I nie mogą rozsądnie powiązać danych w żaden znaczący sposób.

Niestety, czasami sposób, w jaki ktoś próbuje rozwiązać problem i używane przez niego narzędzia, czy to z powodu ignorancji, uporu czy innej cechy, stoją w bezpośredniej opozycji i powodzenia w przekonywaniu go do tego. W związku z tym, oprócz tego, że jest dobrą praktyką, uważam, że warstwa abstrakcji bazy danych jest rodzajem siatki bezpieczeństwa, ponieważ nie tylko chroni SQL przed oczami biednego programisty, ale także znacznie ułatwia refaktoryzację kodu, ponieważ wszystkie zapytania są w jednym miejscu.

SQL doskonale nadaje się do niektórych rodzajów zadań, zwłaszcza do manipulowania i pobierania zestawów danych.

Jednak w SQL brakuje (lub implementuje tylko częściowo) kilka ważnych narzędzi do zarządzania zmianami i złożonością:

• Hermetyzacja : mechanizmy hermetyzacji w SQL są zgrubne. Pisząc kod SQL, musisz wiedzieć wszystko o implementacji Twoich danych. Ogranicza to ilość abstrakcji, jaką możesz osiągnąć.

• Polimorfizm : jeśli chcesz wykonać tę samą operację na różnych tabelach, musisz dwukrotnie napisać kod. (Można to złagodzić, używając wyobraźni poglądów).

• Kontrola widoczności : nie ma standardowego mechanizmu SQL do ukrywania fragmentów kodu przed sobą lub grupowania ich w logiczne jednostki, dzięki czemu każda tabela, procedura itp. Jest dostępna z każdej innej, nawet jeśli jest to niepożądane.

• Modułowość i wersjonowanie

Wreszcie, ręczne kodowanie operacji CRUD w języku SQL (i pisanie kodu w celu połączenia go z resztą aplikacji) jest powtarzalne i podatne na błędy.

Nowoczesna warstwa abstrakcji zapewnia wszystkie te funkcje i pozwala nam używać SQL tam, gdzie jest to najbardziej efektywne, jednocześnie ukrywając uciążliwe, powtarzalne szczegóły implementacji. Dostarcza narzędzi pomagających przezwyciężyć niezgodność impedancji obiektowo-relacyjnej, która komplikuje dostęp do danych w programowaniu zorientowanym obiektowo.

SQL jest oparty na teorii zbiorów, podczas gdy większość języków wysokiego poziomu jest obecnie zorientowana obiektowo. Programiści obiektowi zazwyczaj lubią myśleć obiektami i muszą dokonać zmiany mentalnej, aby używać narzędzi opartych na Zbiorach do przechowywania swoich obiektów. Ogólnie rzecz biorąc, jest znacznie bardziej naturalne (dla programisty OO) po prostu wyciąć kod w wybranym przez siebie języku i zrobić coś takiego jak object.save lub object. Usunąć w kodzie aplikacji, zamiast pisać zapytania sql i wywoływać bazę danych w celu osiągnięcia ten sam wynik.

Oczywiście, czasami w przypadku złożonych rzeczy, SQL jest łatwiejszy w użyciu i bardziej wydajny, dlatego dobrze jest mieć kontrolę nad obydwoma typami technologii.

IMO, problem, jaki widzę ludzie z SQL, nie ma nic wspólnego z projektowaniem relacyjnym ani z samym językiem SQL. Ma to związek z dyscypliną modelowania warstwy danych, która pod wieloma względami zasadniczo różni się od modelowania warstwy biznesowej lub interfejsu. Błędy w modelowaniu na warstwie prezentacji są generalnie dużo łatwiejsze do naprawienia niż na warstwie danych, gdzie wiele aplikacji korzysta z bazy danych. Te problemy są takie same, jak te napotykane podczas modelowania warstwy usług w projektach SOA, w których należy uwzględnić obecnych odbiorców usługi oraz umowy wejścia i wyjścia.

SQL został zaprojektowany do interakcji z modelami relacyjnych baz danych. Istnieją inne modele danych, które istnieją od jakiegoś czasu, ale dyscyplina dotycząca prawidłowego projektowania warstwy danych istnieje niezależnie od zastosowanego modelu teoretycznego, a zatem trudności, jakie programiści mają zwykle z SQL, są zwykle związane z próbami narzucenia nierelacyjnego model danych na produkt relacyjnej bazy danych.

Po pierwsze, sprawiają, że korzystanie z zapytań parametrycznych jest trywialne, chroniąc cię przed atakami iniekcji SQL. Z tego punktu widzenia używanie surowego języka SQL jest bardziej ryzykowne, co oznacza, że ​​z punktu widzenia bezpieczeństwa łatwiej jest popełnić błąd. Często przedstawiają również zorientowaną obiektowo perspektywę w Twojej bazie danych, zwalniając Cię z konieczności wykonywania tego tłumaczenia.

Dużo ostatnio słyszałeś? Mam nadzieję, że nie mylisz tego z ruchem NoSql. O ile wiem, jest to głównie grupa ludzi, którzy używają NoSql w aplikacjach internetowych o wysokiej skalowalności i najwyraźniej zapomnieli, że SQL jest skutecznym narzędziem w scenariuszu innym niż „aplikacja internetowa o dużej skalowalności”.

W biznesie warstwy abstrakcji chodzi po prostu o uporządkowanie różnicy między kodem zorientowanym obiektowo a kodem opartym na tabelach, takim jak SQL lubi mówić. Zwykle powoduje to pisanie dużej ilości kotłów i tępego kodu przejścia między nimi. ORM automatyzuje to, a tym samym oszczędza czas ludzi obiektywnych biznesowo.

Dla doświadczonego programisty SQL są złe strony

• Gadatliwość
• Jak wielu tutaj powiedziało, SQL jest deklaratywny, co oznacza, że optymalizacja nie jest bezpośrednia . To jak wyścigi w porównaniu do wyścigów torowych.
• Struktury, które próbują zaadresować wszystkie możliwe dialekty i nie obsługują skrótów żadnego z nich
• Brak łatwej kontroli wersji.

Dla innych powody są takie

• niektórzy programiści źle znają SQL. Prawdopodobnie dlatego, że SQL operuje zbiorami, podczas gdy języki programowania działają w paradygmacie obiektowym lub funkcjonalnym. Myślenie zbiorami (związek, produkt, przecięcie) jest kwestią przyzwyczajenia, którego niektórzy ludzie nie mają.
• niektóre operacje nie są oczywiste: to znaczy na początku nie jest jasne, gdzie i posiadające filtry różnych zestawów.
• jest zbyt wiele dialektów

Podstawowym celem frameworków SQL jest ograniczenie pisania. Jakoś to robią, ale zbyt często tylko w przypadku bardzo prostych zapytań. Jeśli spróbujesz zrobić coś złożonego, musisz użyć ciągów znaków i dużo pisać. Struktury, które próbują obsłużyć wszystko, co możliwe, takie jak SQL Alchemy, stają się zbyt duże, jak inny język programowania.

[aktualizacja 26.06.10] Ostatnio pracowałem z modułem Django ORM . To jedyna godna platforma SQL, jaką widziałem. A ten sprawia, że ​​dużo się z nimi pracuje. Złożone kruszywa są jednak nieco trudniejsze.

SQL nie jest okropnym językiem, po prostu czasami nie współgra zbyt dobrze z innymi.

Jeśli na przykład masz system, który chce przedstawić wszystkie jednostki jako obiekty w jakimś języku OO lub innym, to połączenie tego z SQL bez jakiejkolwiek warstwy abstrakcji może stać się dość kłopotliwe. Nie ma łatwego sposobu na zmapowanie złożonego zapytania SQL na świat OO. Aby złagodzić napięcie między tymi światami, wstawiono dodatkowe warstwy abstrakcji (na przykład OR-Mapper).

SQL to naprawdę dobry język do manipulacji danymi. Z punktu widzenia programisty nie podoba mi się to, że zmiana bazy danych nie powoduje zepsucia kodu w czasie kompilacji ... Więc używam abstrakcji, która dodaje tę funkcję ceną wydajności i być może ekspresyjności języka SQL , ponieważ w większości aplikacji nie potrzebujesz wszystkiego, co ma SQL.

Innym powodem, dla którego SQL jest znienawidzony, są relacyjne bazy danych.

CAP Twierdzenie staje się popularne:

Jakie cele możesz chcieć od systemu współdzielonych danych?

• Silna spójność: wszyscy klienci widzą ten sam widok, nawet w obecności aktualizacji
• Wysoka dostępność: wszyscy klienci mogą znaleźć repliki danych, nawet w przypadku awarii
• Tolerancja partycji: właściwości systemu są zachowane nawet wtedy, gdy system jest podzielony na partycje

Twierdzenie stwierdza, że ​​zawsze możesz mieć tylko dwie z trzech właściwości CAP w tym samym czasie

Relacyjna baza danych adresuje silną spójność i tolerancję partycji.

Dlatego coraz więcej osób zdaje sobie sprawę, że relacyjna baza danych nie jest srebrną kulą, a coraz więcej osób zaczyna ją odrzucać na rzecz wysokiej dostępności, ponieważ wysoka dostępność ułatwia skalowanie poziome. Skalowanie poziome zyskuje na popularności, ponieważ osiągnęliśmy granicę prawa Moore'a , więc najlepszym sposobem skalowania jest dodanie większej liczby maszyn.

Jeśli relacyjna baza danych zostanie odrzucona, odrzucony zostanie również SQL.

SQL ma wiele błędów, na co zwracają uwagę niektóre inne posty. Mimo to zdecydowanie wolę używać języka SQL zamiast wielu narzędzi, które ludzie oferują jako alternatywy, ponieważ „uproszczenia” są często bardziej skomplikowane niż to, co miały uprościć.

Moja teoria jest taka, że ​​SQL został wynaleziony przez bandę niebieskich narciarzy z wieżami z kości słoniowej. Cała struktura nieproceduralna. Brzmi świetnie: powiedz mi, czego chcesz, a nie jak chcesz to zrobić. Ale w praktyce często łatwiej jest po prostu podać kroki. Często wydaje się, że próbujesz udzielić instrukcji dotyczących konserwacji samochodu, opisując, jak samochód powinien działać po zakończeniu. Tak, możesz powiedzieć: „Chcę, aby samochód ponownie przejechał 30 mil na galon i jechał z takim brzęczącym dźwiękiem… hmmmm… i itd.” Ale czy nie byłoby łatwiej dla każdego po prostu powiedzieć „Wymień świece zapłonowe”? A nawet jeśli dowiesz się, jak wyrazić złożone zapytanie w terminach nieproceduralnych, silnik bazy danych często opracowuje bardzo nieefektywny plan wykonania, aby to osiągnąć.

A obsługa zer doprowadza mnie do szału! Tak, teoretycznie musiało zabrzmieć świetnie, gdy ktoś powiedział: „Hej, jeśli null oznacza nieznane, to dodanie nieznanej wartości do znanej wartości powinno dać nieznaną wartość. W końcu z definicji nie mamy pojęcia, czym jest nieznana wartość . ” Teoretycznie absolutnie prawdziwe. W praktyce, jeśli mamy 10 000 klientów i wiemy dokładnie, ile pieniędzy jest nam winnych 9 999, ale pojawia się pytanie o kwotę zadłużenia tego ostatniego, a kierownictwo mówi: „Jakie są nasze łączne należności?”, Tak, matematycznie poprawne odpowiedź brzmi „nie wiem”. Ale praktyczna odpowiedź brzmi: „obliczamy 4 327 287,42 dolarów, ale chodzi o jedno konto, więc ta liczba nie jest dokładna”. Jestem pewien, że kierownictwo wolałoby raczej zbliżyć się, jeśli nie określoną liczbę, niż puste spojrzenie.

Wszystko to powiedziawszy, nadal wolę używać SQL niż jakiejś warstwy zbudowanej na SQL, która po prostu tworzy kolejny cały zestaw rzeczy, których muszę się nauczyć, a potem muszę wiedzieć, że ostatecznie zostanie to przetłumaczone na SQL, a czasami Mogę po prostu zaufać temu, że wykonam tłumaczenie poprawnie i wydajnie, ale kiedy sprawy stają się skomplikowane, nie mogę, więc teraz muszę znać dodatkową warstwę, nadal muszę znać SQL i muszę wiedzieć, jak to przetłumaczy mogę oszukać warstwę, by skłoniła SQL do zrobienia właściwej rzeczy. Arggh.

• Każdy dostawca rozszerza składnię SQL w zależności od swoich potrzeb. Więc jeśli nie robisz dość prostych rzeczy, twój kod SQL nie jest przenośny.

• Składnia SQL nie jest ortogonalna; np. wszystkie instrukcje select, insert, update,i deletemają zupełnie inną strukturę składniową.

Zgadzam się z twoimi punktami, ale odpowiadając na twoje pytanie, jedną rzeczą, która sprawia, że ​​SQL jest tak „okropny”, jest brak pełnej standaryzacji T-SQL między dostawcami baz danych (Sql Server, Oracle itp.), Co sprawia, że ​​kod SQL jest mało prawdopodobny całkowicie przenośny. Warstwy abstrakcji bazy danych rozwiązują ten problem, chociaż wiąże się to z kosztami wydajności (czasami bardzo poważnymi).

Życie z czystym SQL może być naprawdę piekłem utrzymania. Dla mnie największą zaletą ORMów jest możliwość bezpiecznej refaktoryzacji kodu bez żmudnych procedur „refaktoryzacji DB”. Istnieją dobre frameworki do testowania jednostkowego i narzędzia do refaktoryzacji dla języków OO, ale nie widzę jeszcze na przykład odpowiednika Resharpera dla SQL.

Wciąż wszystkie DAL mają SQL za kulisami i nadal musisz go znać, aby zrozumieć, co dzieje się z twoją bazą danych, ale codzienna praca z dobrą warstwą abstrakcji staje się łatwiejsza.

Jeśli nie korzystałeś zbyt często z SQL, myślę, że głównym problemem jest brak dobrych narzędzi programistycznych.

Jeśli masz duże doświadczenie z SQL, w pewnym momencie będziesz sfrustrowany brakiem kontroli nad planem wykonania. Jest to nieodłączny problem związany ze sposobem, w jaki SQL został określony dostawcom. Myślę, że SQL musi stać się solidniejszym językiem, aby naprawdę wykorzystać podstawową technologię (która jest bardzo potężna).

Szybko, napisz mi SQL, aby podzielić zbiór danych, który działa w MySQL, Oracle, MSSQL, PostgreSQL i DB2.

Och, tak, standardowy SQL nie definiuje żadnych operatorów ograniczających liczbę wyników i wiersz, od którego należy zacząć.

Nie ma miłości do SQL, ponieważ SQL jest zły pod względem składni, semantyki i obecnego użycia. Wytłumaczę:

• jego składnia to kobolski szrapnel, cała krytyka koboli ma tutaj zastosowanie (w mniejszym stopniu, żeby być uczciwym). Próba bycia językiem naturalnym bez faktycznej próby interpretacji języka naturalnego tworzy arbitralną składnię (czy jest to DROP TABLE czy DROP, UPDATE TABLE, UPDATE lub UPDATE IN, DELETE lub DELETE FROM ...) i potworności składniowe, takie jak SELECT (ile stron ma to wypełnia?)
• semantyka jest również głęboko wadliwa, Date wyjaśnia to bardzo szczegółowo, ale wystarczy zauważyć, że trójwartościowa logika boolowska nie pasuje do algebry relacyjnej, w której wiersz może być tylko częścią tabeli lub nie
• posiadanie języka programowania jako głównego (i często jedynego) interfejsu do baz danych okazało się bardzo złym wyborem i stworzyło nową kategorię luk w zabezpieczeniach

Zgadzam się z większością postów tutaj, że debata na temat użyteczności SQL jest w większości subiektywna, ale myślę, że jest bardziej subiektywna w naturze Twoich potrzeb biznesowych.

Języki deklaratywne, jak wskazał Stefan Steinegger, są dobre do określania tego, czego chcesz, a nie jak chcesz to zrobić. Oznacza to, że Twoje różne implementacje SQL są przyzwoite z wysokiego poziomu: to znaczy, jeśli chcesz tylko uzyskać jakieś dane i nic więcej nie ma znaczenia, możesz zadowolić się pisaniem stosunkowo prostych zapytań i wyborem implementacji SQL to jest właśnie dla Ciebie.

Jeśli pracujesz na znacznie „niższym” poziomie i musisz to wszystko zoptymalizować samodzielnie, jest to dalekie od ideału. Użycie dodatkowej warstwy abstrakcji może pomóc, ale jeśli tak naprawdę próbujesz określić metody optymalizacji zapytań itp., Dodanie pośrednika podczas optymalizacji jest trochę sprzeczne z intuicją.

Największy problem, jaki mam z SQL, jest taki, jak w przypadku innych „ustandaryzowanych” języków, istnieje bardzo niewiele prawdziwych standardów. Prawie wolałbym nauczyć się zupełnie nowego języka między Sybase i MySQL, aby nie pomylić tych dwóch konwencji.

Chociaż SQL wykonuje swoje zadanie, z pewnością ma problemy ...

• stara się być jednocześnie abstrakcją wysokiego i niskiego poziomu , i to jest ... dziwne. Być może powinny to być dwa lub więcej standardów na różnych poziomach.
• standardowo jest to ogromna porażka . Wiele rzeczy idzie nie tak, gdy norma albo się we wszystkim porusza, wymaga zbyt wielu wdrożeń, żąda za mało lub z jakiegoś powodu nie osiąga częściowo społecznego celu, jakim jest motywowanie dostawców i wykonawców do tworzenia ściśle zgodnych, interoperacyjnych, kompletnych wdrożeń. Z pewnością nie można powiedzieć, że SQL to zrobił. Spójrz na inne standardy i zauważ, że sukces lub porażka standardu jest wyraźnie czynnikiem osiągniętej pożytecznej współpracy:
  • RS-232 ( zły , niewystarczająco określony, nawet, który pin przesyła, a który odbiera, jest opcjonalny. Możesz się zgodzić, ale nadal nic nie osiągniesz. Szansa na udaną współpracę: bardzo mała, dopóki IBM PC nie stworzył de facto użytecznego standardu .)
  • IEEE 754-1985 Floating Point ( Zły , przesadzony zasięg : ani jeden superkomputer, stacja robocza ani mikroprocesor RISC nigdy go nie przyjęły, chociaż w końcu po 20 latach byliśmy w stanie ładnie zaimplementować to w HW. Przynajmniej świat w końcu do niego wyrósł).
  • C89, C99, PCI, USB, Java ( dobry , czy to standard, czy specyfikacja, udało im się zmotywować ścisłe przestrzeganie przez prawie wszystkich, a zgodność ta zaowocowała udaną współpracą).
• nie został wybrany do prawdopodobnie najważniejszej bazy danych na świecie . Chociaż jest to bardziej punkt danych niż powód, fakt, że Google Bigtable nie jest SQL i nie jest relacyjny, jest pewnego rodzaju anty-osiągnięciem dla SQL.

Nie lubię SQL, ale nie chcę też pisać go w ramach tego, co rozwijam. W DAL nie chodzi o szybkość wprowadzania na rynek - właściwie nigdy nie sądziłem, że będzie implementacja DAL, która byłaby szybsza niż bezpośrednie zapytania z kodu. Ale celem DAL jest abstrakcja . Abstrakcja ma swoją cenę, a tutaj jej wdrożenie zajmie więcej czasu.

Korzyści są jednak ogromne. Pisanie natywnych testów wokół kodu, używanie klas ekspresyjnych, silnie typizowanych zestawów danych itp. Używamy pewnego rodzaju „DAL”, który jest czystą implementacją DDD używającą Generics w C #. Mamy więc repozytoria generyczne, implementacje jednostek pracy (transakcje oparte na kodzie) i separację logiczną. Możemy robić takie rzeczy, jak makiety naszych zestawów danych przy niewielkim wysiłku i faktycznie opracowywać przed wdrożeniami baz danych. Zbudowanie takiej struktury wiązało się z początkowymi kosztami, ale to bardzo fajne, że logika biznesowa znów jest gwiazdą programu. Obecnie konsumujemy dane jako zasoby i obsługujemy je w języku, którego używamy w kodzie. Dodatkową zaletą tego podejścia jest wyraźne oddzielenie, które zapewnia. Na przykład nie widzę już zapytania do bazy danych na stronie internetowej. Tak, ta strona potrzebuje danych. Tak, dotyczy to bazy danych. Ale teraz, bez względu na to, skąd pobieram dane, istnieje jedno (i tylko jedno) miejsce, w którym można przejść do kodu i go znaleźć. Może nie jest to wielka sprawa w przypadku mniejszych projektów, ale jeśli masz setki stron w witrynie lub dziesiątki okien w aplikacji komputerowej, naprawdę możesz to docenić.

Jako programista zostałem zatrudniony do wdrażania wymagań biznesowych przy użyciu moich umiejętności logicznych i analitycznych - a nasze wdrożenie frameworka pozwala mi teraz być bardziej produktywnym. Jako menedżer wolałbym, aby moi programiści używali swoich umiejętności logicznych i analitycznych do rozwiązywania problemów niż do pisania SQL. Fakt, że możemy zbudować całą aplikację, która korzysta z bazy danych, bez posiadania bazy danych aż do końca cyklu rozwojowego, to piękna rzecz. Nie ma to na celu uderzenia w specjalistów ds. Baz danych. Czasami implementacja bazy danych jest bardziej złożona niż rozwiązanie. SQL (aw naszym przypadku widoki i procesy przechowywane) to punkt abstrakcji, w którym kod może wykorzystywać dane jako usługę. W sklepach, w których istnieje wyraźna separacja między zespołami danych i programistów, pomaga to wyeliminować konieczność oczekiwania na implementację i zmiany bazy danych we wzorcu wstrzymania. Programiści mogą skupić się na domenie, w której występuje problem, bez najeżdżania kursorem na DBA, a DBA może skupić się na prawidłowej implementacji, bez potrzeby jej programistyteraz .

Wiele postów wydaje się argumentować, że SQL jest zły, ponieważ nie ma funkcji „optymalizacji kodu” i nie masz kontroli nad planami wykonania.

To, w czym silniki SQL są dobre, to wymyślanie planu wykonania pisemnej instrukcji, ukierunkowanej na dane , rzeczywistą zawartość . Jeśli chcesz spojrzeć poza stronę programowania, zobaczysz, że dane to nie tylko bajty przekazywane między warstwami aplikacji.