схема для хранения различных полей varchar с течением времени?

Question

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

Должен ли я пойти на что-то вроде этого (хранилище значений ключей)?

MetaDataField
-----
metaDataFieldID (PK), name

FieldValue
----------
EntityID (PK, FK), metaDataFieldID (PK, FK), value [varchar(255)]

p.s. Я также думал об использовании XML на SQL Server 05+. После разговора с каким-то ппл кажется, что это не жизнеспособное решение, потому что оно будет слишком медленным для выполнения определенного запроса в целях отчетности.

Answer 1

Скорость XML зависит только от размера данных, поступающих в столбец xml. У нас был проект, который вставлял данные и обрабатывал данные из столбца xml. Это было очень быстро ... пока вы не набрали около 64 КБ. 63 КБ и меньше потребовались миллисекунды, чтобы вывести или вставить данные. 64 КБ и операции подскочили до полной минуты. Пойди разберись.

Кроме этого, у нас была сложность. Работа с XML-данными в SQL Server не для слабонервных.

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

Answer 2

Вы правы, вы не хотите менять схему данных каждый раз, когда появляется новый параметр!

Я видел два способа сделать что-то подобное.Во-первых, просто введите текстовое поле «meta» и отформатируйте значение, чтобы определить и параметр, и значение.Joomla!делает это, например, для отслеживания пользовательских свойств статьи.Выглядит это так:

ProductTable
     id   name     meta
    --------------------------------------------------------------------------
     1    prod-a   title:'a product title',desc:'a short description'
     2    prod-b   title:'second product',desc:'n/a'
     3    prod-c   title:'3rd product',desc:'please choose sm med or large'

Другой способ справиться с этим - использовать дополнительные таблицы, например:

ProductTable
     product_id     name   
    -----------------------
     1              prod-a 
     2              prod-b 
     3              prod-c 

MetaParametersTable
     meta_id     name
    --------------------
     1           title
     2           desc

ProductMetaMapping
     product_id     meta_id     value 
    -------------------------------------
     1              1           a product title
     1              2           a short description
     2              1           second product
     2              2           n/a
     3              1           3rd product
     3              2           please choose sm med or large

В этом случае запрос должен объединить таблицы,но вы можете оптимизировать таблицы лучше, можете запрашивать независимую мету, не возвращая все параметры и т. д.

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

Answer 3

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

Answer 4

«Изменение столбцов таблицы позже будет дорогостоящим и подверженным ошибкам, верно?»

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

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

Желание изменить тип данных действительно является дорогостоящей операцией, подверженной нарушению бесперебойной работы бизнес-операций, но, к счастью, довольно редко пользователь приходит к вам, чтобы сказать вам: «Эй, я знаю, что сказал вам этот атрибут Должно быть, Дата, но угадайте, что, я был не прав, это должен быть Поплавок ". И других изменений того же характера, но с большей вероятностью происходящих (например, от сокращения к целому или около того), можно избежать, проявляя осторожность при определении базы данных.

Другие типы изменений в базе данных (например, добавление нового столбца) обычно не так опасны и / или разрушительны.

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

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

Answer 5

Существует также шаблон для рассмотрения - называемый шаблон наблюдения . Смотрите похожие вопросы / ответы: один , два , три .

Этот паттерн описан в книге Мартина Фаулера Аналитические паттерны , по сути, это паттерн OO , но его можно сделать и в схеме БД.