Хранение мета-базы данных - PullRequest
Новая
       3

Хранение мета-базы данных

1 голос
/ 22 ноября 2011

У меня возникли некоторые разногласия с коллегой по этому вопросу.Прежде всего, среда (гарантированная, не изменится):

  • SQL Server 2008 R2
  • ASP.NET MVC 3
  • C #

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

База данных в базе данных

Я придерживаюсь того мнения, что он должен храниться как коллекция пар ключ-значение (в данном примере таблицаResponseItems): 

+----------+----------+----+-----+
|ResponseId|FormItemId|Name|Value|
+----------+----------+----+-----+

Где ResponseId и FormItemId образуют первичный ключ, ResponseId относится к таблице Response, как таковой: 

+----------+------+------+-------------+
|ResponseId|FormId|UserId|SubmittedDate|
+----------+------+------+-------------+

И FormItemId, относящиеся к таблице FormItem: 

+----------+------+----+-----------------+
|FormItemId|FormId|Type|InstantiationData|
+----------+------+----+-----------------+

Где FormId совпадает с FormId в таблице Response, ссылаясь на таблицу Form, что не так важно иллюстрировать.

Сериализация XML

В ответ я получаю, что сериализация компонентов формы и ответов как XML имеет больше смысла, так что онтребует меньшего объема в терминах таблиц, оставляя только таблицу форм: 

+------+--------+
|FormId|Elements|
+------+--------+

, и все данные экземпляров хранятся в данных XML для каждого элемента формы в Elements.Затем ответы записываются аналогичным образом: 

+----------+------+-------------+----------------+
|ResponseId|UserId|SubmittedDate|ResponseElements|
+----------+------+-------------+----------------+

Короткий вопрос после длинного предисловия

Я думаю, что первая идея более понятна и о ней легче сообщить.Как вы думаете?

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

1 Ответ

3 голосов
/ 22 ноября 2011

Первый подход называется Entity-Attribute-Value (EAV). На мой взгляд, это никогда хороший способ хранения реляционных данных. Вы должны прочитать статью под названием Bad CaRMa , прежде чем принять этот дизайн.

Я также говорю о недостатках EAV в своей презентации Практические объектно-ориентированные модели в SQL и в моей книге Антипаттерны SQL: предотвращение ловушек программирования баз данных .

Из этих двух схем я бы предпочел подход XML. Это в основном шаблон сериализованного LOB Мартина Фаулера.

Вы также можете прочитать Как FriendFeed использует MySQL для хранения данных без схемы . Их подход не является специфичным для MySQL; он будет работать в SQL Server или любой другой СУБД.

...