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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

---

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

Answer 3

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

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

Примечания:

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

• Наследование в одной таблице
• Наследование бетонного стола

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

Answer 4

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

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

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

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