Я багато читав / переглядав вміст Роберта К. Мартіна. Я натрапив на нього, кажучи, що SQL непотрібний через твердотільні накопичувачі. Коли я шукаю інші джерела, щоб підтвердити це, я отримую купу випадкових статей, що описують різницю продуктивності SQL між жорсткими дисками та твердотільними накопичувачами (що пов'язано, але не те, що я намагаюся дослідити).

Зрештою, я не розумію, до чого він намагається потрапити. Він говорить, чи замінити SQL технологіями No-SQL? Він говорить, що зберігати дані у файлах у файловій системі? Або він просто хоче, щоб люди перестали використовувати SQL / реляційні бази даних через атаки SQLi? Я боюся, що я пропускаю точку, яку він намагається зробити.

Я надам тут кілька посилань, щоб ви могли читати прямо з його думки:

1. Столи бобі
2. Лекція з чистої архітектури

По-перше, він заявляє, що SQL слід повністю видалити з системи.

Рішення. Єдине рішення. Це повністю усунути SQL з системи. Якщо двигуна SQL немає, то атак SQLi не може бути.

І хоча він говорить про заміну SQL на API, я не думаю, що він означає поставити SQL за API через цю попередню цитату і те, що він говорив раніше в статті.

Рамки не вирішують проблеми; ...

Побічна примітка: кажучи про SQL, я впевнений, що Роберт має на увазі більшість реляційних баз даних. Можливо, не всі, але більшість. У будь-якому випадку, більшість людей все одно використовують SQL. тому...

Якщо SQL не використовується для збереження даних, то що ми маємо використовувати?

Перш ніж відповісти на це, я також повинен зазначити. Роберт підкреслює, що твердотільні накопичувачі повинні змінити інструменти, які ми використовуємо для збереження даних. Відповідь Сьорена Д. Птюса наголошує на цьому.

Я також повинен відповісти на групу "але цілісність даних". Після деяких подальших досліджень Роберт каже, що ми повинні використовувати транзакційні бази даних, такі як датомічні . Потім CRUD перетворюється на CR (створювати і читати), а транзакції SQL взагалі відходять. Цілісність даних, безумовно, важлива.

Я не можу знайти питання, яке охоплює все це. Я думаю, я шукаю альтернативи, які відповідають настановам Роберта. Датомічний - це одне, але це так? Які ще варіанти відповідають цим рекомендаціям? І чи справді вони краще працюють на твердотільних накопичувачах?

Боб Мартін явно перебільшує, щоб зробити його більш зрозумілим. Але в чому його суть?

Чи він просто хоче, щоб люди припинили використовувати SQL / реляційні бази даних через атаки SQLi?

Наскільки я розумію, у цій публікації блогу (ваше перше посилання) Мартін намагається переконати людей припинити використання SQL, але не реляційних баз даних. Це дві різні речі .

SQL - надзвичайно потужна мова, і вона певною мірою стандартизована. Це дозволяє створювати складні запити та команди дуже компактно, у читаному, зрозумілому, легкому для засвоєння вигляді. Це не залежить від іншої мови програмування, тому він може бути використаний для більшості програмістів додатків, незалежно від того, чи віддають вони перевагу Java, C, C ++, C #, Python, Ruby, JavaScript, Basic, Go, Perl, PHP або щось інше.

Однак ця сила приходить до витрат : писати безпечні запити / команди SQL важче, ніж писати небезпечні. Безпечний API повинен спрощувати створення безпечних запитів "за замовчуванням". Потенційно небезпечним особам потрібно більше розумових або, принаймні, більше зусиль для друку. Це IMHO, чому Мартін рентує проти SQL в його нинішньому вигляді.

Проблема не нова, і для доступу до реляційної бази даних є безпечніші API, ніж стандартні SQL. Наприклад, усі АБО картографи, яких я знаю, намагаються надати такий API (хоча вони, як правило, розроблені для інших основних цілей). Статичні варіанти SQL ускладнюють створення будь-яких динамічних запитів із несанітизованими вхідними даними (і це не новий винахід. Вбудованому SQL, який часто використовує статичний SQL, близько 30 років).

На жаль, я не знаю жодного API, який би настільки гнучкий, стандартизований, зрілий, незалежний від мови, а також такий потужний, як SQL, особливо динамічний SQL. Тому я маю певні сумніви щодо пропозиції Мартіна "не використовувати SQL" як реалістичний спосіб вирішення згаданих проблем. Тому читайте його статтю як думку в правильному напрямку, а не як "найкращу практику", яку ви можете сліпо слідувати з завтрашнього дня.

Думка Боб Мартіна - саме це; думка однієї людини.

Очікується, що програміст зрозуміє систему, про яку він пише, досить добре, щоб розумно дбати про її безпеку та ефективність. Це означає, що якщо ви спілкуєтесь із базою даних SQL, ви робите те, що говорить веб-сайт Bobby Tables : ви санітуєте вхідні дані. Це означає, що ви ставите свою базу даних SQL на машину, яка обіцяє адекватну продуктивність. Існують дуже відомі і добре зрозумілі способи зробити це, і хоча вони не гарантують абсолютної безпеки або ідеальної роботи, також нічого іншого.

Твердження, що нам більше не потрібен SQL, оскільки тепер у нас є SSD, є просто розумним. SQL не був винайдений, тому що швидкісні жорсткі диски ще не існували; він був винайдений тому, що нам потрібен був стандартний спосіб вираження понять пошуку даних. Системи реляційних баз даних мають багато інших якостей, окрім швидкості та безпеки, що робить їх ідеальними для ділових операцій; зокрема, кислоти . Цілісність даних є принаймні такою ж важливою, як швидкість або безпека, і якщо у вас її немає, то який сенс захищати погані дані або отримувати їх якомога швидше?

Перш ніж сприймати істерику чоловіка як євангелію, я пропоную вам дізнатися про застосування та безпеку системи та їх роботу на власних умовах, а не читаючи випадкові статті в Інтернеті. Для безпеки, продуктивності та надійного дизайну системи є набагато більше, ніж просто "уникати цієї технології".

Ми не забороняємо кухонні ножі, тому що декілька нещасних людей вдається випадково порізати їм пальці.

Що він насправді каже?

Він говорить, чи замінити SQL технологіями No-SQL?

TL; DR: Так (свого роду)

У нещодавньому розмові, ніж той, з яким ви пов'язувались на тій же темі, він говорить: "База даних - це деталь. Чому у нас є бази даних?" .

Він стверджує, що база даних стала спрощувати доступ до даних із спінінг-дисків, але в майбутньому "[...] не буде дисків" завдяки новій технології і тому, що він називає "стійкою ОЗУ", і що це буде простіше зберігати дані за допомогою структур, які використовують програмісти, наприклад хеш-таблиць або дерев.

Він продовжує прогнозувати, що реляційні бази даних в цілому значною мірою зникнуть через їх нову конкуренцію:

Якби я був Oracle, я б дуже злякався, бо причина мого існування випаровується з-під мене. [...] Причина існування бази даних зникає.

Напевно, будуть якісь реляційні таблиці, які виживають, але зараз є якась здорова конкуренція .

Тож ні, для нього мова йде не лише про ін'єкцію SQL, хоча він вважає, що SQL в цьому відношенні суттєво хибний .

Примітка автора:

Висловлювання в цій публікації є лише цитатами, щоб зрозуміти погляд Роберта К. Мартіна на цю тему і не представляє думку автора. Для більш диференційованої точки зору дивіться відповідь Роберта Харві .

SQL - деталь. Знання деталі не повинно поширюватися.

Оскільки SQL використовується все більше і більше місць у вашому коді, ваш код стає все більш і більш залежним від нього.

Коли ви дізнаєтесь все більше і більше хитрощів SQL, ви вирішуєте все більше і більше проблем за допомогою SQL. Це означає, що перехід на інший API, щоб продовжуватись, передбачає більше, ніж просто переклад. Ви повинні вирішити проблеми, яких ви не усвідомлювали.

Ви стикаєтесь з цим навіть перемиканням між базами даних. Один пропонує фантастичну функцію whizzbang 5, тому ви використовуєте її в декількох місцях лише для того, щоб дізнатись фантазійну функцію whizzbang 5, яка є власницею, і тепер у вас є проблема з ліцензуванням, яка коштуватиме багато грошей. Таким чином, ви багато працюєте над розкопуванням скрізь, де ви використовували функцію 5, і вирішувати проблему самостійно, щоб дізнатися пізніше, що ви також використовуєте функцію whizzbang 3.

Однією з речей, яка робить Java такою портативною, є те, що певні функції процесора просто недоступні. Якби вони були в наявності, я б використовував їх. І раптом з’являються процесори, на яких мій код Java не буде працювати, оскільки вони не мають цих функцій. Так само і з функціями бази даних.

Все легко пожертвувати своєю незалежністю, не усвідомлюючи цього. SQL - це вибір не даний. Якщо ви приймаєте рішення використовувати SQL, тоді зробіть його в одному місці. Зробіть це таким чином, що його можна не вишити.

Те, що у SQL є проблеми із безпекою і що ми переходимо до стійких моделей пам'яті, не означає, що SQL приречений. Це просто призводить додому, що це вибір. Якщо ви хочете зберегти право зробити цей вибір, вам доведеться виконати роботу.

Можливо, варто відзначити, що рух баз даних 80-х та дядька Боба мають досить неприємну історію. Він вирішив усі свої проблеми з плоскою файловою системою, коли управління примусило адміністратора бази даних у своє життя. Ця подія підштовхнула його до його зоряної консультаційної кар’єри. (Він розповідає цю історію в одній зі своїх ранніх чистих книг, забувши яку) Він знає, як вирішити проблеми без БД, і має мало терпіння для тих, хто діє так, як користуватися ними.

Він також розповідає історію про відкладення додавання БД до програми до останньої хвилини, коли клієнт вимагає цього, і додає його за день як додаткову функцію. Я здогадуюсь, він бачить, як більшість із нас використовують БД як залежність. Він намагається показати нам, як відкинути звичку.

Цитата з вашої першої цитати є (моє наголос),

Рішення. Єдине рішення. Це повністю усунути SQL з системи . Якщо двигуна SQL немає, то атак SQLi не може бути.

Що замінить SQL? API звичайно! І НЕ API, який використовує текстову мову. Натомість API, який використовує відповідний набір структур даних та функціонує викликів для доступу до необхідних даних.

Противодиться проти того, щоб програмісти прикладних програм могли використовувати SQL.

Запропонований виправлення полягає в тому, щоб дозволити їм використовувати замість цього API: який не є SQL і не дозволяє вводити ін'єкції.

ІМО, приклади таких API можуть включати:

• http://bobby-tables.com/csharp пропонує програмістам C # використовувати API ADO.NET.

  Це не ідеальний приклад, тому що ADO.NET - це широкий або глибокий (тобто потужний або загального призначення) API, який також дозволяє своїм користувачам вводити необроблений (або необроблений) SQL.

• Деякі розробники SQL або адміністратори бази даних пропонують налаштувати базу даних таким чином, щоб вона дозволяла отримувати доступ лише через (обмежену кількість кваліфіковано написаних) збережених процедур , і що розробникам додатків не слід дозволяти писати власні (небезпечні) запити SQL

• Інший спосіб "усунути SQL з системи" - це розмістити базу даних (яка відкриває SQL) в іншій системі, до якої можна отримати доступ через REST API або подібну.

Отже, IMO, загальне рішення або система [и] все ще можуть використовувати базу даних (особливо з огляду на те, що двигун бази даних реалізує корисні властивості ACID, добре масштабує і так далі, можливо, буде нерозумно намагатися обійтися без одного або написати специфічний для програми).

Вимоги ранту задовольняються, якщо API SQL бази даних прихований від розробників додатків, за деяким іншим API (наприклад, ADO, можливо, ORM, веб-сервіс чи інше).

Загалом, я вважаю, що це означає наявність певного додатка (DAL) ("рівень доступу до даних" або "рівень абстракції бази даних"). DAL ізолює додаток від деталей того, як і де зберігаються та / або отримуються дані. DAL може бути або не може бути реалізований за допомогою бази даних SQL.

Здається, всі відповідають на це питання з точки зору безпеки або за допомогою об'єктива SQL.

Я бачив лекцію Роберта Мартіна, де він розповідає, що ми, як програмісти, використовуємо багато різних структур даних, оптимальних для наших конкретних програм. Отже, замість повного зберігання всіх даних у табличній структурі, ми повинні зберігати наші дані у хеш-таблицях, деревах тощо, щоб ми могли захопити дані та перейти прямо до програми.

Я інтерпретував його повідомлення лише як кажучи, що ми повинні на мить викинути наші припущення щодо постійного зберігання, щоб розглянути інші майбутні можливості, ніж віковий формат таблиці SQL. SSD - це кандидатське рішення, але не єдине.

Насправді він не повинен використовувати бази даних і SQL - досить явно. Перша посилання - це добре відома проблема, друга посилання звучить як звук. Хоча, я трактую це як є вагомий привід використовувати бази даних і не використовувати SQL. З моєї точки зору, це навіть не розумні поради.

На жаль, приклад, який він використовує, є добре відомим прикладом із добре відомим рішенням, яке він потім вказує. Зазвичай це виникає, коли програміст не усвідомлює, що він робить. Наприклад, побудова рядків, що містять SQL на зразок:

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

на відміну від

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

Це схожий приклад DBI для коду рубіну на рейках. Код рейки, який він надає, легко переплутати між безпечним і небезпечним. Як і багато ORM, приховує, що знаходиться під SQL, і тому часто ви маєте справу з інтерфейсом, який створює та виконує sql для вас. Це не схоже на те, що API робив би для вас?

Моя інтерпретація першої посилання полягає в тому, що він пропонує нам замінити добре відоме питання, яке має добре відоме рішення.

Також прикро, що він не згадує, що якщо це зробити правильно, це полегшить написання та більш читабельний, хоча якщо це буде зроблено добре, це насправді може бути складніше писати і менш читабельним. Крім того, він не згадує, що SQL насправді дуже легко читати і робить те, що ви, як правило, очікуєте.

Він частково правильний, зрештою у нас буде нескінченно велика і швидка пам'ять і нескінченно швидкий процесор. Поки ми не вислизнемо з поточної фізики, яка стримує обчислення, він не є правильним.

Так, прядильний диск - це минуле, і зараз ми використовуємо SSD. Диски працюють з приблизно ~ 10 мілісекундами на передачу даних, SSD - з ~ 0,5 мілісекундами (500 мікросекунд) час доступу до даних. Оперативна пам’ять становить близько 100 наносекунд, процесори працюють на коефіцієнті 100s пікосекунди. Це серце, чому нам потрібні бази даних. Бази даних управляють передачею даних між прядильними дисками або SSD з основною пам'яттю. Поява SSD не усунула необхідності в базах даних.

Відповідь

він просто хоче, щоб люди припинили використовувати SQL / реляційні бази даних через атаки SQLi?

Стаття "Столи Бобі", здається, дозволяє припустити, що це, саме по собі, є причиною не використовувати SQL:

Рішення. Єдине рішення. Це повністю усунути SQL з системи. Якщо двигуна SQL немає, то атак SQLi не може бути.

У нього можуть бути й інші причини, які він обговорює в інших місцях. Я б не знав, бо я не дуже багато читаю його речей.

Відступ

Ця частина насправді не є відповіддю, але я вважаю, що питання про значення SQL набагато цікавіше (як і інші, мабуть.)

У мене був великий досвід використання SQL, і я думаю, що я добре розумію його сильні та слабкі сторони. Моє особисте відчуття полягає в тому, що це було зловживано та зловживано, але думка, що ми ніколи не повинні його використовувати, є якось дурною. Ідея, що нам слід обирати "завжди SQL" або "ніколи SQL", є хибною дихотомією.

Що стосується того, що ін'єкція SQL є аргументом для використання SQL, це смішно. Це добре зрозуміла проблема з досить простим рішенням. Проблема цього аргументу полягає в тому, що SQLi - не єдина вразливість. Якщо ви думаєте, що використання API JSON робить вас безпечним, вас чекає великий сюрприз.

Думаю, кожен розробник повинен переглянути це відео під назвою "П’ятниця 13 числа: Атака JSON - Альваро Муньос та Олександр Мірош - AppSecUSA 2017"

Якщо у вас немає часу або нахилу переглядати це, ось суть: у багатьох бібліотек десеріалізації JSON є вразливі місця виконання коду. Якщо ви використовуєте XML, вам доведеться ще більше турбуватися. Заборона SQL у вашій архітектурі не зробить вашу систему захищеною.

Я хочу звернутися лише до короткої заяви:

Або він просто хоче, щоб люди перестали використовувати SQL / реляційні бази даних через атаки SQLi?

Ні. Це неправильне припущення. Ми не можемо сказати, що ми повинні припинити користуватися автомобілями, адже вони несуть відповідальність за людей, які загинули в автомобільних аваріях. Таким же чином, бази даних SQL / реляційні (або що-небудь інше в цьому контексті, наприклад RDBMS) не несуть відповідальності за зловмисне навантаження SQL, яке зловмисник може виконувати у вашому веб-додатку. Я впевнений, що автор цього не мав на увазі, оскільки для цього існує ціла табличка читів для запобігання ін'єкцій SQL .

Мабуть, проблема Мартіна полягає в тому, що програмісти будують динамічний SQL безпосередньо з введення користувача, щось на зразок (вибачте, я в першу чергу програміст C і C ++):

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

що абсолютно рецепт печії (звідси смужка " Боббі Столи" ). Будь-який програміст, який вводить подібний код у виробничу систему, заслуговує на подряд.

Ви можете усунути (якщо не повністю усунути) проблему, скориставшись підготовленими заявами та належним чином очистивши свої дані. Якщо ви можете приховати SQL за API таким чином, що програмісти безпосередньо не будують рядки запитів, тим більше, що краще (що є частиною того, що виступає Мартін).

Але що стосується повного позбавлення від SQL, я не вважаю це практичним чи бажаним. Реляційні моделі корисні , тому вони існують в першу чергу, і SQL - це, мабуть, найкращий інтерфейс для роботи з реляційними моделями.

Як завжди, справа в тому, щоб використовувати для роботи потрібний інструмент. Якщо у вашому додатку кошика для покупок не потрібна повна реляційна модель, тоді не використовуйте реляційну модель (тобто вам не потрібно використовувати SQL). Коли вам потрібна реляційна модель, ви майже напевно будете працювати з SQL.

Два джерела, з якими ви посилаєтеся, передають різні повідомлення:

У публікації блогу йдеться про те, що логіка доступу до даних не повинна існувати як текст під час виконання, щоб не змішуватися з ненадійним введенням користувача. Тобто, повідомлення в блозі засуджує написання запитів шляхом об'єднання рядків.

Лекція різна. Перша різниця полягає в тонусі: Лекція розмірковує і ставить під сумнів, але не засуджує. Він не каже, що бази даних є злими, але закликає нас уявити стійкість без бази даних. Він стверджує, що за 30 років з моменту поширення реляційних баз даних багато речей змінилося, і виділяє два, які, можливо, вплинуть на наш вибір технології збереження:

• простір для зберігання збільшився приблизно в 1 мільйон - за порівнянними цінами! Отже, зберігати сховище потрібно менше, а зокрема видаляти його більше не потрібно. Використовуючи сховище лише для додавання, контроль сумісності можна спростити, оскільки блокування читання непотрібне. Це може уникнути потреби в транзакціях.
• Час доступу зменшився, тому що більшість наборів даних зараз поміщаються в оперативну пам’ять, масово скорочуючи затримку читання.

Чи змінюються ці змінені обставини оптимальної технології збереження? Цікаво, що дядько Боб не каже - мабуть тому, що він вважає, що відповідь не буде правильною для всіх програм. Ось чому він застерігає нас ставитися до вибору технології збереження, як до деталей, а не до закріплення її в кам'яних табличках і передавати її як отриману мудрість нашим ровесникам.

Чи існують альтернативи?

Запис логіки доступу до даних без рядків цілком можливо. У землі Java ви можете використовувати QueryDSL , де запити описуються за допомогою безпечного для API типу, що створюється на основі схеми вашої бази даних. Такий запит може виглядати наступним чином:

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

Як бачимо, логіка запиту не виражається як String, чітко відокремлюючи довірену структуру запиту від ненадійних параметрів (і звичайно, QueryDSL ніколи не включає параметри в текст запиту, але використовує підготовлені оператори для розділення запиту. для його параметрів на рівні JDBC). Щоб досягти ін'єкції SQL за допомогою QueryDSL, вам доведеться написати власний аналізатор, щоб розібрати рядок і перекласти його в синтаксичне дерево, і навіть якби ви це зробили, ви, ймовірно, не додали б підтримку таких неприємних речей, як select ... into file. Коротше кажучи, QueryDSL робить неможливим введення SQL-ін'єкцій, а також покращує продуктивність програміста та підвищує безпеку рефакторингу. Попереджений найбільший ризик для безпеки веб-додатків, який існує досить довго, щоб нерестувати запущені пробілкита підвищили продуктивність розробників? Смію сказати, що якщо ви все ще пишете запити як рядки, ви робите це неправильно.

Щодо альтернатив реляційним базам даних, то цікаво знати, що багатоповерховий контроль одночасності управління postgres є саме такою структурою даних, що додається лише про дядька Боба, хоча він, напевно, думав більше про сховища подій та пошук подій картина в цілому, який також прекрасно вписується з поняттям збереження поточного стану в оперативній пам'яті.