Лучший способ сохранить поле типа мути - PullRequest
Новая
       20

Лучший способ сохранить поле типа мути

3 голосов
/ 28 августа 2009

Допустим, у нас есть поле, которое может иметь несколько типов, например: строка или дата или типы данных XML.

Теперь у нас есть два способа сохранить это в базе данных

1 - использование поля с типом строки + поле, определяющее тип: потеря возможности сортировки с учетом типа, требуется приведение

2 - отдельные таблицы (StringValues, DateValues, Decimal, XML ... и т. Д.): Внешний ключ, указывающий на значение + поле, определяющее тип: как-то сложно, производительность

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

Вы что-то имеете в виду?

Примечание 1: Желательно рассмотреть проект на основе MS SQL Server 2008 и Linq2SQL

Примечание 2: Может быть, мы обсудим, как реализовать EAV в другом вопросе, я спрашиваю о EAV в реляционном хранилище.

Примечание 3: типы могут меняться, но не часто

Ответы [ 5 ]

5 голосов
/ 28 августа 2009

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

EAV - нереляционный дизайн. Не существует «правильного» способа сделать это в отношении правильных правил проектирования реляционных баз данных .

Правильный дизайн - хранить каждый атрибут в отдельном столбце таблицы one . Дайте каждому столбцу правильный тип данных и описательное имя. В каждом столбце хранятся только значения одного и того же логического типа.

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

2 голосов
/ 22 сентября 2009

Можете ли вы рассмотреть возможность использования типа данных XML? Если это так, вы можете использовать атрибут / элемент для определения типа. 

<string>My string value</string>
<date>24-Nov-1976</date>

Или, 

<val type="System.String">My string value</val>
<val type="System.Date">24-Nov-1976</val>

SQL Server 2005+ имеет хорошую поддержку индексации XML, которая может удовлетворить ваши потребности.

С точки зрения Linq to SQL вы, вероятно, можете иметь легкий класс, который может сопоставлять типы с определенным типом данных; XML de / serialization может быть вариантом здесь.

2 голосов
/ 22 сентября 2009

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

1 голос
/ 24 сентября 2009

Если число возможных типов невелико , используйте опцию 2 (дополнительные таблицы + внешний ключ) или опцию 3.

Вариант 3: Используйте одну таблицу с полем каждого типа и полем enum, определяющим, какое поле является релевантным.

Если число возможных типов велико или не является постоянным , используйте опцию 1 (строки) - вы можете сохранять даты в строках как YYYY-MM-DD-HH-MM-SS для сохранения сортировки.

1 голос
/ 22 сентября 2009

Я не уверен, что это достаточно подробно, чтобы хорошо ответить на вопрос. Если вы буквально спрашиваете о двух типах case, вы можете также рассмотреть таблицу со столбцом для каждого типа и дискриминатором. «Правильный» ответ может зависеть от особенностей, таких как число поддерживаемых различных типов, ограничения скорости и пространства и т. Д.

Некоторые могут утверждать, что наименее дорогой подход - лучший. В частности, подход, который вы считаете, потребует наименьших затрат для понимания и поддержания (часто ~ 60% от общей стоимости владения).

В отношении всех советов о том, как этого не делать, я согласен , если возможно . С другой стороны, SharePoint является одним из примеров, который показывает, что это не невозможно. Удачи!

...