Настройка полуструктурированной базы данных для ASP.NET 3.5 - PullRequest
Новая
       5

Настройка полуструктурированной базы данных для ASP.NET 3.5

1 голос
/ 08 марта 2011

Как лучше всего настроить базу данных для небольшого веб-сайта типа «управление контактами»? Он будет использоваться только для внутренних целей (интрасеть), и я использую ASP.NET 3.5 и SQL Server.

В базе данных хранится информация о людях, с которыми мы общаемся, о компаниях, в которых они работают, и т. Д. Многие люди могут работать в одной и той же компании (n: 1), но люди могут также работать в нескольких компаниях (n: m). Люди могут иметь несколько адресов электронной почты и телефонных номеров. Компании могут иметь несколько офисов в разных местах и ​​т. Д. Структура базы данных должна быть достаточно гибкой, чтобы добавить новые поля на более позднем этапе.

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

  • Очень классическая, другая таблица для разных предметов (людей, компаний), с множеством полей, таких как "email1", "email2" и таблицами, связывающими темы (над чем работают люди в каких компаниях), когда может быть n: м отношений. Дополнительные поля («email3») могут быть добавлены позже без проблем. Будет много пустых полей, так как вы должны учитывать максимальное количество адресов электронной почты, которое может иметь любой человек.
  • Отдельные таблицы для таких вещей, как адреса электронной почты, которые ссылаются на таблицу людей. Может быть проблематично, если (например) оригинальному дизайну требуется только один телефонный номер, и позже будет принято решение обрабатывать телефонные номера, такие как адреса электронной почты, в отдельной таблице. Может закончиться большим количеством разных столов. Но дизайн относительно компактен (несколько пустых полей).
  • Модель списка смежностей, где каждое свойство имеет свою собственную запись в таблице и идентификатор указателя на основную запись. Например, имя, адрес, все адреса электронной почты, все номера телефонов и т. Д. Хранятся в виде отдельных записей, указывающих на одну и ту же основную личную запись. В базе данных вообще не будет пустых полей, и в дальнейшем будет много свободы для дополнительных структур.
  • Все данные, хранящиеся в виде XML в базе данных SQL Server (используя тип данных XML)?
  • Или просто простые XML-файлы?

1 Ответ

0 голосов
/ 08 марта 2011

Я бы предложил реляционную базу данных.Ваш проект кажется достаточно простым, чтобы иметь дело с правильными таблицами с правильными отношениями.Я бы держался подальше от XML, поскольку данные будут согласованными.XML лучше подходит для данных с непредсказуемыми структурами, такими как, например, семейное древо.База данных будет работать лучше, и ее будет легче поддерживать.Кроме того, проще составлять отчеты по данным, когда они находятся в RDB, а не в формате XLM.Рекомендуется кодировать с учетом масштабируемости.Если вы управляете контактами, я могу гарантировать, что в какой-то момент им понадобится несколько телефонов.

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

...