Независимость от базы данных

Question

Мы находимся на ранних стадиях разработки приложения большого бизнеса, которое будет иметь несколько модулей. Одним из требований является то, что приложение должно быть независимым от базы данных, оно должно поддерживать SQL Server, Oracle, MySQL и DB2.

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

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

Одним из возможных вариантов дизайна является использование инфраструктуры Entity для уровня базы данных с провайдером для каждой СУБД. Мое личное чувство заключается в том, что запись инструкций SQL вручную без ORM была бы «обязательной», поскольку у вас нет контроля над SQL, сгенерированным инфраструктурой сущности, и для независимого от базы данных сценария потребуется некоторая настройка SQL на основе СУБД, код которой таргетинга, и я думаю, что сторонние поставщики инфраструктуры сущностей будут иметь значительное количество ошибок, которые появляются только в сложных сценариях, которые будут иметь приложения. Я хотел бы услышать от всех, кто ранее имел опыт использования структуры сущностей для независимого от базы данных сценария.

Кроме того, одна из возможностей, обсуждаемых командой, заключается в поддержке одной СУБД (например, SQL Server) на первой итерации, а затем добавлении поддержки других СУБД в последовательные итерации. Я думаю, что, поскольку нам понадобится дизайн базы данных с наименее распространенными функциями, эта стратегия разработки плохая, так как нам нужно знать все функции всех баз данных, прежде чем мы начнем писать код для первой СУБД. Мне также нужно услышать от вас эту возможность.

Answer 1

Я работаю с Hibernate, который дает мне преимущества ORM плюс независимость базы данных. Специфика базы данных не может быть и речи, и это обычно улучшает мой дизайн. Все (модель домена, бизнес-логика и методы доступа к данным) можно тестировать, поэтому разработка не является болезненной.

Answer 2

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

При этом, если вы действительно хотите включить независимость базы данных, лучше всего написать весь код доступа к базе данных с интерфейсами или абстрактными классами, такими как те, которые используются в пространстве имен .NET System.Data.Common (DbConnection, DbCommand и т. д.) или использовать библиотеку O/RM, которая поддерживает несколько баз данных, например NHibernate.

Answer 3

مرحبا, Muhammed!

Независимость базы данных не является ни «хорошим», ни «плохим». Это дизайнерское решение; это компромисс.

Давайте поговорим о выборе:

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

... Проектирование баз данных с наименьшими общими чертами во всех поддерживаемых СУБД
Это, по определению, правда. К счастью, общие функции во всех поддерживаемых базах данных довольно широки; они должны реализовать стандарт SQL-99.

... плохая производительность и плохая масштабируемость Это не должно быть правдой. Слой должен добавить минимальную стоимость в базу данных.

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

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

• Java имеет JDBC drivers
• Python имеет the Python Database API
• .NET имеет ADO.NET

удачи.

Answer 4

Вы посмотрели Comparison of different SQL implementations?

Это интересное сравнение, я считаю, что оно достаточно актуально.

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

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

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

Учитывая такие требования, то практические вопросы включают в себя:

1. , кто будет чемпионом каждой конкретной базы данных для проектирования и разработки? Это важно, поскольку личные предпочтения для реализации каждого из этих людей необходимо согласовать для достижения нейтрального для базы данных решения. Если у конкретной базы данных нет чемпиона, возможно, что реализация приложения в этой базе данных будет плохо выполнена, если вообще.
2. У кого есть глубина базы данных, чтобы действовать как модератор для чемпионов? Этот человек должен будет принимать некоторые жесткие решения время от времени, но horsetrading - часть удовольствия.
3. будет ли команда разработчиков продуктивной без всех своих личных любимых функций? Хранимые процедуры, триггеры и т. Д. Являются наименее переносимыми функциями между RDBM.

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

Компоненты, связанные с использованием базы данных, должны включать все DML или ORM, если вы их используете.

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

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

В общем, проектирование баз данных агностиком приложений является расширение простой заповедью:

---

Инкапсулируйте, что меняется

---