設計問題ASP.NET C＃

Question

我正在一個網站上工作，在該網站上我具有許多查詢值，例如城市，州，國家/地區，汽車制造商，車型等。 這些值的ID和Description分別有兩個字段。 現在我有一個問題，我應該將它們保留在一個表中，並保留某種區分它們的TypeId類型的字段，還是應該保留在不同的表中。

我的Dataprovider類也將如何，目前我正在考慮擁有一個可以提供所有數據的類。 但是，我覺得此類中有很多方法。

歡迎提出建議。

關於Parminder

Answer 1

相信我，是時候有人說：“嘿，我們可以為城市增加經度/緯度嗎？”您會踢自己，因為這些屬性對汽車品牌和型號毫無意義。

物理上將不相關，不相交的實體分開實際上不會出錯。 因此，我建議使用其他表格。

Answer 2

始終將查找放在自己的表中，以便您可以在相關表上使用有意義的外鍵以實現關系完整性（即“客戶”表中的“國家/地區” ID引用“國家/地區”表中的“國家/地區”）。

您的查找架構也可能在每個實體的基礎上與標准ID /描述有所不同，因此“一刀切”就不是最好的開始方式。

另外，每次查找都只有一個存儲庫/數據提供程序，不要將它們全部混入一個大類中，因為那樣會變得笨拙和不可靠。

Answer 3

我已經看到它同時完成了兩種工作，但是就可發現性而言，我更喜歡為每個數據單獨使用一個表。 維護多個表並不難，並且當您決定需要向其中一個項目添加一兩列時，事情變得容易得多。

Answer 4

我希望您將它們放在單獨的表中，以便於區分。

至於dataprovider類，我建議您使用ORM，而不要決定如何編寫dataprovider類。

Answer 5

確實取決於您是否要出售產品，我會說是的，將它們放在一張桌子中，並具有某種TypeID來區分產品類型。 例如，如果您要出售商品，則TypeID可以是Automotive，Education等。

但是，如果您要處理用於特定目的的不同實體，而每個實體之間並沒有真正的聯系，那么分離是不錯的選擇。 我們需要更多信息來幫助您：)。

Dataprovider可以是一類，即您的數據訪問層，並且您可以有很多方法都沒關系。 那是很正常的。

Answer 6

城市，州，國家似乎是不同的實體。

因此最好將這些詳細信息保留為單獨的主表。

如果存在任何關系，則使用外鍵將它們關聯。

如果將要進行任何更改或更新，這將減少將來的開銷，並且如果這些開銷都在一個表中，那么還將減少對數據庫的負載。

編寫一個單獨的DBProvider來執行SP，即席查詢

並且還創建了單獨的BusinessModel來表示每個表，這些表就與DBProvider和客戶端的前端進行交互。

那應該是好的，完美的設計策略。

Answer 7

這取決於這些實體的方案和域。 可以說在設計時，如果您不知道要使用的實體類型，那么TypeId方法會更好，這樣，當添加新類型時，您不必為其創建另一個實體。 但是，如果在設計時確定了實體域（您將擁有哪些實體），則將它們保存在單獨的表中，以便可以更有效地優化搜索。

但是，請考慮是否需要更新實體的屬性（添加，編輯，刪除等），因此，如果將它們保留在一個表中，則更新可能會影響所有其他屬性。 如果以后需要與表添加關系，該怎么辦？ 所有不相關的實體也可以繼承關系。

Answer 8

關於您的Dataprovider類-如果它太大，則可以將其視為代碼異味 ，通常認為這是一種不好的做法。 確定多大太大有點主觀。

從文章：

大班：已經變得太大的班，請看上帝的對象 。

Answer 9

如果您認為隨着時間的推移，不同類型的數據將獲得不同的屬性，則將它們分別放在自己的表中。 但是，如果您認為它們始終都將僅作為Id和Description保留，那么為簡單起見，請將它們全部與TypeId放在同一表中。

我同意其他建議使用第三方數據訪問或OR / M組件的答案，例如LINQ-to-SQL，NHibernate，SubSonic，LLBLGen Pro等。