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

Question

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

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

Поскольку встроенный SQL, по-видимому, ограничивается несколькими Oracle и несколькими другими, то является ли это скорее попыткой блокировки, или есть ли реальная ценность во встроенном SQL?

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

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

В сторону: Я думаю, что книга «Теория SQL и реляционная теория» стоимостью ~ 30 долларов США научила меня больше, чем этот класс баз данных.

Answer 1

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

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

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

Параметризованные запросы - это совершенно независимое различие. Вы можете поместить заполнители параметров во встроенный или динамический 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.

На эту долю приходится подавляющее большинство доли рынка СУБД.

Answer 2

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

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

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

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

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

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

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

Надеюсь, это поможет.