Проблема с динамическими столбцами SQL Server

Question

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

1. Создать таблицу с общими свойствами в виде столбцов и добавить дополнительный столбец типа Текст для сохранения всех уникальных свойств каждого типа гаджета в формате XML.
2. Создайте таблицу со всеми возможными столбцами во всех типах гаджета.
3. Создайте отдельную таблицу для каждого типа гаджетов.
4. Любой другой лучший способ, который вы рекомендуете?

(Примечание: Число типов гаджетов может расти даже за 100, а)

Answer 1

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

Вариант 2 (разреженная таблица) будет иметь много значений NULL и займет дополнительное пространство. Определение таблицы также потребует обновления, если в будущем будет добавлен другой тип. Не так плохо, но все же больно.

Я использую вариант 1 в производстве (используя тип xml вместо text). Это позволяет мне сериализовать любой тип, полученный из моего общего типа, извлекая общие свойства и оставляя уникальные в столбце XmlProperties. Это можно сделать в приложении или в базе данных (например, хранимой процедуре).

Answer 2

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

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

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

Оставшаяся опция 1, за исключением того, что вместо текста я бы использовал тип SQL-серверов вместо текста, вы можете использовать XQuery в своих хранимых процедурах.

Answer 3

Ваши варианты:

1. Хорошо один.Могли бы даже заставить схему и т. Д.
2. Вы не можете сделать эти столбцы NOT NULL, поэтому вы потеряете некоторую целостность данных
3. Пока вы не разрешаете искать более одного типа гаджетов, это достаточно хорошо, но опция 1 лучше
4. Я хотел бы использовать ORM

Примечание:

Если вы хотели бы сохранить свою базу данных «реляционные», но не боится использовать ORM инструменты, то я хотел бы использовать один , В любом случае вы можете хранить данные (почти) по своему усмотрению, но правильно их обрабатывать до тех пор, пока вы правильно их сопоставляете. См:

• Single Table Inheritance
• Concrete Table Inheritance

Если вам нужно SQL-только решение, то в зависимости от РСУБДА, я бы, вероятно, использовать столбец XML, чтобы хранить все данные, относящиеся к Тип гаджета: вы можете иметь валидацию, легко расширяться с новыми атрибутами. Затем вы можете иметь все в одной таблице, быстро искать по всем общим атрибутам, а также довольно легко искать атрибуты типа одного гаджета.

Answer 4

Если все типы гаджетов имеют множество общих обязательных свойств, которые могут храниться в одной таблице и только несколько дополнительных свойств, вам лучше использовать первый подход: таким образом, вы будете использовать лучшую реляционную схему и облегчите свою жизнь с помощью XML. И не забудьте использовать сборку XML Schema, связывающую XML-столбец с ней: у вас будет полная индексация и возможности XQuery.

Если типы гаджетов имеют очень разных описаний и только 1-3 общих столбца среди 5 или более разных наборов свойств, используйте третий подход.

---

А о ситуации 100+ типов устройств я бы использовать 1-й подход: он обладает гибкостью поддерживаемой с хорошей производительностью и простотой поддержки и дальнейшего развития.