怎麼定義某些欄位的歸屬模組?

在設計商品模組的時候,有一個需求是某一些商品是不能參加活動的。這個時候設計商品模型的時候就又兩種選擇：

• 將限購這個屬性放到商品模型上,歸商品模組維護

• 商品模組不管這個限購屬性,由活動模組記錄限購，維護一份限購商品Id表

個人覺得這兩種方式都可以,但是如果把限購這個屬性放到商品模型上得話,以後這種特殊屬性越來越多的話,會導致商品模型無限膨脹。所以如果由促銷來管理這個關係的話,商品模型上就只有一些簡單的屬性,這個基礎服務就會更加的乾淨。

請問有沒有一些經驗或者準則可以參考一下？謝謝。

回複內容：

在設計商品模組的時候,有一個需求是某一些商品是不能參加活動的。這個時候設計商品模型的時候就又兩種選擇：

• 將限購這個屬性放到商品模型上,歸商品模組維護

• 商品模組不管這個限購屬性,由活動模組記錄限購，維護一份限購商品Id表

個人覺得這兩種方式都可以,但是如果把限購這個屬性放到商品模型上得話,以後這種特殊屬性越來越多的話,會導致商品模型無限膨脹。所以如果由促銷來管理這個關係的話,商品模型上就只有一些簡單的屬性,這個基礎服務就會更加的乾淨。

請問有沒有一些經驗或者準則可以參考一下？謝謝。

我基本同意 @邊城 的方法。
商品，活動，限購都是需要記錄的事實。關鍵問題是“限購”應該怎樣表示。
由於限購本身還可能包含其他屬性，比如限購日期等等，所以不是單單一個關聯表（多對多關係）就能解決的。

有兩種方法可以記錄限購：1）記錄不限購的商品、活動2）記錄限購的商品活動
如果限購的商品活動數量相對較小，方法2）更合適。

Product (ProductId, ...)
Activity (ActivityId, ...)
PurchaseRestriction (ProductId, ActivityId, StartDate, EndDate，...)

你的疑問：
1. 這張映射表,屬於哪個模組去維護
商品、活動不是相互獨立的，PurchaseRestriction 恰恰表示了它們之間的聯絡。
PurchaseRestriction 既跟Product相關，又跟Activity相關。不是簡單的“誰的屬性”。
很多人設計class時使用循環參考，比如，Product 擁有 RestrictedActivities 集合，Activity 擁有 RestrictedProducts 集合。
你心裡也有類似的疑問，一方面覺得限購是一個事實，只應該放在一個地方；另一方面，感覺限購既是Product的屬性，又是Activity的屬性。

我覺得，這是物件導向的一個缺點，“對象擁有屬性，屬性必須屬於某個對象”這個思想的根源是認為所有東西都是樹狀結構的。
這跟樹形資料庫犯了同樣的錯誤，後來出現網路資料庫。網路資料庫可以表達複雜的結構，但是過於複雜。
關聯式資料庫的出現，解決了樹形資料庫和網路資料庫的問題。關聯式資料庫是基於集合論和一階謂詞邏輯的模型，可以完美地表達各種結構。

"模組化"當然很好，合理的模組化減少了程式各模組之間的耦合。
但是，一個系統最大的耦合往往是程式和資料的耦合。資料的結構變了，程式必須跟著變。
因此，規範的資料庫設計比應用程式的模組化更重要。

你把商品和活動分到不同的模組，一方面提高了抽象層級，模組化，另一方面割裂了它們的聯絡。雖然模組多了，但模組間的互動更複雜了。
你的問題沒有完美的答案，有3個解決方案：
a) 商品模組去維護
b) 活動模組去維護
c) 單獨的模組去維護。

2. 上面提到的(商品是否能參加活動,商品限購屬性),我覺得第一個是可以歸為商品固有屬性,第二個可能通過一張映射表來記錄(因為限購商品畢竟是少數)
"商品是否能參加活動"可以由PurchaseRestriction推匯出，不需要這樣的屬性。
在程式裡，也許有某個類，它有一個屬性 CanTakePartInActivity. 但是資料庫不能這樣設計。

一般情況下，建議採用商品和活動分表記錄，然後通過一張關係表來建立聯絡，這樣不管從商品找活動還是從活動找商品都會比較方便。對於近期活動需要快速讀取的情況，甚至可以針對活動單獨建立快取資料，以提高讀取效率。

具體情況具體分析，如果商品任何活動都不參加，則直接放在商品表中可矣，但如果某種商品只是某次活動不參加，而別次活動又有可能要參加，則必須另外建立一個商品活動表。

或者將商品分類，某次活動某幾類商品參與，則需要建立一個活動商品分類表，但也可能這次活動這些分類商品參與，而又要排除某幾件特殊商品，還是要分析這些被排除的商品是否有共性？如果有共性，則加分類標籤，如果完全是憑店主個人喜好隨機摘除，則再加一個排除表。大概就是這麼一個思路。

