[問題] 資料庫正規化的必要性

看板Ajax作者 (小強)時間14年前 (2010/01/04 02:20), 編輯推噓14(14推 0噓 29→)
留言43則, 9人參與, 最新討論串1/7 (看更多)
因為牽扯到JSON所以就來這個版問了 我現在做了一個問卷系統 可以自行增加問題 而問題有很多種type，每一種type的attibute數量都不同 譬如說..單選題需要"答案選項"，但是如果是文字空格就不需要"答案選項"， 我現在的作法是把每一題都視作一個物件，傳進php的時候只需要用json stringfy 傳進去，接著把整個stringfy過後的物件存進table裡面， 而table只有兩個欄位，一個是題號一個是stringfy過後的物件 這樣的好處是，我從資料庫拿出來或存進去都不用做非常複雜的分析 query的時候也非常的簡單 存的時候整個丟進去就好了，要用的時候整個拿出來～ 修改也只要覆蓋原本的～ 我的問題是，有需要把物件裡面的元素拆成個別的attibute嗎？ 譬如說原本的table是 question_num question_obj 兩欄而已 改成 question_num question_content question_notnull qustion_type ..... -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 122.116.233.166 ※ 編輯: tonilin 來自: 122.116.233.166 (01/04 02:20)
→
01/04 09:03, , 1F
正規化不是鐵則 , 你的問題應該是看你有沒有需要對你的obj
01/04 09:03, 1F
→
01/04 09:03, , 2F
做sql層級的成員分析 , 有的話當然是要列出來, 否則不需要
01/04 09:03, 2F
→
01/04 09:03, , 3F
也就是你會不會對question_content question_notnull 查詢
01/04 09:03, 3F
推
01/04 09:15, , 4F
我不懂幹嘛這麼省table,集中在1個table的目的是???
01/04 09:15, 4F
→
01/04 09:26, , 5F
樓上可以去查查反正規化的理由 XD
01/04 09:26, 5F
→
01/04 09:27, , 6F
通常不外乎是資料調用上的方便，效能上的需要，對資料關係
01/04 09:27, 6F
→
01/04 09:28, , 7F
比較不嚴謹的欄位的聚合等
01/04 09:28, 7F
推
01/04 14:44, , 8F
我覺得資料庫還是能byte就不要str,除非是寫給別人用的^^
01/04 14:44, 8F
推
01/04 15:06, , 9F
這case我的正規化是題目和特殊答題方式分兩個網頁編輯...
01/04 15:06, 9F
推
01/04 16:03, , 10F
然後1樣開這個table來加速select(不能忘本呀,交叉分析用)
01/04 16:03, 10F
推
01/04 17:43, , 11F
我個人會用 serialize 來做儲存
01/04 17:43, 11F
→
01/04 17:43, , 12F
當然這適合小量問卷～
01/04 17:43, 12F
→
01/04 17:58, , 13F
嗯嗯我瞭解了..我大概會用原本的方式吧..
01/04 17:58, 13F
→
01/04 17:58, , 14F
畢竟要調用的時候方便多了
01/04 17:58, 14F
→
01/04 18:07, , 15F
而且我不會單獨拿一個問題出來做分析
01/04 18:07, 15F
→
01/04 18:07, , 16F
要拿也是全部拿～所以查詢直接用foreach就好
01/04 18:07, 16F
推
01/04 20:46, , 17F
如果問卷資料人家填完之後就不能改，乾脆用檔案記錄算了
01/04 20:46, 17F
→
01/04 20:46, , 18F
一堆select真的很浪費資源
01/04 20:46, 18F
→
01/04 22:22, , 19F
沒有，這是問卷設計～問卷資料還有別的table來存
01/04 22:22, 19F
推
01/04 23:44, , 20F
那如果是紀錄物件屬性，serialize會比較方便吧？
01/04 23:44, 20F
→
01/04 23:45, , 21F
這樣可以隨程式擴充XDDD
01/04 23:45, 21F
推
01/05 18:23, , 22F
2欄就夠了呀,不管單選複選文字都放同一欄,複選可用位元運算記
01/05 18:23, 22F
→
01/05 18:24, , 23F
如果有其它選項,再讓人填文字,也可以在文字前用符號標示
01/05 18:24, 23F
推
01/06 10:57, , 24F
連連看呢?有沒有人有做過?要當做很多小項的單選或複選嗎?
01/06 10:57, 24F
推
01/06 16:18, , 25F
連連看小弟有做過~正解答案一欄，使用者的答案也一欄
01/06 16:18, 25F
→
01/06 21:48, , 26F
收回來的問卷結果不用做分析嗎？
01/06 21:48, 26F
→
01/06 21:49, , 27F
都用 JavaScript在 client端跑？還是 server端也能parse
01/06 21:49, 27F
推
01/07 02:23, , 28F
輸出表格或是CVS，丟進Excel或是其他比較好用的軟體
01/07 02:23, 28F
推
01/07 02:34, , 29F
啊，那我要建議原po要記得在CSV的每一格都加上 " "
01/07 02:34, 29F
→
01/07 04:43, , 30F
其實我問的只是"問卷的設計"～收回來的結果是放在別的tabl
01/07 04:43, 30F
→
01/07 04:43, , 31F
e～就是一個問卷會產生一個table
01/07 04:43, 31F
→
01/07 04:44, , 32F
這方法我是參考limesurvey的
01/07 04:44, 32F
→
01/08 01:18, , 33F
「一個問卷會產生一個table」我覺得這很有問題
01/08 01:18, 33F
→
01/08 01:25, , 34F
可以請教一下是什麼問題嗎＠＠..因為我看limesurvey也是
01/08 01:25, 34F
→
01/08 01:25, , 35F
這樣做的
01/08 01:25, 35F
→
01/08 09:22, , 36F
看需要跟問題的回覆有沒有標準化 , 不過基本上來講是不會
01/08 09:22, 36F
→
01/08 09:22, , 37F
設計自動繁衍的table的... :3
01/08 09:22, 37F
推
01/08 12:08, , 38F
以前sa規劃過一個問卷一個table...table流水號命名
01/08 12:08, 38F
推
01/08 13:42, , 39F
一個問卷不一個table大量select會不會很浪費資源啊@@?
01/08 13:42, 39F
→
01/08 13:43, , 40F
不過我是建議原po既然問卷不會在你的系統裡編輯
01/08 13:43, 40F
→
01/08 13:43, , 41F
直接存成純文字檔，用append會比較省事一些吧
01/08 13:43, 41F
→
01/08 14:39, , 42F
樓上你先查查 index 是幹嘛用的就知道了 XD
01/08 14:39, 42F
→
01/08 14:39, , 43F
良好索引的table 是不怕查的.
01/08 14:39, 43F
‣ 更多 tonilin 的文章
文章代碼(AID): #1BGD_HKL (Ajax)
討論串 (同標題文章)
以下文章回應了本文：
完整討論串 (本文為第 1 之 7 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共7篇)
‣ 更多 tonilin 的文章
文章代碼(AID): #1BGD_HKL (Ajax)