Насколько необходимо или удобно писать переносимый SQL?

Question

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

Вы действительно выиграли от написания переносимого SQL и отказа от проприетарных инструментов / синтаксиса вашего диалекта?

Я никогда не видел, чтобы кто-то изо всех сил пытался создать сложное приложение на mysql, а затем говорил Вы знаете, что было бы просто замечательно? Давайте переключимся на (PostGreSQL | Oracle | SQL Server)!

Общие библиотеки в -say- PHP делают абстрактные тонкости SQL, но какой ценой? В конечном итоге вы не сможете использовать эффективные конструкции и функции, поскольку вы, вероятно, никогда не будете использовать предполагаемый проблеск переносимости. Для меня это звучит как учебник ЯГНИ.

РЕДАКТИРОВАТЬ: Может быть, пример, который я упомянул, является слишком странным, но я думаю, что суть остается: если вы планируете переход с одной СУБД на другую, вы, вероятно, все равно перепроектируете приложение, или вы не захотите вообще не буду.

Answer 1

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

Когда вы работаете на предприятии, вы можете воспользоваться знаниями платформы.

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

Answer 2

Единственный случай, когда я вижу в этом необходимость, - это когда вы создаете программное обеспечение, которое клиент будет покупать и использовать на своих собственных системах. Безусловно, большинство программ не попадают в эту категорию. Отказ от использования кода, специфичного для поставщика, означает, что у вас есть частично выполняемая база данных, поскольку код, специфичный для поставщика, обычно пишется для повышения производительности определенных задач по сравнению со стандартом ANSII SQL, а также для того, чтобы учитывать особенности конкретной архитектуры этой базы данных. Я работал с базами данных более 30 лет и никогда еще не видел, чтобы компания меняла свою базу данных без полной переписывания приложений. В этом случае исключение кода, специфичного для поставщика, означает, что вы в большинстве случаев наносите ущерб своей производительности без каких-либо причин.

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

Answer 3

Проблема с расширениями заключается в том, что вам нужно обновлять их при обновлении самой системы баз данных. Разработчики часто думают, что их код будет длиться вечно, но большая часть кода должна быть переписана в течение 5-10 лет. Базы данных, как правило, живут дольше, чем большинство приложений, поскольку администраторы достаточно умны, чтобы не исправлять вещи, которые не сломаны, поэтому они часто не обновляют свои системы с каждой новой версией.
Тем не менее, когда вы обновляете свою базы данных до более новой версии, но расширения не совместимы с этой и, следовательно, не будут работать. Это значительно усложняет обновление и требует переписывания большего количества кода.
Когда вы выбираете систему баз данных, вы часто застреваете с этим решением годами.
Когда вы выбираете базу данных и несколько расширений Вы застряли с этим решением на много, очень долго!

Answer 4

Всегда есть некоторые преимущества и некоторые затраты на использование диалекта языка с наименьшим общим знаменателем для обеспечения переносимости. Я думаю, что опасность привязки к конкретной СУБД невелика по сравнению с аналогичными опасностями для программирования языков, библиотек объектов и функций, составителей отчетов и т. П.

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

Если вы не понимаете различия между логическим моделированием и физическим моделированием, изучите его.

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

С точки зрения обработки SQL CRUD внутри приложения, при необходимости используйте специфические конструкции СУБД, но старайтесь сохранять их документированными. Например, я без колебаний использую конструкцию Oracle «CONNECT BY» всякий раз, когда я думаю, что она принесет мне пользу. Если ваше логическое моделирование было независимым от СУБД, большая часть CRUD SQL также будет независимой от СУБД даже без особых усилий с вашей стороны.

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

(Слово «вы» в приведенном выше относится к тому, кого это может касаться, а не к ОП в частности.)

Answer 5

• Если вы корпоративный, то вы используете платформу, которую вам дали
• Если вы поставщик, вы должны планировать несколько платформ

Долговечность для корпоративных:

• Вы, вероятно, перепишете код клиента перед миграцией СУБД
• СУБД, вероятно, переживет ваш клиентский код (Java или c # против мэйнфрейма '80)

Помните:

SQL на платформе обычно обратно совместим, а клиентские библиотеки - нет. Вы вынуждены выполнить миграцию, если ОС не может поддерживать старую библиотеку, или среду безопасности, или архитектуру драйвера, или 16-битную библиотеку и т. Д.

Итак, предположим, что у вас было приложение на SQL Server 6.5. Он все еще работает с несколькими изменениями в SQL Server 2008. Могу поспорить, что вы не используете вменяемый код клиента ...

Answer 6

В подавляющем большинстве приложений я бы поспорил, что польза практически отсутствует, и даже отрицательный эффект от попытки написать переносимый sql; однако в некоторых случаях существует реальный вариант использования. Предположим, вы создаете веб-приложение для отслеживания времени. И вы хотели бы предложить самостоятельное решение.

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