2013-01-13 108 views
0

比方說你有一個調查,你需要轉成一個數據庫,然後在Web應用程序使用以下問題:數據庫設計 - 如何存儲VS如何顯示

在過去的週末,其中的你吃了下面?

  • 冰淇淋
  • 沙拉
  • 炸雞

在上面,我們會自動進行連接。但爲了有問題在數據庫意義應將其存放這樣?:

  • 在過去的週末,你吃冰淇淋嗎?
  • 在上個週末,你吃沙拉嗎?
  • 在上個週末,你吃過炸籤嗎?

假設你正在使用的設計像Micheal's,似乎有理由將它們存儲在表像這樣:

[During the last weekend, did you eat ice cream] -> questions_table.question_name 
[Yes/No] -> Option_group_table.option_group_name 
[Yes][No] -> option_choices_table.option_choice_name 
[True or False] -> answers_table.answers_yn 

但如果要你想建立從這些數據將是一個wepage凌亂的顯示:

  • 在上個週末,你吃冰激凌了嗎?
  • 在上個週末,你吃沙拉嗎?
  • 在上個週末,你吃過炸籤嗎?

前端Web應用程序應該照顧這個嗎?通過像正則表達式的一些手段?

Function_to_help_properly_display_string("String") 

,犯人的這一做法似乎是,不同questions.question_names(串)無法處理方式相同。例如:

您在週末下列哪一項?

  • 德國
  • 法國

無法處理方式與我們最初的問題一樣。

還是應該數據庫帳戶爲此可能有更多的列?

[Question table] 
[question.heading] -> During the last weekend, which of the following did you eat?: 
[question.list] -> ice cream 
[question.full] -> During the last weekend, did you eat ice cream? 

的缺點,做這樣的事情是它似乎重複和混亂。

最有可能他們是第三個選項,我不提出,隨時分享吧! 由於提前,

回答

1

我已經做了數據庫設計/ UI設計,調查好幾次,這裏是我使用:

表:問題

領域:question_id,QUESTION_TEXT, display_order,question_type,required

請注意,display_order,question_type和required字段都是UI的提示。我們沒有將問題和答案一起存儲在文本中,但我們已經向Web開發人員提供瞭如何在UI中顯示問題的提示。我們告訴他們應該出現什麼樣的順序,它是什麼樣的問題(複選框/多選 - 或 - 單選按鈕/一個選項),以及是否需要提問。

表:question_options

領域:question_option_id,question_id,option_text,display_order

同樣在這裏的事情。我們對顯示順序和選項文本有一些UI幫助。請注意,對於我們的選項,我們並不會指定UI中會發生什麼。這是在問題層面上進行的。這意味着您可以輕鬆地更改選項的顯示方式(下拉列表,單選按鈕,複選框等)。

另請注意,我們保留加入問題的能力。

表:回答

領域:USER_ID,question_id,question_option_id

這只是告訴我們,對於一個給定的用戶,並且給定的問題,用戶回答什麼。

所有這三種結構都是在數據庫中進行調查的良好開端。 UI自然流暢。您必須編寫查詢/存儲過程才能將數據返回到Web應用程序,但這並不難。

(總的來說,我認爲嘗試使用字符串解析作爲顯示數據庫數據的一部分是不明智的。換句話說,我認爲嘗試使用正則表達式來組成一個問題/回答來顯示是不明智的用戶界面,對數據庫進行建模,你會發現應用程序的其餘部分不會很難編碼。)

相關問題