Проектирование базы данных для приложений, не зависящих от базы данных

Question

Что я должен учитывать при проектировании базы данных для нового приложения, которое должно поддерживать самые распространенные системы реляционных баз данных (SQL Server, MySQL, Oracle, PostgreSQL ...)?

Стоит ли даже усилий? Какие подводные камни?

Answer 1

Правило 1: не используйте специфичные для базы данных функции

Правило 2: не используйте хранимые процедуры.

Правило 3: если вы нарушите правило 1, то нарушите и правило 2.

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

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

Answer 2

Наряду с учетом множества хороших и разумных ответов здесь, я бы также добавил, что может быть полезным что-то вроде миграции ActiveRecord (из Ruby On Rails, но вы можете просто использовать библиотеку) , Он абстрагирует такие вещи, как создание / изменение таблиц, соответствующие типы столбцов, более простое управление индексами и (в определенной степени) упорядочение в довольно простой описательный язык.

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

Из любопытства я переключился между Oracle, MS SQL, MySQL и SQLite с одним и тем же набором миграций, и худшая проблема, которую я обнаружил, заключалась в том, чтобы убедиться, что имена моих столбцов и таблиц не находятся в объединении зарезервированных слов. списки по БД.

Answer 3

Исследуйте заранее самый низкий общий знаменатель для типов данных. Например, SQL Server имеет целое число, а Oracle использует число.

Answer 4

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

Для крупных клиентов (больших приложений) они должны полностью зависеть от базы данных. Для небольших настроек действительно сложно иметь Oracle XE и MySQL на одном сервере (или двух).

Действительно, я предпочитаю использовать более одной базы данных, и приложение знает, какая база данных является «абастракальным» кодом.

Answer 5

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

Answer 6

IMO, это зависит от типа разрабатываемого вами приложения:

1. Приложение, которое удовлетворяет другим потребностям, связанным с хранением данных, например, коммерческие сайты, линейка бизнес-приложений, даже приложения для дома / стиля жизни.
2. Приложение, специально разработанное для управления или администрирования баз данных, например, инструменты дизайна, инструменты моделирования, инструменты ETL.

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

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

Answer 7

1. Не использовать хранимые процедуры
2. Не использовать специфичный для поставщика SQL

Или используйте постоянную технологию, такую ​​как hibernate / nHibernate, которая устраняет различия между различными БД.