2012-05-29 65 views
0

我被別人指出以下數據庫設計有嚴重問題,誰能告訴我爲什麼?這個數據庫設計有什麼問題?

  1. 一個tb_user表保存所有用戶的信息
  2. tb_user表將有3 - 只有8用戶。
  3. 每個用戶的數據將被保存在一個單獨的表格中,以用戶名稱命名。 假設一個用戶被調用:bill_admin,那麼他有一個單獨的表,即bill_admin_data來保存屬於他的所有數據。所有用戶的數據共享相同的結構。

誰指出了這個問題,說我應該所有的數據合併到一個表,並使用FK來區分他們,但我有以下陳述的人:

  1. 用戶只能3 - 8,所以無論如何都不會有很多桌子。
  2. 每個用戶都有一個非常大的數據表,比如500K記錄。

像這樣設計數據庫是不好的做法嗎?爲什麼?謝謝。

+0

呃!指出這一點的人對你有很大的幫助。這是一個可怕的設計。你可以編輯你的問題,包括實際的表設計?這將使提供建議更容易,例如爲什麼這是一個壞主意。 – JohnFx

回答

5

因爲它不是很好維護。

1)向數據庫添加數據不應該要求修改結構。在你的模型中,如果你需要添加另一個人,你將需要一個新的表格(或兩個)。你可能不認爲你會永遠需要這樣做,但相信我。你會。

因此,假設您想要嚮應用程序添加功能以將新用戶添加到數據庫。有了這個結構,您將不得不爲最終用戶提供創建新表的權限,這會產生安全問題。

2)違反了DRY principle。也就是說,您正在創建相同表結構的多個副本。這使得維護在對接中很痛苦。

3)跨多個用戶查詢將不必要地複雜。沒有很好的理由將每個用戶分成單獨的表格,而不是針對必須針對該數據庫模型編寫查詢的人員的仇恨。

4)如果因爲每個用戶都有很多行而將它拆分爲多個表以提高性能,那麼您正在重新發明輪子。您使用的RDBMS無疑具有索引功能,可以有效查詢大型表格。您的本土黑客不會超越平臺處理大數據的方法。

-1

對於這些類型的需求,使用像mongoDB這樣的基於Document的數據庫是很好的。

+0

這與要求的內容無關。可以說它也不是真的。 – JohnFx

1

我不會說這本身就是糟糕的設計。這只是關係數據庫設計和優化的設計類型。

當然,您可以按照您提到的方式存儲您的數據,但許多操作並不是微不足道的。例如:

  • 添加一個新的人
  • 卸下一個人基於在所有的人

數據

  • 生成報告。如果你真的不關心這樣做。按照你的建議繼續做,儘管我建議使用非關係數據庫,比如MongoDB,它更適合這種類型的結構。

    如果您更喜歡使用關係數據庫,通過按類型聚合數據而不是人員爲添加新用戶和計算報告提供了很大的靈活性。

    500k線不是「非常大」,所以不要擔心在進行設計時的尺寸。