Самый расширяемый дизайн для базы данных

Question

Я разрабатываю программу вместе с базой данных с нуля. Каким будет наилучший дизайн базы данных для следующего сценария (SQL 2008 R2, C #):

Программа будет продаваться различным покупателям с разными потребностями. Вот почему я пытаюсь сделать его максимально расширяемым. в Code-Side я использую DI для архитектуры на основе плагинов.

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

• Создайте дополнительный столбец в обязательных таблицах, в котором будет храниться любая другая информация об объекте в формате XML или CSV, и анализируется в выделенном коде.
• Создайте новую таблицу, которая содержит идентификатор объекта и имеет столбцы пары ключ / значение вместе со столбцом DataType (например, Key="IsPremiumMember", DataType="boolean", value="true"), и проанализируйте его в коде.

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

Answer 1

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

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

Если вселенная возможных столбцов неизвестна, вы можете использовать шаблон «Ключ / Тип / Значение». Как сказал marc_s, он гибкий, но сложнее в кодировании SQL.

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

Answer 2

Вы можете получить некоторые другие полезные идеи здесь ... Какой использовать? EAV или BLOB-объекты в базе данных?

Лично я предпочел бы использовать платформу разработки, которая уже предоставляет полностью работающую схему на основе EAV, или использовать решение на основе RavenDB или Mongo.