Рекомендации по схеме базы данных для хранения полей формы и значений полей

Question

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

У меня проблемы с попыткой придумать хороший способ хранения значений полей в базе данных, так как формы будут динамическими (основанными на полях pdf).

В самом приложении я передам данные в хеш-таблицу (fieldname, fieldvalue), но я не знаю, как лучше всего преобразовать хэш в значения db.

Я использую веб-формы MS SQL Server 2000 и asp.net.Кто-нибудь работал над чем-то похожим?

Answer 1

Рассматривали ли вы использование базы данных документов здесь?Это как раз та проблема, которую они решают намного лучше, чем традиционные решения СУБД.Лично я большой поклонник RavenDb .Еще один довольно приличный вариант - CouchDb .Я бы избегал MongoDb, так как он действительно не является безопасным местом для данных в его текущей реализации.

Даже если вы не можете использовать базу данных документов, вы можете сделать так, чтобы SQL притворился единым целым, настроив в ваших таблицах несколько метаданных в традиционных столбцах с полем полезной нагрузки, которое является сериализованным XML или json.Это позволит вам выполнять поиск по метаданным, находясь вне EAV-земли.Земля EAV - ужасное место.

ОБНОВЛЕНИЕ

Я не уверен, что существует хороший гид, но концепция довольно проста.Основная идея состоит в том, чтобы разбить части, по которым вы хотите выполнить запрос, на «нормальные» столбцы в таблице - это позволяет выполнять запросы стандартными способами.Когда вы найдете нужные записи, вы можете взять CLOB и десериализовать его соответствующим образом.В вашем случае у вас будет таблица, которая выглядит примерно так:

SurveyAnswers
  Id INT IDENTITY
  FormId INT
  SubmittedBy VARCHAR(255)
  SubmittedAt DATETIME
  FormData TEXT

Несколько подсказок:
a) используйте текстовую подпрограмму сериализации.Дает вам реальную возможность исправить ошибки в данных и действительно помогает при отладке.
b) В SQL 2000 вы можете рассмотреть возможность разбивки CLOB (поля TEXT, содержащего ваши полезные данные) в отдельную таблицу.Прошло много времени с тех пор, как я использовал SQL 2000, но, насколько я помню, столбцы TEXT плохо влияли на таблицы.

Answer 2

Решение для того, что вы описываете, называется Значение атрибута сущности (EAV), и с этой моделью может возникнуть огромная боль.Поэтому вы должны максимально ограничить использование этого.

Например, есть ли поля, которые почти всегда находятся в формах (Имя, Фамилия, Электронная почта и т. Д.), Тогда вы должны поместить их в таблицу какполя.

Причина этого в том, что если вы не знаете, кто-то рано или поздно поймет, что у них есть эти имена и электронные письма, и попросит вас создать этот запрос

     SELECT 
        Fname.value fname,
        LName.Value lname,
        email.Value email,
        ....
     FROM  
         form f
         INNER JOIN formFields fname
         ON f.FormId = ff.FormID
            and AttributeName = 'fname'      
         INNER JOIN formFields lname
         ON f.FormId = ff.FormID
            and AttributeName = 'lname'
         INNER JOIN formFields email
         ON f.FormId = ff.FormID
            and AttributeName = 'email'
         ....

, когда вымог бы написать это

    SELECT 
        common.fname,
        common.lname,
        common.email,
        ....
     FROM  
         form f
         INNER JOIN common c
         on f.FormId = c.FormId

Также выйдите из SQL 2000, как только сможете, потому что вы действительно пропустите предложение UNPIVOT

Еготакже, вероятно, неплохая идея взглянуть на предыдущие SO EAV вопросы , чтобы дать вам представление о проблемах, с которыми люди сталкивались в прошлом

Answer 3

Я бы предложил отражать ту же структуру:

Form
-----
form_id
User
created

FormField
-------
formField_id
form_id
name
value