Встроенный SQL vs динамический SQL

в настоящее время я делаю *кашель*Oracle*кашель* тема базы данных. Лектор представляет встроенный SQL Как вы получаете другие языки (например, C, C++) для взаимодействия с базой данных (Oracle).

Я сам сделал некоторую работу с базой данных (на mysql), где я использую динамический sql.

поскольку embedded SQL, похоже, ограничен несколькими Oracle и несколькими другими, это больше попытка блокировки, или есть реальная ценность во embedded В SQL?

Edit: Я только что понял, что тот факт, что этот урок был сразу после урока по PL/SQL, может быть важным.

исходный вопрос спросил о параметризованном SQL (теперь заменен на "динамический sql", чтобы улучшить вопрос).

в сторону: Я думаю, что книга ~$30 "SQL и реляционная теория", которую я купил, учит меня больше, чем этот класс базы данных.

6
oracle parameterized sql

2 ответов

Embedded SQL анализируется во время компиляции. Одно из преимуществ заключается в том, что во время компиляции вы также ловите синтаксические ошибки, что может предотвратить некоторые типы неловких ошибок во время выполнения. Это также означает, что уязвимости SQL-инъекций не могут изменить предполагаемый синтаксис SQL во время выполнения.

практически все программисты SQL в наши дни помещают SQL в строки и анализируют эти строки во время выполнения. Это исходное определение динамического SQL. Это также называется уровнем вызова Интерфейс (CLI).

поскольку это так часто использовать SQL таким образом, новое определение для "динамического SQL" стало общим использованием, т. е. люди используют этот термин для SQL-запросов, которые они создают условно на основе логики приложения и переменных, в отличие от фиксированной строки в их приложении, которая определяет весь запрос.

параметризованные запросы-это совершенно независимое различие. Вы можете поместить заполнители параметров в embedded или dynamic язык SQL.

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

  • Oracle 11g по-прежнему поддерживает различные SQL прекомпиляторы.
  • в IBM с DB2 UDB в 9.7 поддержка в SQL препроцессор называется PREP.
  • Microsoft SQL Server имеет устаревший поддержка встроенного SQL после MS SQL Server 2000.
  • Sybase, как сообщается, также прекратил встроенный SQL (но я не могу найти ссылку на cite).
  • PostgreSQL по-прежнему поддерживает препроцессор ECPG для встроенного SQL.
  • MySQL никогда не поддерживал встроенный SQL.
  • SQLite не поддерживает препроцессор SQL, насколько я знаю.

это объясняет подавляющее большинство рыночной доли РСУБД.

10

У меня тоже есть книга SQL и реляционная теория дейт. Это лучшая книга, которую вы можете прочитать о реляционных концепциях, которые являются нейтральными СУБД. например, проектирование таблиц и написание SQLs, которые реляционно ориентированы, а не основаны на продукте.

однако я нахожу, что книга не слишком практична, когда дело доходит до поддержания производственных систем или в практических ситуациях, когда изменения схемы менее благоприятны. Кроме того, поведение производственных данных и приложений также может имейте влияние на преобразование нормальных форм таблицы, например таблица может начать славно с 3NF, но заканчивает вверх в 1nf к причинам представления. т. е. чем меньше соединений и поисковых таблиц, тем лучше.

тем не менее, это связано с ограничением концепции СУБД на основе таблиц, поэтому в последнее время большое внимание уделяется базам данных ключей/пар NoSQL.

вернемся к вашей теме embedded SQL vs parameterized SQL, сравниваете ли вы написанный SQL в исходных кодах уровня приложения и SQLs, которые находятся на компьютерах баз данных (например, PL/SQL в Oracle)?

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

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

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

надеюсь, что это помогает.

0