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

Question

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

Вспомни:

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

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

Answer 6

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

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

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

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

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

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

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