Насколько важна переносимость SQL?

Question

Мне кажется, как из личного опыта, так и из вопросов и ответов, что реализации SQL существенно различаются. Одна из первых проблем с вопросами по SQL: какие базы данных вы используете?

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

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

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

Answer 1

Я голосую против стандартного / независимого поставщика sql

• Редко база данных фактически переключается.
• Нет единой базы данных, которая бы полностью соответствовала текущему стандарту sql. Таким образом, даже если вы соответствуете стандарту, вы не зависите от поставщика.
• различия между поставщиками выходят за рамки синтаксиса sql. Блокировка поведения отличается. Уровни изоляции разные.
• тестирование базы данных довольно сложно и недостаточно разработано. Не нужно усложнять ситуацию, добавляя в игру нескольких продавцов, если вам это абсолютно не нужно.
• В настройках поставщика есть много возможностей. (подумайте «предел», или «аналитические функции», или «подсказки»)

Итак, квинтэссенция: - Если не требуется независимость от поставщика, обратитесь к поставщику, которого вы фактически используете. - Если есть требование независимости продавца, убедитесь, что тот, кто когда-либо оплачивает счет, будет стоить денег. Убедитесь, что у вас есть все rdbms для тестирования. И использовать это тоже - Поместите каждый кусок SQL в специальный слой, который является подключаемым, чтобы вы могли использовать возможности базы данных и работать с различными поставщиками - Только в том случае, если различие является чисто вопросом синтаксиса, переходите к стандарту, например использование оракуловой записи для (внешних) соединений по сравнению со стандартным синтаксисом ANSI.

Answer 2

Мы очень серьезно относимся к этому в нашем магазине. Мы не допускаем нестандартный SQL или расширения, если они не поддерживаются на ВСЕХ основных платформах. Даже в этом случае они помечены в коде как нестандартные, и необходимы обоснования.

Не разработчик приложения должен выполнять свои запросы быстро, у нас есть четкое разделение обязанностей. Запрос должен быть оптимизирован только за счет самой СУБД или настройки СУБД.

Реальные базы данных, такие как DB2 / z :-), достаточно быстро обрабатывают стандартный SQL.

Причина, по которой мы применяем это, заключается в том, чтобы предоставить клиенту выбор. Им не нравится идея быть привязанным к конкретному поставщику больше, чем нам.

Answer 3

По моему опыту, переносимость запросов не так важна. Мы работаем с различными источниками данных (в основном MSSQL и MySQL), но мы знаем, какие данные хранятся и где можем оптимизировать. Поскольку мы контролируем системы, мы решаем, когда - если когда-либо - структуры будут перемещены, и запросы должны быть переписаны.

Мне также нравится использовать некоторые другие специфичные для сервера функции, такие как уведомление о запросах в SQL Server, которые MySQL не предлагает. Так что, опять же, мы используем его, когда можем, и не беспокоимся о переносимости.

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

Answer 4

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

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

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

Если вы пишете код на PHP, то подавляющее большинство ваших потенциальных клиентов, вероятно, ожидают MySQL. Если это так, то нет ничего страшного в том, чтобы принять MySQL. Или аналогичным образом, если вы находитесь в C # /. NET, то вы можете использовать Microsoft SQL Server. Однако, опять же, есть и обратная сторона, потому что может существовать небольшой, но менее конкурентный рынок пользователей PHP или .NET, которые хотят подключаться к другим системам баз данных, чем обычно.

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