Porady dotyczące schematu bazy danych do przechowywania pól formularzy i wartości pól

Question

Zostałem poproszony o stworzenie aplikacji, która umożliwia użytkownikom wprowadzanie danych do formularza internetowego, który zostanie zapisany, a następnie ostatecznie użyty do wypełnienia pól formularza PDF.

Mam problem z próbą wymyślenia dobrego sposobu przechowywania wartości pól w bazie danych, ponieważ formularze będą dynamiczne (na podstawie pól pdf).

W samej aplikacji będę przekazywał dane dookoła tablicy mieszającej (nazwa pola, wartość pola), ale nie wiem, jak najlepiej przekonwertować wartości mieszania na db.

Używam formularzy internetowych MS SQL 2000 i asp.net. Czy ktoś pracował nad czymś podobnym?

Answer 1

Czy rozważali Państwo zastosowanie tutaj bazy danych dokumentów? Jest to problem, który rozwiązują znacznie lepiej niż tradycyjne rozwiązania RDBMS. Osobiście jestem wielkim fanem RavenDb. Kolejną całkiem przyzwoitą opcją jest CouchDb. Uniknąłbym MongoDb, ponieważ to naprawdę nie jest bezpieczne miejsce na dane w jego obecnej implementacji.

Nawet jeśli nie można korzystać z bazy danych dokumentów, można udawać, że SQL to taki, konfigurując tabele tak, aby miały pewne metadane w tradycyjnych kolumnach z polem danych, które jest serializowane XML lub json. Dzięki temu możesz wyszukiwać metadane, pozostając poza obszarem EAV. Ziemia EAV to okropne miejsce.

UPDATE

Nie jestem pewien, czy to dobry przewodnik istnieje, ale koncepcja jest dość prosta. Podstawową ideą jest rozbicie części, które chcesz przesłać, na "normalne" kolumny w tabeli - dzięki temu możesz wyszukiwać w standardowy sposób. Po znalezieniu rekordów, które chcesz, możesz pobrać CLOB i deserializować go odpowiednio. W twoim przypadku trzeba stół, który wyglądał mniej więcej tak:

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

Kilka protips:
a) użyć tekstu na podstawie rutynowych serializacji. Daje ci szansę na naprawę błędów w danych i naprawdę pomaga w debugowaniu.
b) W przypadku SQL 2000, możesz rozważyć zerwanie CLOB (pole TEKST zawierające dane ładunku) w osobnej tabeli. Dawno nie używałem SQL 2000, ale moje wspomnienia polegają na używaniu kolumn TEKSTU do tabel.

Answer 2

Sugeruję mirroring taką samą strukturę:

Form 
----- 
form_id 
User 
created 

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

Answer 3

Roztwór do czego opisujące nazywa Entity Attribute Value (EAV) i model ten może być królewski ból do czynienia. Powinieneś więc ograniczyć w maksymalnym stopniu swoje wykorzystanie tego.

Na przykład istnieją pola, które prawie zawsze znajdują się w formularzach (imię, nazwisko, adres e-mail itp.), A następnie należy je umieścić w tabeli jako pola.

Powodem tego jest, ponieważ nie jeśli nie ktoś prędzej czy później będzie sobie sprawę, że mają te nazwiska i e-maile i poprosi, aby zbudować ten zapytanie

 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' 
     .... 

kiedy mogłeś to napisane

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

uzyskać także poza SQL 2000 tak szybko jak to możliwe, ponieważ masz zamiar naprawdę brakuje klauzuli UNPIVOT

Jest także strona nie jest to zły pomysł, aby spojrzeć na poprzednie SO EAV questions, aby dać wyobrażenie o problemach, które ludzie napotkali w przeszłości