Tư vấn lược đồ cơ sở dữ liệu để lưu trữ trường mẫu và giá trị trường

Question

Tôi đã được giao nhiệm vụ tạo ứng dụng cho phép người dùng nhập dữ liệu vào biểu mẫu web sẽ được lưu và sau đó được sử dụng để điền vào các trường biểu mẫu pdf.

Tôi đang gặp khó khăn khi cố gắng nghĩ ra cách tốt để lưu trữ giá trị trường trong cơ sở dữ liệu vì các biểu mẫu sẽ động (dựa trên các trường pdf).

Trong bản thân ứng dụng, tôi sẽ chuyển dữ liệu xung quanh trong bảng băm (tên trường, giá trị trường) nhưng tôi không biết cách tốt nhất để chuyển đổi giá trị băm thành giá trị db.

Tôi đang sử dụng MS SQL server 2000 và asp.net webforms. Có ai làm việc về một cái gì đó tương tự?

Answer 1

Bạn đã xem xét sử dụng cơ sở dữ liệu tài liệu ở đây chưa? Đây chỉ là vấn đề mà họ giải quyết tốt hơn nhiều so với các giải pháp RDBMS truyền thống. Cá nhân, tôi là người hâm mộ lớn của RavenDb. Một lựa chọn khá khác là CouchDb. Tôi muốn tránh MongoDb vì nó thực sự không phải là một nơi an toàn cho dữ liệu trong thực hiện hiện tại của nó.

Thậm chí nếu bạn không thể sử dụng cơ sở dữ liệu tài liệu, bạn có thể làm cho SQL giả vờ là một bằng cách thiết lập bảng của bạn để có một số siêu dữ liệu trong cột truyền thống với trường tải trọng được tuần tự hóa XML hoặc json. Điều này sẽ cho phép bạn tìm kiếm trên siêu dữ liệu trong khi ở ngoài vùng đất EAV. EAV-land là một nơi kinh khủng.

CẬP NHẬT

Tôi không chắc liệu hướng dẫn tốt có tồn tại hay không, nhưng khái niệm này khá đơn giản. Ý tưởng cơ bản là chia nhỏ các phần bạn muốn truy vấn thành các cột "bình thường" trong bảng - điều này cho phép bạn truy vấn theo cách thức tiêu chuẩn. Khi bạn tìm thấy (các) bản ghi bạn muốn, bạn có thể lấy CLOB và deserialize nó khi thích hợp. Trong trường hợp của bạn, bạn sẽ có một bảng trông giống như:

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

Một vài protips:
a) sử dụng một thói quen serialization dựa trên văn bản. Cung cấp cho bạn một cơ hội chiến đấu để sửa lỗi dữ liệu và thực sự giúp gỡ lỗi.
b) Đối với SQL 2000, bạn có thể muốn xem xét vi phạm CLOB (trường TEXT giữ dữ liệu tải trọng của bạn) vào một bảng riêng biệt. Nó được một thời gian dài kể từ khi tôi sử dụng SQL 2000, nhưng hồi ức của tôi là sử dụng các cột văn bản đã làm những điều xấu cho bảng.

Answer 2

tôi muốn đề nghị phản ánh cấu trúc giống nhau:

Form 
----- 
form_id 
User 
created 

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

Answer 3

Giải pháp cho những gì bạn đang mô tả được gọi là Entity Attribute Value (EAV) và mô hình này có thể là một nỗi đau của hoàng gia để đối phó với. Vì vậy, bạn nên hạn chế càng nhiều càng tốt sử dụng của bạn về điều này.

Ví dụ: có các trường gần như luôn ở dạng (Tên, Họ, Email, v.v.) thì bạn nên đặt chúng trong bảng dưới dạng trường.

Lý do cho điều này là bởi vì nếu bạn làm không ai đó sớm hay muộn sẽ nhận ra rằng họ có những cái tên và email và yêu cầu bạn xây dựng truy vấn này

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

khi bạn có thể viết này

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

cũng nhận được off của SQL 2000 càng sớm càng tốt vì bạn sẽ thực sự bỏ lỡ mệnh đề UNPIVOT

của nó cũng p không phải là ý tưởng tồi để xem trước SO EAV questions để cung cấp cho bạn ý tưởng về các sự cố mà mọi người gặp phải trong quá khứ