SQL: Лучшая практика для хранения различных полей в одной таблице

Question

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

----Items
+Item_id
+Item_Type_Id
+Item_Serial
...

----Item_types
+Item_Type_Id
+Item_Name
...

----Item_Fields
+Item_Field_Id
+Item_Type_Id
+Field_Name
...

----Field_Values
+Field_Value_Id
+Item_Field_Id
+Item_Id
+Value
...

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

Какие-нибудь лучшие предложения? Или, возможно, простой (не хранимая процедура) способ объединения таблиц для получения единой информации? Я пытался использовать PIVOT (я использую SQL 2005), но безуспешно.

Спасибо.

Answer 1

Я написал сохраненный процесс, чтобы сделать PIVOT более полезным. Вот источник:

http://dot -dash-dot.com / файлы / pivot_query.sql

и несколько примеров, как его использовать:

http://dot -dash-dot.com / files / pivot_query_examples.sql

Для ваших данных запросом будут просто необработанные данные, объединяющие эти таблицы выше, чтобы получить необработанный список:

set @myQuery = '
 Select Item_Id, Item_Name, Field_Name, Value From ...
';

Тогда ваш вызов pivot_query будет:

exec pivot_query @myQuery, 'Item_Id, Item_Name', 'Field_Name', 'max(Value)'

вот так.

Answer 2

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

• Если вы хотите получить данные для типа, вы можете просто присоединиться к двум таблицам.
• Если вы хотите получить данные для всех типов (со всеми полями), вы можете ВСТУПИТЬ ВСЕ таблицы

---

----Items
+Item_id
+Item_Type_Id
+Item_Common_Field1
+Item_Common_Field1
...

----Item_Type_A
+Item_id
+Item_Type_A_Specific_Field1
+Item_Type_A_Specific_Field2
...

----Item_Type_B
+Item_id
+Item_Type_B_Specific_Field1
...

Answer 3

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

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

В этом примере вы создаете стол предметов, книжный стол и стул.

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

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

Затем вы создаете дополнительные столы для разных типов предметов, стульев и т. Д. Там могут даже быть некоторые совпадения. Например, itembook, itemhardback, itempaperback - это 3 таблицы, используемые для описания книг.

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

Конечно, есть системы, которые делают это так, как вы описываете, но если вы не создаете инструмент, который другие собираются использовать для многих различных проектов, имеет смысл спроектировать систему для поставленной задачи. В противном случае вы попадаете в сверхпроектную ловушку. (ИМХО)

С другой стороны, если вы собираетесь идти в совершенно общем направлении, я предлагаю вам использовать одну из уже существующих систем, которые работают таким образом (инфраструктура сущностей, инфраструктура приложений и т. Д.). с нуля.

Answer 4

Еще один вариант - хранить элементы в формате XML в одном поле. В зависимости от вашего сценария использования, он может работать хорошо. Или не может.

Answer 5

Я не хочу, чтобы меня обвиняли в том, что я всегда использую новейшую бесполезную технологию, но в зависимости от вашего случая использования это может быть хорошим примером для базы данных nosql - Токио, Монго, SimpleDB и т. д. Или, как предложил Developer Art, вы можете просто сериализовать различные поля в один столбец. Это не самое страшное в мире.

Answer 6

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

Но я бы не назвал бы это лучшей практикой. (см. комментарии под вашим вопросом)