Czytałem / oglądałem dużo treści Roberta C. Martina. Natknąłem się na niego, mówiąc, że SQL jest niepotrzebny z powodu dysków półprzewodnikowych. Kiedy szukam innych źródeł, aby to zrobić, otrzymuję losowe artykuły opisujące różnicę wydajności SQL między dyskami twardymi a dyskami półprzewodnikowymi (co jest powiązane, ale nie to, co próbuję zbadać).

Ostatecznie nie rozumiem, do czego on chce się dostać. Czy mówi, że zamień SQL na technologie bez SQL? Czy mówi, że przechowuj dane w plikach w systemie plików? A może po prostu chce, aby ludzie przestali używać SQL / Relacyjnych baz danych z powodu ataków SQLi? Obawiam się, że nie rozumiem tego, co on chce zrobić.

Podam tutaj kilka linków, abyś mógł przeczytać bezpośrednio z jego myśli:

1. Stoły Bobby'ego
2. Wykład o czystej architekturze

Po pierwsze, stwierdza, że ​​SQL powinien zostać całkowicie usunięty z systemu.

Rozwiązanie. Jedyne rozwiązanie. Całkowicie eliminuje SQL z systemu. Jeśli nie ma silnika SQL, nie może być ataków SQLi.

I chociaż mówi o zamianie SQL na API, nie sądzę, żeby miał na myśli pozostawienie SQL za API z powodu tego poprzedniego cytatu i tego, co powiedział wcześniej w tym artykule.

Ramy nie obsługują tego problemu; ...

Uwaga dodatkowa: Mówiąc SQL, jestem prawie pewien, że Robert ma na myśli większość relacyjnych baz danych. Może nie wszystkie, ale większość. W każdym razie większość ludzi i tak używa SQL. więc...

Jeśli SQL nie jest używany do utrwalania danych, to czego powinniśmy użyć?

Zanim odpowiem na to pytanie, powinienem również zauważyć. Robert podkreśla, że ​​dyski półprzewodnikowe powinny zmienić narzędzia, których używamy do utrwalania danych. Wskazuje na to odpowiedź Søren D. Ptæus .

Muszę także odpowiedzieć na grupę „ale integralność danych”. Po dalszych badaniach Robert mówi, że powinniśmy używać transakcyjnych baz danych, takich jak datomic . Następnie CRUD zamienia się w CR (twórz i czytaj), a transakcje SQL znikają całkowicie. Integralność danych jest oczywiście ważna.

Nie mogę znaleźć pytania, które obejmowałoby to wszystko. Chyba szukam alternatyw, które pasują do wytycznych Roberta. Datomic jest jeden, ale czy o to chodzi? Jakie inne opcje są zgodne z tymi wytycznymi? I czy faktycznie działają lepiej z dyskami półprzewodnikowymi?

Bob Martin wyraźnie przesadza, aby wyjaśnić swoje stanowisko. Ale o co mu chodzi?

Czy chce tylko, żeby ludzie przestali używać SQL / Relacyjnych baz danych z powodu ataków SQLi?

O ile mi wiadomo, w tym wpisie na blogu (twój pierwszy link) Martin próbuje przekonać ludzi, aby przestali używać SQL, ale nie relacyjnych baz danych. To są dwie różne rzeczy .

SQL jest niezwykle potężnym językiem i jest do pewnego stopnia standaryzowany. Pozwala tworzyć złożone zapytania i polecenia w bardzo kompaktowy sposób, w czytelny, zrozumiały i łatwy do nauczenia sposób. Nie zależy od innego języka programowania, więc jest użyteczny dla większości programistów aplikacji, bez względu na to, czy wolą Java, C, C ++, C #, Python, Ruby, JavaScript, Basic, Go, Perl, PHP lub coś innego.

Jednak ta moc wiąże się z pewnym kosztem : pisanie bezpiecznych zapytań / poleceń SQL jest trudniejsze niż pisanie niebezpiecznych. Bezpieczny interfejs API powinien ułatwiać tworzenie bezpiecznych zapytań „domyślnie”. Potencjalnie niebezpieczne powinny wymagać więcej wysiłku umysłowego lub przynajmniej więcej pisania na klawiaturze. Właśnie dlatego IMHO tłumaczy, że Martin używa SQL w swojej obecnej formie.

Problem nie jest nowy i istnieją bezpieczniejsze interfejsy API niż standardowy SQL, aby uzyskać dostęp do relacyjnej bazy danych. Na przykład wszyscy znawcy mapowania LUB, którzy znają, starają się zapewnić taki interfejs API (chociaż zwykle są zaprojektowane do innych podstawowych celów). Statyczne warianty SQL utrudniają tworzenie dynamicznych zapytań z niezaszyfrowanymi danymi wejściowymi (a to nie jest nowy wynalazek: osadzony SQL, który często korzysta ze statycznego SQL, ma około 30 lat).

Niestety nie znam żadnego interfejsu API, który byłby tak elastyczny, znormalizowany, dojrzały, niezależny od języka, a także tak potężny jak SQL, szczególnie dynamiczny SQL. Dlatego mam wątpliwości co do sugestii Martina, by „nie używać SQL” jako realistycznego sposobu rozwiązania wspomnianych problemów. Przeczytaj więc jego artykuł jako myśl we właściwym kierunku, a nie „najlepszą praktykę”, którą możesz ślepo stosować od jutra.

Opinia Boba Martina jest właśnie taka; opinia jednego człowieka.

Oczekuje się, że programista zrozumie system, który pisze wystarczająco dobrze, aby zachować należytą dbałość o jego bezpieczeństwo i wydajność. Oznacza to, że jeśli rozmawiasz z bazą danych SQL, robisz to, co mówi witryna Bobby Tables : odkażasz swoje dane wejściowe. Oznacza to, że umieścisz bazę danych SQL na komputerze, który zapewnia odpowiednią wydajność. Istnieją bardzo dobrze znane i zrozumiałe sposoby robienia tych rzeczy i chociaż nie gwarantują absolutnego bezpieczeństwa ani idealnej wydajności, nie robią nic innego.

Twierdzenie, że nie potrzebujemy już SQLa, ponieważ mamy teraz dyski SSD, jest po prostu spekulacyjne. SQL nie został wymyślony, ponieważ szybkie dyski twarde jeszcze nie istniały; został wymyślony, ponieważ potrzebowaliśmy standardowego w branży sposobu wyrażania koncepcji odzyskiwania danych. Systemy relacyjnych baz danych mają wiele innych cech oprócz szybkości i bezpieczeństwa, co czyni je idealnymi do operacji biznesowych; w szczególności ACID . Integralność danych jest co najmniej tak samo ważna jak szybkość lub bezpieczeństwo, a jeśli jej nie masz, jaki jest sens zabezpieczenia złych danych lub odzyskania ich tak szybko, jak to możliwe?

Zanim przyjmiesz histerię jednego człowieka jako ewangelię, sugeruję, abyś poznał bezpieczeństwo aplikacji i systemu oraz ich wydajność na własnych warunkach, a nie przez czytanie przypadkowych artykułów w Internecie. Bezpieczeństwo, wydajność i solidna konstrukcja systemu to coś więcej niż „unikanie tej technologii”.

Nie zakazujemy noży kuchennych, ponieważ kilku nieszczęśliwym osobom przypadkowo skaleczy się nimi palcami.

Co on tak naprawdę mówi?

Czy mówi, że zamień SQL na technologie bez SQL?

TL; DR: Tak (w pewnym sensie)

W bardziej niedawnym przemówieniu niż ten, do którego podłączyłeś, na ten sam temat, mówi: „Baza danych jest szczegółem. Dlaczego mamy bazy danych?” .

Twierdzi, że baza danych ma ułatwić dostęp do danych z wirujących dysków, ale w przyszłości „[...] nie będzie dysków” dzięki nowej technologii i tak zwanej „trwałej pamięci RAM” oraz że łatwiej będzie przechowuj dane przy użyciu struktur używanych przez programistów, takich jak tabele skrótów lub drzewa.

Dalej przewiduje, że relacyjne bazy danych w ogóle znikną z powodu ich nowej konkurencji:

Gdybym był Wyrocznią, byłbym bardzo przestraszony, ponieważ przyczyny mojego istnienia znikają spode mnie. [...] Powód istnienia bazy danych znika.

Prawdopodobnie będą istnieć pewne stoły relacyjne, które przetrwają, ale teraz jest pewna zdrowa konkurencja .

Więc nie, dla niego nie chodzi tylko o wstrzykiwanie SQL, chociaż jego zdaniem SQL jest z natury wadliwy pod tym względem .

Notka autora:

Stwierdzenia w tym poście są tylko cytatami mającymi na celu zrozumienie poglądu Roberta C. Martina na ten temat i nie reprezentują opinii autora. Bardziej zróżnicowany punkt widzenia znajduje się w odpowiedzi Roberta Harveya .

SQL jest szczegółem. Znajomość szczegółów nie powinna się rozprzestrzeniać.

Ponieważ SQL jest używany w coraz większej liczbie miejsc w kodzie, kod staje się od niego coraz bardziej zależny.

Gdy uczysz się coraz więcej sztuczek SQL, rozwiązujesz coraz więcej problemów za pomocą SQL. Oznacza to, że przejście na inny interfejs API w celu zachowania wymaga więcej niż tylko tłumaczenia. Musisz rozwiązać problemy, o których nie masz pojęcia.

Wpadasz na to nawet przełączając się między bazami danych. Jedna oferuje fantazyjną funkcję whizzbang 5, więc używasz jej w wielu miejscach, aby dowiedzieć się, że fantazyjna funkcja whizzbang 5 jest zastrzeżona, a teraz masz problem z licencją, który będzie kosztował dużo pieniędzy. Robisz więc dużo pracy, szukając wszędzie, gdzie korzystałeś z funkcji 5 i sam rozwiązujesz problem, aby dowiedzieć się później, że używasz również funkcji whizzbang 3.

Jedną z rzeczy, które sprawiają, że Java jest tak przenośna, jest to, że niektóre funkcje procesora po prostu nie są dostępne. Gdyby były dostępne, użyłbym ich. I nagle są procesory, na których mój kod Java nie będzie działał, ponieważ nie mają tych funkcji. To samo dotyczy funkcji bazy danych.

Łatwo jest poświęcić swoją niezależność, nie zdając sobie z tego sprawy. SQL nie jest wyborem. Jeśli podejmiesz decyzję o użyciu SQL, zrób to w jednym miejscu. Zrób to w sposób, którego nie da się zrobić.

Fakt, że SQL ma problemy z bezpieczeństwem i że przechodzimy na trwałe modele pamięci, nie oznacza, że ​​SQL jest skazany na niepowodzenie. Po prostu doprowadza do tego, że jest to wybór. Jeśli chcesz zachować prawo do dokonania tego wyboru, musisz wykonać pracę.

Warto zauważyć, że ruch bazy danych w latach 80. i wujek Bob mają dość nieprzyjemną historię. Wszystkie problemy rozwiązał przy pomocy płaskiego systemu plików, gdy zarządzanie zmusiło administratora bazy danych do swojego życia. To wydarzenie pchnęło go do jego gwiezdnej kariery konsultingowej. (Opowiada tę historię w jednej ze swoich wczesnych czystych książek, zapomnij o tym). Wie, jak rozwiązywać problemy bez DB i ma małą cierpliwość dla tych, którzy zachowują się, jakby z nich korzystali.

Opowiada także historię o odkładaniu dodawania bazy danych do aplikacji do ostatniej chwili, gdy klient tego zażąda, i dodał ją w ciągu dnia jako funkcję opcjonalną. Domyślam się, że widzi sposób, w jaki większość z nas używa DB jako uzależnienia. Próbuje nam pokazać, jak zerwać z nałogiem.

Cytat z pierwszego cytatu to (wyróżnienie moje),

Rozwiązanie. Jedyne rozwiązanie. Jest wyeliminowanie z systemu SQL całkowicie. Jeśli nie ma silnika SQL, nie może być ataków SQLi.

Co zastąpiłoby SQL? API oczywiście! I NIE interfejs API, który używa języka tekstowego. Zamiast tego interfejs API, który korzysta z odpowiedniego zestawu struktur danych i wywołań funkcji w celu uzyskania dostępu do niezbędnych danych.

Rant nie pozwala programistom aplikacji na używanie SQL.

Sugerowana poprawka polega na umożliwieniu im używania interfejsu API: który nie jest SQL i nie pozwala na wstrzyknięcie.

IMO, przykłady takich interfejsów API mogą obejmować:

• http://bobby-tables.com/csharp sugeruje, że programiści C # mogą korzystać z interfejsu API ADO.NET.

  To nie jest idealny przykład, ponieważ ADO.NET jest szerokim lub głębokim (tj. Potężnym lub ogólnego przeznaczenia) interfejsem API, który umożliwia również użytkownikom wprowadzanie surowego (lub surowego) SQL.

• Niektórzy programiści SQL lub administratorzy baz danych sugerują, że baza danych powinna być skonfigurowana w taki sposób , aby zezwalała na dostęp tylko za pośrednictwem (ograniczonej liczby fachowo napisanych) procedur przechowywanych oraz aby twórcy aplikacji nie mogli pisać własnych (niebezpiecznych) zapytań SQL

• Innym sposobem na „wyeliminowanie SQL z systemu” jest umieszczenie bazy danych (która udostępnia SQL) w innym systemie, do którego dostęp uzyskuje się za pośrednictwem interfejsu API REST lub podobnego.

Tak więc, IMO, ogólne rozwiązanie lub systemy mogą nadal korzystać z bazy danych (szczególnie biorąc pod uwagę, że silnik bazy danych implementuje użyteczne właściwości ACID i dobrze się skaluje itd., Głupotą byłoby próba obejścia się bez niej lub napisanie specyficzny dla aplikacji).

Wymagania rant są spełnione, jeśli SQL API bazy danych jest ukryty przed twórcami aplikacji, za jakimś innym API (np. ADO, być może ORM, usługa sieci Web lub cokolwiek innego).

Mówiąc bardziej ogólnie, przypuszczam, że oznacza to posiadanie specyficznego dla aplikacji DAL („warstwa dostępu do danych” lub „warstwa abstrakcji bazy danych”). DAL izoluje aplikację od szczegółów dotyczących tego, jak i gdzie dane są przechowywane i / lub pobierane. DAL może, ale nie musi być zaimplementowany przy użyciu bazy danych SQL.

Wydaje się, że wszyscy odpowiadają na to pytanie z punktu widzenia bezpieczeństwa lub za pomocą soczewki SQL.

Widziałem wykład Roberta Martina, w którym opowiada, że ​​jako programiści używamy wielu różnych struktur danych, które są optymalne dla naszych konkretnych programów. Dlatego zamiast uniwersalnie przechowywać wszystkie dane w strukturze tabelarycznej, powinniśmy przechowywać nasze dane w tabelach skrótów, drzewach itp., Abyśmy mogli pobrać dane i przejść bezpośrednio do programu.

Zinterpretowałem jego wiadomość jako mówiącą, że powinniśmy na chwilę odrzucić nasze obecne założenia dotyczące trwałego przechowywania, aby rozważyć inne przyszłe możliwości niż stary format tabelaryczny SQL. SSD to rozwiązanie kandydujące, ale nie jedyne.

W rzeczywistości nie powinien on używać baz danych i SQL - całkiem otwarcie. Pierwsze odniesienie jest dobrze znanym problemem, drugie odniesienie brzmi jak rant. Chociaż interpretuję to jako dobry powód do korzystania z baz danych, a nie SQL. Z mojej perspektywy nie jest to nawet rozsądna rada.

Niestety przykład, którego używa, to dobrze znany przykład ze znanym rozwiązaniem, na które następnie wskazuje. Zwykle dzieje się tak, gdy programista nie zdaje sobie sprawy z tego, co robi. Na przykład konstruowanie ciągów zawierających SQL, takich jak:

    my $sql="select a from b where a=$ui_val;";
    prepare($sql)
    execute($sql)

w przeciwieństwie do

    my $sql="select a from b where a=?;";
    prepare($sql)
    execute($sql,$ui_val);

Jest to podobny do perla przykład DBI dla kodu ruby ​​on rails. Podany przez niego kod szyny jest łatwy do pomylenia między sejfem a sejfem. Podobnie jak wiele ORM ukrywa to, co kryje się pod SQL, i tak często masz do czynienia z interfejsem, który konstruuje i wykonuje SQL dla Ciebie. Czy to nie brzmi prawie tak, jak by to zrobił dla ciebie API?

Moją interpretacją pierwszego odniesienia jest to, że sugeruje, abyśmy zastąpili dobrze znany problem, który ma dobrze znane rozwiązanie.

Szkoda też, że nie wspomina, że ​​jeśli zostanie to wykonane poprawnie, kod będzie łatwiejszy do napisania i bardziej czytelny, chociaż jeśli zostanie to zrobione dobrze, może być trudniejsze do napisania i mniej czytelne. Ponadto nie wspomina, że ​​SQL jest naprawdę bardzo łatwy do odczytania i robi to, czego na ogół można oczekiwać.

Jest częściowo poprawny, ostatecznie będziemy mieli nieskończenie dużą i szybką pamięć oraz nieskończenie szybki procesor. Dopóki nie wymkniemy się z obecnej fizyki, która ogranicza przetwarzanie, nie ma on racji.

Tak, wirujący dysk należy już do przeszłości, a teraz używamy dysków SSD. Dyski działają z około ~ 10 milisekundami na transfer danych, dyski SSD działają z ~ 0,5 milisekund (500 mikrosekund) czasu dostępu do danych. Pamięć RAM jest rzędu 100 nano sekund, procesory pracują z dokładnością do 100 s piko sekund. To jest sedno tego, dlaczego potrzebujemy baz danych. Bazy danych zarządzają przesyłaniem danych między wirującymi dyskami lub dyskami SSD z pamięcią główną. Pojawienie się dysków SSD nie wyeliminowało potrzeby korzystania z baz danych.

Odpowiedź

czy on po prostu chce, aby ludzie przestali używać SQL / Relacyjnych baz danych z powodu ataków SQLi?

Artykuł „Tabele Bobby'ego” wydaje się sugerować, że to samo w sobie jest powodem, aby nie używać SQL:

Rozwiązanie. Jedyne rozwiązanie. Całkowicie eliminuje SQL z systemu. Jeśli nie ma silnika SQL, nie może być ataków SQLi.

Może mieć inne powody, które omawia gdzie indziej. Nie wiedziałbym, bo tak naprawdę nie czytam dużo jego materiałów.

Dygresja

Ta część nie jest tak naprawdę odpowiedzią, ale myślę, że pytanie o wartość SQL jest o wiele bardziej interesujące (podobnie jak inne).

Mam duże doświadczenie w korzystaniu z SQL i myślę, że dobrze rozumiem jego mocne i słabe strony. Osobiście uważam, że było nadużywane i nadużywane, ale pomysł, że nigdy nie powinniśmy go używać, jest trochę głupi. Pomysł, że musimy wybrać „SQL zawsze” lub „SQL nigdy” jest fałszywą dychotomią.

O ile iniekcja SQL jest argumentem za niestosowaniem SQL, to jest śmieszne. Jest to dobrze zrozumiany problem z dość prostym rozwiązaniem. Problem z tym argumentem polega na tym, że SQLi nie jest jedyną istniejącą podatnością. Jeśli uważasz, że korzystanie z interfejsów API JSON zapewnia bezpieczeństwo, czeka Cię wielka niespodzianka.

Myślę, że każdy programista powinien obejrzeć ten film zatytułowany „Piątek 13: atakowanie JSON - Alvaro Muñoz i Oleksandr Mirosh - AppSecUSA 2017”

Jeśli nie masz czasu ani ochoty się temu przyglądać, oto sedno: wiele bibliotek deserializacji JSON ma luki w zabezpieczeniach umożliwiających zdalne wykonanie kodu. Jeśli korzystasz z XML, masz jeszcze więcej powodów do zmartwień. Zablokowanie SQL w architekturze nie zapewni bezpieczeństwa twojego systemu.

Chcę odnieść się tylko do krótkiego oświadczenia:

A może po prostu chce, aby ludzie przestali używać SQL / Relacyjnych baz danych z powodu ataków SQLi?

Nie. To błędne założenie. Nie możemy powiedzieć, że musimy przestać używać samochodów, ponieważ są oni odpowiedzialni za śmierć ludzi w wypadkach samochodowych. W ten sam sposób bazy danych SQL / relacyjne bazy danych (lub cokolwiek innego w tym kontekście, takie jak RDBMS) nie są odpowiedzialne za szkodliwy ładunek SQL, który atakujący może wykonać w Twojej aplikacji internetowej. Jestem pewien, że autor nie miał tego na myśli, ponieważ w tym celu jest cały ściągawka SQL zapobiegająca wstrzykiwaniu .

Problem Martina wydaje się polegać na tym, że programiści budują dynamiczny SQL bezpośrednio z danych wprowadzanych przez użytkownika, coś w stylu (wybacz mi, jestem przede wszystkim programistą C i C ++):

sprintf( query, "select foo from bar where %s;", user_input );

który jest absolutnie receptą na zgagę (stąd pasek Bobby Tables ). Każdy programista, który umieszcza taki kod w systemie produkcyjnym, zasługuje na paddlin '.

Możesz złagodzić (jeśli nie całkowicie wyeliminować) problem, używając przygotowanych instrukcji i odpowiednio odkażając swoje dane wejściowe. Jeśli możesz ukryć kod SQL za interfejsem API, tak aby programiści nie budowali bezpośrednio ciągów zapytań, tym lepiej - co jest częścią tego, co zaleca Martin.

Ale jeśli chodzi o całkowite pozbycie się SQL, nie sądzę, aby było to praktyczne lub pożądane. Modele relacyjne są przydatne , dlatego istnieją przede wszystkim, a SQL jest prawdopodobnie najlepszym interfejsem do pracy z modelami relacyjnymi.

Jak zawsze chodzi o użycie odpowiedniego narzędzia do pracy. Jeśli twoja aplikacja koszyka na zakupy nie potrzebuje pełnego modelu relacyjnego, nie używaj modelu relacyjnego (co oznacza, że ​​nie będziesz musiał używać SQL). Jeśli potrzebujesz modelu relacyjnego, prawie na pewno będziesz pracować z SQL.

Dwa połączone źródła przekazują różne komunikaty:

Wpis na blogu mówi, że logika dostępu do danych nie powinna istnieć jako tekst w czasie wykonywania, aby nie zostać pomieszana z niezaufanym wprowadzeniem użytkownika. Oznacza to, że post na blogu potępia pisanie zapytań przez łączenie ciągów.

Wykład jest inny. Pierwsza różnica jest w tonie: wykład spekuluje i kwestionuje, ale nie potępia. Nie twierdzi, że bazy danych są złe, ale rzuca nam wyzwanie, aby wyobrazić sobie trwałość bez bazy danych. Twierdzi on, że w ciągu 30 lat od rozpowszechnienia relacyjnych baz danych wiele rzeczy uległo zmianie i podkreśla dwie, które mogą mieć wpływ na nasz wybór technologii trwałości:

• powierzchnia magazynowa wzrosła około 1 milion razy - w porównywalnych cenach! W związku z tym mniej jest konieczne oszczędzanie pamięci, a w szczególności nie trzeba już jej usuwać. Korzystając z pamięci tylko z dołączaniem, można uprościć kontrolę współbieżności, ponieważ blokady odczytu są niepotrzebne. Może to wyeliminować potrzebę transakcji.
• czasy dostępu spadły, ponieważ większość zestawów danych mieści się teraz w pamięci RAM, co znacznie zmniejsza opóźnienia odczytu.

Czy te zmienione okoliczności zmieniają optymalną technologię trwałości? Co ciekawe, wujek Bob nie mówi - prawdopodobnie dlatego, że uważa, że ​​żadna odpowiedź nie byłaby poprawna dla wszystkich programów. Dlatego ostrzega nas, abyśmy traktowali nasz wybór technologii uporczywości jako szczegół, a nie zapisywali go w kamiennych tablicach i przekazywali jako otrzymaną mądrość naszym rówieśnikom.

Czy istnieją alternatywy?

Zapis logiki dostępu do danych bez ciągów jest całkowicie możliwy. W środowisku Java można użyć QueryDSL , w której zapytania są opisywane przy użyciu płynnego API typu bezpiecznego generowanego ze schematu bazy danych. Takie zapytanie może wyglądać następująco:

JPAQuery<?> query = new JPAQuery<Void>(entityManager);
Customer bob = query.select(customer)
  .from(customer)
  .where(customer.firstName.eq("Bob"))
  .fetchOne();

Jak widać, logika zapytania nie jest wyrażana jako ciąg, wyraźnie oddzielając zaufaną strukturę zapytania od niezaufanych parametrów (i oczywiście QueryDSL nigdy nie włącza parametrów do tekstu zapytania, ale używa przygotowanych instrukcji do oddzielenia zapytania dla jego parametrów na poziomie JDBC). Aby uzyskać wstrzyknięcie SQL za pomocą QueryDSL, musisz napisać własny analizator składni, aby przeanalizować ciąg znaków i przetłumaczyć go na drzewo składniowe, a nawet gdyby to zrobił, prawdopodobnie nie dodałbyś obsługi takich nieprzyjemnych rzeczy select ... into file. Krótko mówiąc, QueryDSL sprawia, że ​​wstrzyknięcie SQL jest prawie niemożliwe, a także poprawia wydajność programisty i zwiększa bezpieczeństwo refaktoryzacji. Zapobiegał największemu zagrożeniu dla bezpieczeństwa aplikacji internetowych, które istniało wystarczająco długo, aby spawnować działające gagii zwiększyłeś produktywność programistów? Śmiem twierdzić, że jeśli nadal piszesz zapytania jako ciągi, robisz to źle.

Jeśli chodzi o alternatywy dla relacyjnych baz danych, ciekawe jest to, że kontrola współbieżności wielu wersji Postgres jest dokładnie tego rodzaju strukturą danych tylko o dołączaniu, o której mówi wujek Bob, chociaż prawdopodobnie myślał raczej o magazynach zdarzeń i źródłach zdarzeń wzorzec w ogólności, co również ładnie pasuje do pojęcia utrzymania bieżącego stanu w pamięci RAM.