所有者ID類型數據庫字段

假設您有以下表格：RestaurantChains，Restaurants,MenuItems - 它們之間有明顯的關係。現在，您有Comments和Ratings的表格，其中存儲有關鏈條，餐館和菜單項的顧客評論/評級。鏈接這些表格的最佳方式是什麼？最明顯的解決方案可能是：所有者ID類型數據庫字段

使用列OwnerType和表Comments和Ratings在OwnerID，但現在我不能添加外鍵的意見/評級與他們對精神疾病
創建單獨的對象鏈接每個表的Comments和Ratings的表格，例如MenuItemRatings, MenuItemComments等。這種解決方案的優點是所有正確的外鍵都存在，並且具有顯着的缺點，即具有基本上相同結構的大量和大量表。

那麼，哪種解決方案效果更好？還是有更好的解決方案，我不知道？

來源

2009-02-18 Saulius Valatka

由於有關的菜單項意見是從大約一間餐廳（即使他們碰巧共享相同的結構）的意見不同，我會把他們分開表並具有適當的FK來強化數據庫中的某些數據完整性。

我不知道爲什麼有人厭惡你的數據庫中有更多的表。除非你從50個表格到5萬個表格，否則由於大型目錄表格的存在，你不會看到性能問題（並且在這種情況下具有更多，更小的表格實際上應該會給你更好的性能）。我也傾向於認爲，處理名爲「Menu_Item_Comments」和「Restaurant_Comments」的表比處理稱爲「評論」的表更清楚，並且不知道僅僅通過其中的確切內容它的名字。

來源

2009-02-18 18:37:50

對所有對象都有一個評論/評級表，並且不使用自動生成的外鍵。評級表中的關鍵字，例如RatingID可以放在餐廳，連鎖店，菜單項表中的一個字段中，並且它們都可以指向同一個表，它們仍然是外鍵。

如果您需要反過來知道審覈與您相關的對象，則需要有一個字段來指定審覈類型，但這應該是全部。

來源

2009-02-18 17:59:28

等一下，要麼我沒有收到什麼東西，要麼你的解決方案將允許一個項目有一個評級/評論。我想要一個Restaurant/MenuItem/etc有很多評論，所以我不能在Restaurant/MenuItem/etc中添加一個RatingID列。 – 2009-02-18 18:05:15

我的錯誤。我認爲Decker有你正在尋找的解決方案。 – 2009-02-18 21:16:00

使用單個表格進行評論，並使用GUID作爲貴賓的主鍵。

然後你就可以，甚至沒有事先知道選擇的意見，他們屬於：

SELECT CommentText 
FROM Comments c, Restaurants r 
WHERE c.Source = r.Id 

SELECT CommentText 
FROM Comments c, Chains ch 
WHERE c.Source = ch.Id

等

不能使用徵求意見外鍵，當然，但它不是，註釋不能沒有外鍵的生活。

您可以清除觸發器中的孤立註釋，但如果其中一些留下，則沒有什麼不好。

您艾米還可以創建一個全球Entity表（使用單一GUID列），讓你的Chains，Restaurants，MenuItems和Comments指的是表與FOREING KEY ON DELETE CASCADE，當DELETE「荷蘭國際集團，也就是說，一個餐廳，將其刪除從該表中取而代之。它會刪除一個餐廳和所有的評論，你仍然有你的誠信。

來源

2009-02-18 18:04:37 Quassnoi

如果要利用外鍵約束並規範化基表中的評論（和評分）屬性，則可能需要在基表與評論（和評分）之間創建關係表。

例如對於餐廳和評論：

Restaurants 
    id (PK) 
    (attributes of restaurants...) 

RestaurantComments 
    id (PK) 
    restaurantid (FK to Restaurants) 
    commentid (FK to Comments) 

Comments 
    id (PK) 
    (attributes of comments...)

來源

2009-02-18 18:13:47 Sean

這個怎麼樣alt text http://www.freeimagehosting.net/uploads/8241ff5c76.png

來源

2009-02-18 18:21:51

所有者ID類型數據庫字段

回答

相關問題