Как сохранить список элементов в одном столбце в SQL Server 2008

Question

Я ищу эффективный способ хранения информации о пользователях в таблице SQL Server 2008.

В проекте все данные о пользователях будут храниться в виде ряда столбцов в одной таблице, за исключением одного изВ столбцах требуется хранить список значений, например: 'column1' будет хранить username, 'column2' будет хранить userID, а 'column3' будет хранить список элементов, которые со временем изменятся.

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

Какой тип данных мне следует использовать для этого 'column3'?Должен ли я использовать совершенно другой подход?

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

Спасибо.

Answer 1

Как правило, хранение кратных значений в столбце указывает на плохую структуру базы данных. Это очень затрудняет эффективный выбор строк на основе критериев в этом отдельном столбце. Тем не менее, если вам действительно нужно выбирать эти значения только для каждой строки, рассмотрите возможность использования XML, поскольку SQL Server изначально поддерживает данные XML .

Answer 2

Я думаю, вам нужен другой подход.

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

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

Если вы ищете гибкую схему, вы можете рассмотреть подход Entity-Attribute-Value . У этого дизайна есть свои недостатки , но я думаю, что это лучше, чем хранить множество различных типов значений в одном поле.

Answer 3

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

Вот несколько примеров, которые вы можете рассмотреть (отношение схемы пользователь-элемент):

схема многие-многие

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

• даст вамсписок элементов для пользователя без необходимости каких-либо объединений

  пользователь
  идентификатор пользователя
  имя пользователя
  элементы (тип данных xml)

пример схемы отношения один-много

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

• , ограничивающий доступ пользователей к тому жеуникальный элемент

  пользователь
  userID
  userName ListItemID

  List
  ListID
  ListItemID
  ItemID
  Item

пример схемы один - много

• ограничивает пользователей, имеющих один и тот же уникальный элемент

• , не требует от пользователя иметь один или несколько элементов

  Пользователь
  userID
  userName

  Item
  ItemID
  UserID
  Item

много - пример схемы отношения многие

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

• , если данные элемента изменили васпотребуется обновить одну или несколько записей

  UserItems
  UserItemID
  userID
  userName
  ItemID
  Item

пример схемы многие - многие:

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

• если список элементов пользователя изменяется, количество изменений будет равно количеству необходимых обновлений / удалений / вставок

  Пользователь
  userID userName

  ItemList
  ItemListID
  UserID
  ItemID

  Item
  ItemID
  Item

много -пример схемы многих отношений:

• это позволяет пользователям совместно использовать один и тот же уникальный элемент
• требует, чтобы у пользователя был список элементов (один или несколько)
• требуется объединение 3 таблиц для получения информации об элементах, которые есть у пользователей
• если информация пользователя изменяет только 1 запись для обновления
• при изменении данных элемента, только одна записьчтобы обновить

• , если список элементов пользователя изменится, количество изменений будет равно числу необходимых обновлений / удалений / вставок

  Пользователь
  userID userNameListItemID

  Список
  ListID ListItemID
  Идентификатор пользователя
  ItemID

  Item
  ItemID
  Item

Answer 4

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

Если я вас правильно понимаю, и вы хотите сохранить список элементов для каждого пользователя, то для этого потребуется только одна дополнительная таблица, а не "много". Создайте основную таблицу (Users) и таблицу сведений (UserItems) и добавьте столбец внешнего ключа в UserItems, который будет указывать на принадлежащую пользователю запись.

Это правильный способ проектирования отношений сущностей в реляционной базе данных.

Answer 5

Если вы используете PHP или другой такой же способный язык, вы можете сохранить значения в виде списка с разделителями, разделенного специальным символом, таким как трубы ('|') или даже запятыми, если вы уверены, что они победилине отображаются в фактических значениях, которые вы храните.Извлечение значений будет легко (по крайней мере, в PHP) - просто сделайте $var = explode("delimiting_char", $input_string).В конечном итоге, $ var будет массивом значений.delimiting_char будет вашей трубкой или чем-то, что вы хотите использовать.

Надеюсь, это поможет (хотя бы немного)

Answer 6

Вы также можете использовать тип XML.Проверьте здесь для получения дополнительной информации.