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

В конечном счете, я не понимаю, к чему он стремится. Он говорит заменить SQL технологиями без SQL? Он говорит хранить данные в файлах в файловой системе? Или он просто хочет, чтобы люди прекратили использовать SQL / реляционные базы данных из-за SQLi-атак? Боюсь, мне не хватает того, что он пытается сделать.

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

1. Бобби Столы
2. Лекция «Чистая архитектура»

Во-первых, он заявляет, что SQL должен быть полностью удален из системы.

Решение. Единственное решение. Это исключить SQL из системы полностью. Если нет механизма SQL, тогда не может быть никаких атак SQLi.

И хотя он говорит о замене SQL на API, я НЕ думаю, что он имеет в виду поместить SQL за API из-за этой предыдущей цитаты и того, что он сказал ранее в этой статье.

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

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

Если SQL не используется для сохранения данных, то что мы должны использовать?

Прежде чем ответить на это, я должен также отметить. Роберт подчеркивает, что твердотельные накопители должны изменить инструменты, которые мы используем для сохранения данных. Ответ Сёрена Д. Птюса указывает на это.

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

Я не могу найти вопрос, который охватывает все это. Я думаю, я ищу альтернативы, которые соответствуют рекомендациям Роберта. Datomic один, но это так? Какие другие варианты соответствуют этим рекомендациям? И действительно ли они лучше работают с твердотельными накопителями?

Боб Мартин явно преувеличивает, чтобы прояснить свою точку зрения. Но в чем его смысл?

Он просто хочет, чтобы люди прекратили использовать SQL / реляционные базы данных из-за SQLi-атак?

Насколько я понимаю, в этом посте (ваша первая ссылка) Мартин пытается убедить людей прекратить использовать SQL, а не реляционные базы данных. Это две разные вещи .

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

Тем не менее, эта возможность требует затрат : написание безопасных SQL-запросов / команд сложнее, чем написание небезопасных. Безопасный API должен облегчать создание безопасных запросов «по умолчанию». Потенциально небезопасным нужно больше умственных или, по крайней мере, больше печатных усилий. ИМХО, почему Мартин разглагольствует против SQL в его нынешнем виде.

Проблема не нова, и есть более безопасные API, чем стандартный SQL, для доступа к реляционной базе данных. Например, все известные мне операторы OR пытаются предоставить такой API (хотя обычно они предназначены для других основных целей). Варианты статического SQL затрудняют создание любых динамических запросов с неанизированными входными данными (и это не новое изобретение: встроенному SQL, который часто использует статический SQL, около 30 лет).

К сожалению, я не знаю ни одного API, который был бы таким же гибким, стандартизированным, зрелым, независимым от языка и мощным, как SQL, особенно динамический SQL. Вот почему у меня есть некоторые сомнения по поводу предложения Мартина «не использовать SQL» в качестве реалистичного способа решения упомянутых проблем. Поэтому читайте его статью как мысль в правильном направлении, а не как «лучшую практику», которой вы можете слепо следовать с завтрашнего дня.

Мнение Боба Мартина именно это; мнение одного человека.

Предполагается, что программист понимает систему, которую он пишет, достаточно хорошо, чтобы проявлять разумную заботу о ее безопасности и производительности. Это означает, что если вы говорите с базой данных SQL, вы делаете то, что говорит веб-сайт Bobby Tables : вы дезинфицируете свои входные данные. Это означает, что вы размещаете свою базу данных SQL на машине, которая обещает адекватную производительность. Есть очень хорошо известные и понятные способы сделать это, и хотя они не гарантируют абсолютную безопасность или идеальную производительность, они не делают ничего другого.

Утверждение, что нам больше не нужен SQL, потому что у нас теперь есть твердотельные накопители, является просто ложным. SQL не был изобретен, потому что высокоскоростных жестких дисков еще не было; он был изобретен, потому что нам нужен был стандартный для отрасли способ выражения концепций извлечения данных. Системы реляционных баз данных обладают многими другими качествами, помимо скорости и безопасности, что делает их идеальными для бизнес-операций; в частности, КИСЛОТА . Целостность данных, по крайней мере, так же важна, как скорость или безопасность, и если у вас ее нет, то какой смысл защищать плохие данные или извлекать их как можно быстрее?

Прежде чем принять истерию одного человека за Евангелие, я предлагаю вам ознакомиться с безопасностью и производительностью приложений и систем на их собственных условиях, а не читать случайные статьи в Интернете. Безопасность, производительность и надежная конструкция системы - это гораздо больше, чем просто «избегать этой технологии».

Мы не запрещаем кухонные ножи, потому что нескольким несчастным людям удается случайно порезать им пальцы.

Что он на самом деле говорит?

Он говорит заменить SQL технологиями без 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, хорошо масштабируется и т. Д., Может быть глупо пытаться обходиться без такового или писать для конкретного приложения).

Требования rant удовлетворяются, если SQL API базы данных скрыт от разработчиков приложений за каким-либо другим 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 Perl для кода ruby ​​on rails. Код рельсов, который он предоставляет, легко перепутать между безопасным и небезопасным. Как и многие ORM, скрывает то, что находится под SQL, и так часто вы имеете дело с интерфейсом, который создает и выполняет SQL для вас. Разве это не похоже на то, что API сделает для вас?

Моя интерпретация первого упоминания заключается в том, что он предлагает заменить хорошо известную проблему, решение которой хорошо известно.

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

Он частично прав, в конечном итоге у нас будет бесконечно большая и быстрая память и бесконечно быстрый процессор. Пока мы не ускользнем от текущей физики, которая ограничивает вычисления, он не прав.

Да, вращающиеся диски остались в прошлом, и теперь мы используем твердотельные накопители. Диски работают с ~ 10 миллисекундами на передачу данных, SSD работают с ~ 0,5 миллисекундами (500 мкс) времени доступа к данным. Объем оперативной памяти составляет порядка 100 наносекунд, процессоры работают на порядка 100 секунд пико-секунд. Это суть того, почему нам нужны базы данных. Базы данных управляют передачей данных между вращающимися дисками или твердотельными накопителями с основной памятью. Появление SSD не устранило необходимость в базах данных.

Ответ

он просто хочет, чтобы люди прекратили использовать SQL / реляционные базы данных из-за SQLi-атак?

Статья «Таблицы Бобби», кажется, предполагает, что это, само по себе является причиной не использовать SQL:

Решение. Единственное решение. Это исключить SQL из системы полностью. Если нет механизма SQL, тогда не может быть никаких атак SQLi.

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

отступление

Эта часть на самом деле не является ответом, но я думаю, что вопрос о значении SQL гораздо интереснее (как, впрочем, и другие).

У меня большой опыт использования SQL, и я думаю, что у меня есть четкое представление о его сильных и слабых сторонах. Мое личное ощущение, что этим злоупотребляют и злоупотребляют, но мысль о том, что мы никогда не должны его использовать, глупа. Идея, что мы должны выбрать «SQL всегда» или «SQL никогда», является ложной дихотомией.

Поскольку инъекция SQL является аргументом в пользу неиспользования SQL, это смешно. Это хорошо понятная проблема с довольно простым решением. Проблема с этим аргументом в том, что SQLi не единственная существующая уязвимость. Если вы думаете, что использование JSON API делает вас безопасным, вас ждет большой сюрприз.

Я думаю, что каждый разработчик должен посмотреть это видео под названием «Пятница, 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();

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

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