Co Robert C. Martin ma na myśli mówiąc, że SQL jest niepotrzebny? [Zamknięte]


45

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?


5
@ christo8989 - „Co rozumie przez zastąpienie SQL interfejsem API?”. Interpretuję go jako oznaczającego, że nie masz tekstowego języka zapytań (który jest przekazywany do silnika SQL) w całej bazie kodu. Ukrywasz to za interfejsem API, który udostępnia tylko bezpieczne mechanizmy opisywania zapytań. Wewnątrz interfejsu API coś musi generować polecenia do silnika SQL, ale jest to mniejszy obszar, w którym można wymusić użycie wiązania parametrów itp., Kontrolować, kto dokonuje zmian itp.
andrew

42
Ale, ale, ale ... SQL jest API. Jest to interfejs API dla RDBMS. Zdarza się, że jest to bardzo potężny interfejs API, którego można łatwo nadużywać.
Bart van Ingen Schenau

25
Jeśli utworzysz DB API, które nie posiada interfejs tekstowy, prędzej czy później jakiś biedny programista napisze kod, który wygląda tak: eval(request.GET["table_name"] + ".get(pk=" + request.GET["pk"] + ")")). To nie SQL jest tak naprawdę winny, ale biedni, nieświadomi programiści.
Lie Ryan

6
@JimmyJames SQL to język tak, ale to nie znaczy, że nie jest to interfejs API. SQL to język zapewniający interfejs API umożliwiający dostęp do niektórych baz danych.
Cubic

5
@nocomprende SQL zawsze był zaprojektowany do użycia w aplikacjach. W przeciwnym razie byłoby praktycznie bezużyteczne. Chodziło zawsze o to, aby dać aplikacjom sposób na przechowywanie i pobieranie danych bez bałaganu w dziwnych niestandardowych formatach, a nawet bez konieczności dbania o sposób przechowywania danych.
Cubic

Odpowiedzi:


74

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.


2
Przynajmniej możemy uniknąć używania go do jakiejkolwiek operacji zapisu, zwykle z tym, co zapewniają materiały podobne do ORM. Jeśli chodzi o zapytania do bazy danych, możesz już robić całkiem sporo rzeczy bez pisania własnego SQL. W dzisiejszych czasach tylko „zaawansowane” wykorzystanie możliwości bazy danych powinno wymagać pisania SQL lub użycia złożonego typu danych (wykres, dane geograficzne, rekurencyjne).
Walfrat

7
Martin twierdzi w szczególności, że używany interfejs API nie powinien być tak potężny jak SQL; Jego argument, że moc SQL jest problemem, a nie cechą. Interfejs API, o który się kłóci, powinien być specyficzny dla aplikacji i być tak elastyczny i wydajny, jak absolutnie potrzebuje aplikacja, a nie więcej. W szczególności argumentuje przeciwko wynalezieniu innego języka zapytań opartego na łańcuchach znaków.
Cubic

3
@Cubic: każde rozwiązanie problemów wymienionych przez Martina prawdopodobnie musi być mniej wydajne lub mniej łatwe w użyciu niż SQL - to ich błogosławieństwo i przekleństwo.
Doc Brown

1
@Barmar: SQL jest tak wysoki, jak to tylko możliwe, a Bob zapewnia, że ​​jest oczywiście niebezpieczny.
Robert Harvey

3
@ christo8989: Nie sądzę, aby próba napisania jednej odpowiedzi była odpowiedzią na wszystko, co Martin napisał lub powiedział w swojej karierze. Moja odpowiedź była jedną z pytań podanych w twoim tytule, wyjaśniając głównie, jak post na blogu w pierwszym linku, który podałeś, powinien być interpretowany przez IMHO.
Doc Brown

57

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.


16
Nie interpretuję artykułów Martina jako zalecających porzucenie RDBMS, ale raczej do korzystania z alternatywnych sposobów interakcji z nimi, np. LINQ-to-SQL lub JPA Criteria API, zamiast bezpośredniego kodowania lub manipulowania ciągami SQL w naszym kodzie źródłowym.
Jules

27
Więc nie powinniśmy ślepo podążać za tym, co mówi ... ale co on mówi ?
TRiG

33
Jedną z rzeczy, których naprawdę nie lubię w tej społeczności, jest to, że kiedy tylko zadajesz pytanie o zrobienie czegoś w Clean Clean / Uncle Bob -way , ludzie zastanawiają się, jak powinieneś zrobić coś innego . „Jak malować jak van Gogh?” - „van Gogh się mylił, zamiast tego powinieneś malować jak Picasso”.
R. Schmitz

21
odkażanie danych wejściowych w celu uniknięcia ataków iniekcyjnych powinno być opcją tworzenia kopii zapasowych po użyciu sparametryzowanych metod w celu oddzielenia kodu od danych wejściowych.
maniak zapadkowy

17
Cała technologia jest skazana na niepowodzenie i zasadniczo wadliwa. Jest to tylko kwestia czasu. Tymczasem mamy rzeczy, które musimy zrobić, korzystając z naszych wadliwych i skazanych technologii.

15

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 .


2
„Trwała pamięć RAM” najwyraźniej odnosi się tylko do wykorzystania baz danych do szeregowania aktualnego stanu aplikacji, bez względu na zgodność z poprzednią wersją. Jasne, niektóre bazy danych są używane w ten sposób, ale w żadnym wypadku nie wszystkie (zdaję sobie sprawę, że to Martin to mówi, nie ty).
Cubic

7
Tak więc Martin twierdzi, że jedynym punktem baz danych jest abstrakcja nad powolnym przechowywaniem? Łał. To potwierdza odpowiedź Roberta Harveya: jego opinia powinna być podjęta z ogromnym ziarnem soli. Na przykład ten punkt widzenia nie uwzględnia faktu, że wartość bazy danych utrzymuje spójny i trwały model danych. Jego idea struktur danych w „trwałej pamięci RAM” (SSD?) Jest zarówno powolna, jak i otwiera możliwość utraty danych, nawet bazy danych NoSQL często używają kronikowania i niezmiennych struktur danych do bezpiecznej aktualizacji trwałych rekordów.
amon

3
@amon Tak, Robert Harvey ma rację, oferując bardziej zróżnicowany punkt widzenia. Ale skoro OP zapytał konkretnie o to, co Robert C. Martin próbuje powiedzieć, przepisałem część jego „nowszej” wypowiedzi.
Søren D. Ptæus

3
@amon - patrz pierwsze zdanie odpowiedzi Doc Browna powyżej. Martin często wypowiada stwierdzenia, które są przesadną przesadą w jego racji, aby się z tym pogodzić. Nie oznacza to, że wszystkie operacje na bazach danych mogą zostać zastąpione przez magazyny w pamięci, podobnie jak po prostu posiadanie komponentu aplikacji, który dotyka SQL w jakiejś formie, jest wystarczająco dużym ryzykiem bezpieczeństwa, którego należy unikać we wszystkich przypadków, a jednak na podstawie jego słów można go interpretować w ten sposób. Ale tak naprawdę stara się, aby wszyscy zatrzymali się i pomyśleli: czy SQL / RDBMS jest odpowiedni dla mojej aplikacji?
Jules

12
@Jules Rozumiem, że często przesadza. Biorąc jednak pod uwagę jego zasięg i reputację, nie jest pomocne, że „wujek Bob” nie wyjaśnia, kiedy przesadza i gdzie właściwie mówi, co ma na myśli. Jeśli ma coś uczyć, nie jest możliwe dwukrotne odgadnięcie i ponowne zinterpretowanie wszystkiego, co mówi, dopóki nie będzie to miało sensu , zwłaszcza, że ​​sam nie odzwierciedla ani nie krytykuje swoich pomysłów. W pewnym momencie łatwiej powiedzieć „nie słuchaj go”, a nawet: wujek Bob uważany za szkodliwy .
amon

11

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.


1
Jasne, Einstein, oczywiście.

1
Ach, nie wiedziałem, że Einstein znał Boba. Albo że Bob był Bogiem. Chociaż brzmi to tak, jakby zawierało trochę zabawy.
candied_orange

9
@nocomprende żyjesz na stałej diecie motywacyjnych plakatów?
candied_orange

2
Ale Bob jest Bogiem. Przynajmniej dla niektórych.
Peter Mortensen

3
Nie wierzę, że Bóg jest tak dobry w wystąpieniach publicznych.
candied_orange

5

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.


Pracowałem nad produktem, który zrobił to dokładnie 30 lat temu. Baza danych nawet nie obsługiwała SQL (jeszcze). Zbiór powiązanych tabel został zapisany w bazie danych (poczekaj na nią ...). Facet, który to wymyślił, był naprawdę mądry. Ale już nie programista.

Podoba mi się ta odpowiedź, ale myślę, że on tego nie powiedział. Stwierdza również: „Ramy nie obsługują problemu ...”. Z twojej odpowiedzi wygląda na to, że mówisz, że używanie Linq-to-Sql jest w porządku, ale czy nie jest to struktura obsługująca ten problem?
christo8989

@ christo8989 Nie wiem. Wymienia Hibernację jako przykład frameworka, który nie poradzi sobie z tym problemem. I rzeczywiście OWASP mówi : „Hibernacja nie zapewnia odporności na wstrzykiwanie SQL, można niewłaściwie korzystać z interfejsu API, jak im się podoba. W HQL (podzbiór Hibernates SQL) nie ma nic szczególnego, co czyni go mniej lub bardziej podatnym”. Podczas gdy niektóre z wymienionych przeze mnie interfejsów API byłyby lepszymi izolatorami, w ogóle nie ujawniającymi SQL. Może Hibernacja jest czymś, czego można użyć do implementacji DAL (ale sama nie jest w pełni izolującym DAL).
ChrisW

1
@ christo8989 augustl.com/blog/2016/... sugeruje, że Datomic jest (tylko) innym opakowaniem / warstwą wokół bazy danych (prawdopodobnie SQL) - „Datomic nie pisze bezpośrednio do systemu plików. Zamiast tego możesz użyć liczby różnych baz danych jako zaplecza pamięci dla Datomic: Dowolna baza danych SQL JDBC itp. ”
ChrisW

Należy zauważyć, że rozwiązanie pozwalające uniknąć wstrzykiwania SQL w ADO.NET nie jest wcale takie skomplikowane - użyj symboli zastępczych w SQL, użyj parametrów w poleceniu i ustaw wartość tych parametrów.
Zev Spitz,

3

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.


Co może myśleć o jednoczesnym odczycie / zapisie danych przez wielu użytkowników?
ChrisW

1
@ChrisW Nie sądzę, że jest to kwestia implementacji, a raczej pomysł wysokiego poziomu na znalezienie lepszego sposobu na trwałe przechowywanie danych.
Keenan

@ChrisW Mówi także o transakcyjnych bazach danych. Wykorzystanie technologii kontroli źródła jako narzędzia trwałości. W ten sposób tworzysz tylko i czytasz, co jest o wiele bardziej przyjazne dla użytkownika niż transakcje i aktualizacje.
christo8989

@Keenan Więc tak naprawdę nie oferuje rozwiązania poprzez wdrożenie. Mówi tylko: pomyśl o tym, co może być?
christo8989

1
@ christo8989 Nie wiem, czy osobiście przewodził rozwojowi kandydatów na rozwiązania problemu trwałego przechowywania w informatyce. Jest to poza zakresem pytania PO. Wujek Bob zajmuje się architekturą wtyczek. Obecny branżowy standard tworzenia aplikacji ściśle łączy się z bazą danych i buduje wokół niej aplikację, aplikacja zależy od db, kiedy db powinien zależeć od aplikacji. Zamiast tego wujek Bob sugeruje, że „baza danych jest szczegółem” i że powinna być oddzielona i wymienna.
Keenan

2

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.


4
„Przestań używać SQL (cytowany z pierwszego linku) brzmi bardzo podobnie, jak mówi, żeby nie używać SQL, o ile rozumiem.
Doc Brown

6
Jest to kwestia kolejności słów. Właściwie był to pierwotnie telegram: KORZYSTANIE Z SQL STOP

6
@nocomprende Więc mówisz, że on jest ofiarą warunków wyścigu? Cóż, ups. Mógłby tego uniknąć za pomocą transakcji SQL.
Konrad Rudolph

Może jest to bardzo krótka mieszanka Visual Basic i Fortran. Gdzie to wszystko się skończy?

1
@KonradRudolph: Cóż, myślę, że zgodzilibyśmy się, że praktycznie nikt nie będzie używać TSX od samego montażu. Będą abstrakcje na wyższym poziomie. Czy te abstrakcyjne transakcje będą transakcjami SQL? Myślę, że nie. Jako język interpretowany, SQL niesie narzut wydajności. To naprawdę nie miało znaczenia, kiedy uzyskiwałeś dostęp do danych na obrotowych dyskach twardych. Jest to jednak niedostępne podczas uzyskiwania dostępu do danych w pamięci RAM.
MSalters

2

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.


Nikt nie twierdził, że samo zablokowanie SQL zapewni bezpieczeństwo twojego systemu. Wujek Bob twierdzi, że zwiększa bezpieczeństwo twojego systemu , a biorąc pod uwagę, że zastrzyk SQL pozostaje największym zagrożeniem dla bezpieczeństwa aplikacji internetowych od ponad dekady, uważam, że nie powinieneś lekceważyć potrzeby branży w zakresie poprawy sposobu komunikacji z bazami danych .
meriton - podczas strajku

@meriton Przepraszamy, ale „rozwiązanie, jedyne rozwiązanie” wydaje się dość jasne. Rozwiązanie problemu SQLi jest znane i dość proste. Ludzie, którym nie przeszkadza użycie instrukcji przygotowania, stworzą niezabezpieczone systemy niezależnie od tego, czy przestaną używać SQL. Są to osoby nieprofesjonalne, które muszą zacząć przestrzegać podstawowych dobrych praktyk lub znaleźć nową pracę.
JimmyJames

2

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 .


2
Samochody zautomatyzowane zapobiegłyby około 98% wypadków samochodowych. Musimy bardziej ufać maszynie , heh heh heh.

3
„Nie możemy powiedzieć, że musimy przestać korzystać z samochodów [poza wyjątkowymi i / lub ściśle kontrolowanymi okolicznościami], ponieważ są oni odpowiedzialni za śmierć ludzi w wypadkach samochodowych.” - Uhm. Możemy to absolutnie powiedzieć. I robi to wielu rozsądnych ludzi.
Konrad Rudolph

1
Mówisz w zasadzie: Aplikacja opracowana w Javie została zhakowana, więc musimy przestać używać Java . Głosowanie jest wystarczające, a poza tym nie jestem tutaj, by uczyć cię zdrowego rozsądku. @KonradRudolph
Billal Begueradj

2
@BillalBEGUERADJ To nieco fałszywa równoważność (ponieważ nic nie jest bezpieczne przed włamaniem), ale nie jest to również całkiem dalekie: istnieją języki, które, w sumie, nie powinny być używane, ponieważ istnieją lepsze alternatywy; na przykład, jeśli używasz C poza kontekstem programowania systemu, robisz to źle. W każdym razie nie głosowałem za twoją odpowiedzią, ale jest ona błędna: ponieważ wbrew temu, co twierdzisz, właśnie to mówi Bob Martin (jak pokazują inne odpowiedzi).
Konrad Rudolph

2

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.


Choć sprintfnie zawiera tego rodzaju dezynfekcji, która wymaga SQL, funkcje, które zostały zaprojektowane specjalnie do tego celu zrobienia, i są całkowicie bezpieczne. Przykład: SqlQuery w Entity Framework .
Robert Harvey

@RobertHarvey: Zakładam, że tak jest. Ze swojej strony głównie pracuję po stronie serwera w C i C ++, więc wciąż widzę od czasu do czasu (na szczęście rzadkie) przykłady ludzi po prostu korzystających z sprintfdynamicznego SQL, co nie jest tym, jak to robisz.
John Bode

1

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.