Jakie są dobre alternatywy dla SQL (języka)? [Zamknięte]

Czasami słyszę rzeczy o tym, jak SQL jest do bani i nie jest to dobry język, ale tak naprawdę nigdy nie słyszę zbyt wiele o jego alternatywach. Czy więc inne dobre języki służą temu samemu celowi (dostęp do bazy danych) i co sprawia, że ​​są lepsze niż SQL? Czy są jakieś dobre bazy danych, które używają tego alternatywnego języka?

EDYCJA: Znam SQL i używam go cały czas. Nie mam z tym problemu, interesują mnie tylko alternatywy, które mogą istnieć i dlaczego ludzie bardziej je lubią.

Nie szukam też alternatywnych rodzajów baz danych (ruch NoSQL), tylko różne sposoby dostępu do baz danych.

Z pewnością zgadzam się, że składnia SQL jest trudna w obsłudze, zarówno z punktu widzenia jej automatycznego generowania, jak i z punktu widzenia jej przetwarzania, i nie jest to styl języka, który napisalibyśmy dzisiaj, gdybyśmy projektowali SQL pod kątem wymagań, które stawiamy na to dzisiaj. Nie sądzę, abyśmy znaleźli tak wiele różnych słów kluczowych, gdybyśmy dzisiaj zaprojektowali język, podejrzewam, że składnia złączeń byłaby inna, funkcje takie jak GROUP_CONCATmiałyby bardziej regularną składnię, zamiast umieszczać więcej słów kluczowych w środku nawiasów, aby kontrolować ich zachowanie ... stwórz własną listę niespójności i nadmiarowości w SQL, które chciałbyś / spodziewałbyś się wygładzić, gdybyśmy dzisiaj przeprojektowali język.

Nie ma żadnej alternatywy dla SQL, aby mówić do relacyjnych baz danych (np. SQL jako protokół), ale istnieje wiele alternatyw dla pisania SQL w twoich aplikacjach. Te alternatywy zostały zaimplementowane w postaci frontendów do pracy z relacyjnymi bazami danych. Oto kilka przykładów frontendu:

• SchemeQL i CLSQL , które są prawdopodobnie najbardziej elastyczne dzięki swojemu dziedzictwu Lisp, ale również wyglądają bardziej jak SQL niż inne frontendy.
• LINQ (w .Net)
• ScalaQL i ScalaQuery (w Scali)
• SqlStatement , ActiveRecord i wiele innych w Rubim,
• HaskellDB
• ... lista jest długa dla wielu innych języków.

Myślę, że dzisiaj głównym motywem jest to, że zamiast zastępować SQL jednym nowym językiem zapytań, zamiast tego tworzymy interfejsy specyficzne dla języka, aby ukryć SQL w naszych zwykłych, codziennych językach programowania i traktujemy SQL jako protokół do komunikacji z relacyjnym bazy danych.

Spójrz na tę listę.

Hibernate Query Language jest prawdopodobnie najpopularniejszym. Zaletą Hibernate jest to, że obiekty bardzo łatwo (prawie automatycznie) mapują się do relacyjnej bazy danych, a programista nie musi poświęcać dużo czasu na projektowanie bazy danych. Sprawdź witrynę Hibernate, aby uzyskać więcej informacji. Jestem pewien, że inni będą dzwonić z innymi interesującymi językami zapytań ...

Oczywiście jest wiele rzeczy związanych z NoSQL, ale wyraźnie wspomniałeś, że nie jesteś nimi zainteresowany.

„Czasami słyszę, jak SQL jest do bani i nie jest to dobry język”

SQL ma ponad trzydzieści lat. Spostrzeżenia dotyczące tego, „które cechy sprawiają, że coś jest„ dobrym ”językiem, a które czynią go„ złym ”” rozwinęły się szybciej niż sam SQL.

Ponadto SQL nie jest językiem zgodnym z aktualnymi standardami „tego, co jest relacyjne”, więc SQL po prostu nie jest językiem relacyjnym do rozruchu.

„ale nigdy tak naprawdę nie słyszałem zbyt wiele o alternatywach”.

Zapraszam do rozważenia możliwości, że próbujesz słyszeć tylko w niewłaściwych miejscach (czyli wyłącznie w komercyjnej branży DBMS).

„Czy zatem inne dobre języki służą temu samemu celowi (dostęp do bazy danych) i co sprawia, że ​​są lepsze niż SQL?”

Date & Darwen opisują cechy, które musi spełniać współczesny język manipulacji danymi w ich „Trzecim Manifeście”, którego najnowsza wersja jest przedstawiona w ich książce „Bazy danych, typy i model relacyjny”.

„Czy są jakieś dobre bazy danych, które używają tego alternatywnego języka?”

Jeśli przez „dobry” masz na myśli coś w rodzaju „przemysłowej siły”, to nie. Najbliższą dostępną rzeczą byłby prawdopodobnie Dataphor.

Projekt Rel oferuje implementację języka Tutorial D zdefiniowanego w "Bazach danych, typach i modelu relacyjnym", ale obecnie głównym celem Rel jest charakter edukacyjny.

Mój projekt SIRA_PRISE oferuje implementację do „prawdziwie relacyjnego” zarządzania danymi, ale waham się, czy nazwać ją również „implementacją języka”.

Oczywiście, możesz również przyjrzeć się pewnym nierelacyjnym rzeczom, jak niektórzy proponowali, ale osobiście odrzucam nierelacyjne zarządzanie danymi jako kilkadziesiąt lat regresji technologicznej. To znaczy nie warto się zastanawiać.

Aha, przy okazji, system oprogramowania używany do zarządzania bazami danych nie jest „bazą danych”, ale „systemem zarządzania bazą danych”, w skrócie „DBMS”. Tak jak zdjęcie to nie to samo co aparat, a jeśli rozmawiasz o aparatach i chcesz uniknąć nieporozumień, powinieneś używać właściwego słowa „aparaty” zamiast „fotografować”.

Być może myślisz o krytyce, którą C. Date i jego przyjaciele wypowiedzieli przeciwko istniejącym relacyjnym bazom danych i SQL; mówią, że systemy i język nie są w 100% relacyjne i powinny być. Naprawdę nie widzę tutaj żadnego prawdziwego problemu; o ile widzę, możesz mieć w 100% system relacyjny, jeśli chcesz, po prostu dyscyplinując sposób, w jaki używasz SQL.

To, na co osobiście natrafiam, to brak mocy ekspresji, którą SQL dziedziczy po swojej podstawie teoretycznej, algebrze relacyjnej. Jednym z problemów jest brak wsparcia dla korzystania z porządkowania domen, na które napotykasz, pracując z danymi oznaczonymi datami, sygnaturami czasowymi itp. Kiedyś próbowałem stworzyć aplikację raportującą całkowicie w prostym SQL na bazie danych pełnej sygnatur czasowych i po prostu nie było to wykonalne. Innym jest brak obsługi przemierzania ścieżek: większość moich danych wygląda jak ukierunkowane wykresy, w których muszę przechodzić przez ścieżki, a SQL nie może tego zrobić. (Brakuje "przechodniego zamknięcia". SQL-1999 może to zrobić z "rekursywnymi podzapytaniami", ale nie widziałem ich jeszcze w rzeczywistym użyciu. Istnieją również różne sposoby, aby SQL sobie poradził, ale są brzydkie.) Te problemy są Nawiasem mówiąc, omówione również w niektórych pismach Date.

Niedawno wskazano mi .QL, który wydaje się ładnie rozwiązywać problem zamykania przechodniego, ale nie wiem, czy może rozwiązać problem z zamówionymi domenami.

Bezpośrednia odpowiedź: nie sądzę, żeby był tam jakiś poważny rywal. DBase i jego naśladowcy (Foxpro, Codebase itp.) Byli przez jakiś czas pretendentami, ale myślę, że w zasadzie przegrali wojnę o język zapytań do baz danych. Było wiele innych produktów bazodanowych, które miały swój własny język zapytań, takich jak Progress i Paradox oraz kilka innych, których użyłem, których nazw nie pamiętam i na pewno wiele innych, o których nigdy nie słyszałem. Ale nie sądzę, by jakikolwiek inny pretendent był nawet bliski zdobycia nietrywialnego udziału w rynku.

Jako prosty dowód na to, że istnieje różnica między formatem bazy danych a językiem zapytań, ostatnia wersja DBase, z której korzystałem - wiele lat temu - oferowała zarówno "tradycyjny" język zapytań DBase, jak i SQL, z których oba mogły być używane dostęp do tych samych danych.

Boczne wędrówki: nie powiedziałbym, że SQL jest do bani, ale ma wiele wad. Korzystając z wieloletniego doświadczenia i perspektywy czasu, którą mamy teraz, jestem pewien, że można zaprojektować lepszy język zapytań. Ale stworzenie lepszego języka zapytań i przekonanie ludzi do jego używania to dwie zupełnie różne rzeczy. Czy nie byłoby lepiej przekonać ludzi, że warto było się uczyć. Ludzie spędzili wiele lat, ucząc się efektywnego korzystania z SQL. Nawet jeśli twój nowy język jest łatwiejszy w użyciu, z pewnością będzie krzywa uczenia się. Jak można przeprowadzić migrację istniejących systemów z SQL do nowego języka? Itd. Można to oczywiście zrobić, tak jak C ++, C # i Java w dużej mierze obaliły języki COBOL i FORTRAN. Ale osiągnięcie tego wymaga połączenia przewagi technicznej i dobrego marketingu.

Mimo to, chichoczą ludzie, którzy rzucają się w obronę SQL za każdym razem, gdy ktoś go krytykuje, którzy twierdzą, że każdy problem, który masz z SQL, musi być twoją własną nieudolnością w używaniu go, a nie jakąkolwiek winą SQL, której po prostu nie możesz mieć osiągnęli wyższy poziom myślenia, niezbędny do zrozumienia jego doskonałości, itd. Uspokój się, weź głęboki oddech: obrażamy język komputera, a nie twoją matkę.

Spójrz na LINQ to SQL ...

Wypróbowałem to kilka miesięcy temu i nigdy nie oglądałem się za siebie ...

W latach 80-tych ObjectStore zapewniał przezroczysty dostęp do obiektów. To było trochę jak RDBMS plus ORM, z wyjątkiem tych wszystkich dodatkowych nieszczelnych warstw abstrakcji: przechowywał obiekty bezpośrednio w bazie danych.

Tak więc ta alternatywa była naprawdę „brakiem języka” lub być może „językiem, którego już używasz”. Należałoby pisać kod w C ++ i tworzyć lub przechodzić przez obiekty tak, jakby były obiektami natywnymi, a baza danych zajmowała się wszystkim w razie potrzeby. Trochę jak ActiveRecord, ale faktycznie działał tak dobrze, jak twierdzą marketingowe blitze ActiveRecord. :-)

(Oczywiście nie miał on potencjału marketingowego Oracle i nie miał zerowego kosztu MySQL, więc wszyscy go zignorowali. A teraz próbujemy to powtórzyć za pomocą RDBMS i ORM, a niektórzy próbują argumentować, że tabele w rzeczywistości ma sens do przechowywania obiektów, a napisanie gigantycznego pliku XML, aby powiedzieć komputerowi, jak mapować obiekty do tabel, jest w pewnym sensie rozsądnym rozwiązaniem).

Myślę, że możesz być zainteresowany przyjrzeniem się Dataphor , który jest relacyjnym środowiskiem programistycznym typu open source z własnym serwerem bazy danych (który mówi w języku D) i możliwością tworzenia interfejsów użytkownika z jego języka zapytań.

Wygląda również na to, że Ingres nadal obsługuje QUEL i jest to oprogramowanie typu open source.

Obecnie głównym ruchem jest NoSQL; ogólnie te technologie to:

• Rozproszone „tabele skrótów” przechowujące dane jako pary klucz / wartość
• Bazy danych zorientowane na dokumenty

Osobiście uważam, że nie ma nic złego w SQL, jeśli tylko odpowiada Twoim potrzebom. SQL jest wyrazisty i doskonale nadaje się do pracy z danymi strukturalnymi.

SQL działa dobrze w domenie, dla której został zaprojektowany - powiązane ze sobą tabele danych. Zwykle występuje to w tradycyjnym przetwarzaniu danych biznesowych. SQL nie działa tak dobrze, gdy próbuje się zachować złożoną sieć obiektów.

Jeśli potrzebujesz przechowywać i przetwarzać stosunkowo tradycyjne dane, użyj jakiegoś DBMS opartego na SQL.

W odpowiedzi na Twoją zmianę:

Jeśli szukasz alternatywy dla SQL DML do pobierania danych z relacyjnych magazynów danych, nigdy nie słyszałem o żadnej poważnej alternatywie dla SQL.

Wydaje mi się, że problemy, jakie stawia SQL, nie są tak bardzo sprzeczne z językiem, jak z podstawowymi zasadami przechowywania danych, na których ten język jest oparty. Ludzie często mylą język SQL z relacyjnym modelem danych, na którym zbudowane są systemy RDBMS.

Relacyjne bazy danych nie są jedynym rodzajem baz danych. Powinienem powiedzieć słowo o bazach danych obiektów, ponieważ nie widziałem tego w odpowiedziach innych. Miałem pewne doświadczenie z frameworkiem Zope Python, który używa ZODB do trwałości obiektów zamiast RDBMS (no cóż, teoretycznie jest możliwe zastąpienie ZODB inną bazą danych w zope, ale ostatnim razem, gdy sprawdzałem, nie udało mi się to uruchomić, więc mogę nie myśl o tym pozytywnie).

Sposób myślenia ZODB jest naprawdę inny, bardziej przypomina programowanie obiektowe, które akurat byłoby trwałe.

ORM można postrzegać jako rodzaj języka

W pewnym sensie uważam, że model bazy danych obiektów jest tym, o co chodzi w ORM: dostęp do trwałych danych za pośrednictwem zwykłego modelu obiektowego. To rodzaj języka, który zyskuje pewien udział w rynku, ale na razie nie postrzegamy go jako języka, ale jako warstwę abstrakcji. Jednak uważam, że byłoby znacznie bardziej wydajne użycie ORM na Object-Database niż na SQL (innymi słowy wydajność ORMów, których używałem używając jakiejś bazy danych SQL jako warstwy bazowej).

Istnieje wiele implementacji języka SQL (SQL Server, mysql, Oracle itp.), Ale nie ma innego języka, który służyłby temu samemu celowi w tym sensie, że byłby językiem ogólnego przeznaczenia zaprojektowanym do relacyjnego przechowywania i pobierania danych .

Istnieją obiektowe bazy danych, takie jak db4o , i podobne tak zwane bazy danych noSQL, które odnoszą się do prawie każdego mechanizmu przechowywania danych, który nie opiera się na SQL, ale najczęściej do produktów open source, takich jak Cassandra, luźno opartych na koncepcji Google Bigtable .

Istnieje również wiele produktów bazodanowych specjalnego przeznaczenia, takich jak CDF, ale prawdopodobnie nie musisz się o nie martwić - jeśli ich potrzebujesz, będziesz o tym wiedzieć.

Żaden z nich nie jest równoważny z SQL.

Nie oznacza to, że są „lepsi” lub „gorsi” - po prostu nie są tacy sami. Dennis Forbes napisał ostatnio świetny post, w którym omówił szereg dziwnych twierdzeń, jakie pojawiają się w SQL. Utrzymuje (i zgadzam się), że te skargi pochodzą głównie od ludzi i sklepów, którzy albo wybrali niewłaściwe narzędzie do pracy, albo nie używają prawidłowo ich SQL DBMS (nie jestem już nawet zaskoczony, gdy ja zobacz inną bazę danych SQL, w której każda kolumna to a varchar(50)i nigdzie nie ma ani jednego indeksu ani klucza).

Jeśli wdrażasz kolejny portal społecznościowy i nie przejmujesz się zbytnio zasadami ACID , koniecznie zacznij szukać produktów takich jak db4o. Jeśli jednak tworzysz system biznesowy o znaczeniu krytycznym, zdecydowanie zalecam dwa razy przemyślenie, zanim dołączysz do refrenu „SQL jest do bani”. Najpierw przeprowadź badania, dowiedz się, jakie funkcje mogą, a jakich nie mogą obsługiwać różne produkty.

Edytuj - byłem zajęty pisaniem odpowiedzi i nie otrzymałem aktualizacji pytania od kilku minut. Powiedziawszy to, SQL jest zasadniczo nierozerwalnie związany z samym DBMS. Jeśli uruchamiasz produkt bazodanowy SQL, uzyskujesz do niego dostęp za pomocą SQL, kropka.

Być może szukasz abstrakcji w składni; Linq to SQL, Entity Framework, Hibernate / NHibernate, SubSonic i wiele innych narzędzi ORM zapewniają własną składnię podobną do SQL, która nie jest do końca SQL. Wszystko to „kompiluje się” do SQL. Jeśli uruchomisz SQL Server, możesz także napisać CLR Functions / Procedures / Triggers, co pozwala na pisanie kodu w dowolnym języku .NET, który będzie działał wewnątrz bazy danych; jednak w rzeczywistości nie jest to substytut SQL, a raczej jego rozszerzenie.

Nie znam żadnego pełnego „języka”, który można nałożyć na bazę danych SQL; Oprócz przełączenia się na inny produkt bazodanowy, w końcu zobaczysz SQL na potoku.

SQL jest de facto.

Struktury, które próbują chronić programistów przed tym, w końcu stworzyły własny, specyficzny język (przychodzi na myśl Hibernate HQL).

SQL dość dobrze rozwiązuje problem. Nie jest trudniejszy do nauczenia niż język programowania wysokiego poziomu. Jeśli znasz już język funkcjonalny, opanowanie SQL jest bardzo proste.

Biorąc pod uwagę czołowych dostawców baz danych dostarczających najnowocześniejsze bazy danych (Oracle i SQL Server) obsługujące SQL i zainwestowaliśmy lata w silniki optymalizacyjne itp. Oraz wszystkie czołowe oprogramowanie do modelowania danych i oprogramowanie do zarządzania zmianami w SQL, powiedziałbym, że jest to najbezpieczniejszy zakład.

Ponadto baza danych to coś więcej niż tylko zapytania. Jest skalowalność, tworzenie kopii zapasowych i odzyskiwanie, eksploracja danych. Duzi dostawcy obsługują wiele rzeczy, których nawet nowe silniki „pamięci podręcznej” nawet nie uwzględniają.

Problemy z SQL zmotywowały mnie do przygotowania projektu języka zapytań o nazwie SMEQL na wiki Portland Pattern Repository . Komentarze Witamy. Zapożycza pomysły z programowania funkcjonalnego i eksperymentalnego języka IBM Business System 12. (Pierwotnie nazwałem to TQL, ale później okazało się, że ta nazwa została przejęta).

W świecie .NET, mimo że wciąż ma charakter SQL, LINQ-to-SQL pozwoli ci uzyskać dobre połączenie SQL i przetwarzania danych w pamięci .NET. Upraszcza również wiele operacji związanych z danymi niższego poziomu, których nikt tak naprawdę nie chce.

Jeśli chcesz zobaczyć bazę danych o zupełnie innym sposobie myślenia, spójrz na CouchDB . „Lepiej” jest oczywiście wymaganiem względnym, a tego rodzaju baza danych niezwiązanych z relacjami jest „Lepsza”, ale tylko w pewnych sytuacjach.

SQL język to bardzo potężny , a systemy zarządzania relacyjnymi bazami danych odniosły i nadal odnoszą ogromny sukces. Istnieje jednak klasa aplikacji, która wymaga bardzo dużej skalowalności i dostępności, ale niekoniecznie wysokiego stopnia spójności danych (liczy się ostateczna spójność). Różne systemy uzyskują lepszą wydajność i skalowalność niż RDBMS, zmniejszając potrzebę transakcji w pełni zgodnych z ACID. Zostały one nazwane „NoSQL”, ale jak wskazują inni, jest to błędne określenie: być może powinny nazywać się bazami danych NoACID.

Michael Stonebraker omawia to w Dyskusja „NoSQL” nie ma nic wspólnego z SQL .