Можно ли использовать столбец XML для хранения дополнительных данных?

Если все в порядке и рекомендуется использовать столбец xml для хранения любых дополнительных данных, которые может предоставить пользовательский интерфейс?

Например, предположим, что таблица Employee

CREATE TABLE Employee ( EmployeeId int not null, Name nvarchar(300) not null, Phone varchar(30) null, Email varchar(320) null, Address nvarchar(max) null, Data xml null ) 

Data могут содержать множество значений, таких как дополнительные номера телефонов, комментарии …

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

Мы ожидаем, что данные, хранящиеся в столбце xml, будут редко обращаться к данным. Кроме того, что просмотр просматривается в списке сотрудников, данные могут быть распечатаны. Поэтому нам нужно хранить тип данных по данным (немного похоже на то, что набор данных выполняет сериализацию его данных)

Это хороший подход для хранения неизвестных дополнительных данных?

Отредактировано Хороший пример

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

Вы можете сделать это следующим образом:

 [EmployeeField] ----------------------------------------------------- EmployeeID EmployeeFieldName EmployeeFieldValue 

Это на самом деле тот же подход. .NET Membership использует для профилей пользователей динамические поля. Многие бизнес-приложения используют один и тот же подход для хранения динамических клиентских данных.

Записанный на комментарий Spencer Ruport, этот подход известен как модель Entity-Attribute-Value (EAV) .

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

Если customer – странность, а остальная часть ваших данных в порядке, то, вероятно, это нормально, хотя я бы определенно пошел с подходом EAV. Если большинство ваших таблиц выглядят так, то пришло время пересмотреть подход к хранилищу данных.

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

Я лично предпочитаю добавлять дополнительные, неизвестные данные в виде отдельной таблицы. Это позволяет вам разрешать бесконечное количество опций (просто иметь идентификаторы, имя, тип (? – необязательно) и столбцы данных), но дает дополнительное преимущество, позволяющее выбирать выборочные обновления / удаления.

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

Зависит от данных. Если нелегко моделировать в реляционной структуре, то то, что вы предлагаете (это просто сериализованная LOB ), в порядке.

Если вы хотите использовать данные в запросе, я бы не рекомендовал помещать их в поле xml. Да, есть способы запросить данные из полей xml, но я не нашел их эффективными.

Да, это хорошо. Рекомендуется ли это в значительной степени зависит от вашей конкретной ситуации. Мы делаем что-то подобное с использованием Oracle, и гибкость велика, но наша пользовательская веб-инфраструктура (Java-сервлет, который создает веб-страницы / приложения на основе модулей, написанных на основе XML) сильно использует XML, и у нас есть конкретные системы для хранения данных в один столбец XML, поэтому мое мнение и опыт основаны на сценариях, где это удобно.

Например (и я знаю, что это может показаться ужасным для людей), если вы собираетесь искать на основе данных внутри вашего XML, это может изначально представлять проблему, потому что запуск XPaths и извлечение данных из XML в каждой строке при каждом поиске массивный удар производительности. У нас есть система, подобная материализованным представлениям, которая использует триггеры и хранимый запрос. Каждый раз, когда строка в basetable (содержащая столбец XML) изменяется, триггеры запускаются, ваш запрос запускается и извлекает данные из XML и вставляет его в реляционную таблицу, которая, в свою очередь, имеет представление о ней, 't изменить реляционные данные (так как это не отражает обратно в XML).

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

Я предполагаю, что вам также придется запрашивать и искать атрибуты Employee в XML.

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

В качестве примечания стороны, сохранение только ИД и ИМЯ для сущности, такой же богатой атрибутами, как и сотрудник, похоже на то, что вы действительно отбрасываете мяч за пределы цели. Вы должны хотя бы добавить общие атрибуты, которые вы ожидаете от большинства клиентов, и полагаться только на расширяемые модели (XML или EAV) для дополнительных атрибутов, которые вы не можете просмотреть.

Обновить

Поскольку мы находимся в этом списке, здесь также содержатся документы SQL CAT по передовым методам XML:

  • Рекомендации XML для Microsoft SQL Server 2005
  • Оптимизация производительности для типа данных XML в SQL Server 2005

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

Поэтому, если ваши дополнительные данные – это всего лишь поля «заметки», и, как правило, у каждого предопределенного заголовка клиента это нормально.

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

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

  • Таблица Valued Параметр против большого XML-документа: ускорение проверки наличия записи
  • Как создать представление или функцию в запросе XML PATH?
  • Разбор XML: строка 1, символ 80, неожиданный конец ввода
  • Вставить XML в деньги
  • Запрос SQL Server XML xpath пустое пространство имен
  • DTD не допускается в XML-фрагментах - xml в sql
  • sql server xml одновременно удаляет два атрибута
  • Преобразование XML-узлов в строки в SQL Server
  • Как получить имя узла ROOT из SQL Server
  • Необходимо выбрать только те значения атрибутов, которые начинаются с «имени» и условной проверки
  • Вложенный элемент FOR XML в SQL Server
  • Interesting Posts

    Таблицы проектов в базе данных SQL

    SQL Server: существует ли какое-либо ограничение производительности для упаковки запроса SELECT в транзакции?

    Получить дату 3 дня назад

    Как я могу принудительно блокировать эскалацию (для устранения проблем с блокировкой) во время тестирования?

    XML-данные запроса SQL-запроса

    Сортировка различных значений строк по десятичному значению

    Префикс SQL T-SQL N для строкового литерала

    Какой самый DRY-подходящий способ выполнить команду SQL?

    Как мы можем расширить правила анализа кода SQLProj, добавив наше собственное правило?

    Мне нужен запрос для нескольких оконных результатов (SQL Server 2012+)

    SQL Server QUOTED_IDENTIFIER Область применения

    Функция Max () не возвращает максимальное значение

    Как удалить дубликаты в таблице SQL с Первичным ключом

    Как отобразить столбец текущей даты, столбца времени, столбца предыдущей даты, столбца времени

    Эффективное сохранение кеша отдельных элементов в огромной таблице БД

    Давайте будем гением компьютера.