我應該選擇以下兩種數據庫設置中的哪一種？

Question

我有3種類型的內容：博客，新聞稿和提醒。 他們都有一個body並按字段entered by 。 博客和新聞稿都有一個title字段，提醒者缺少title字段，而提醒文件有一個hour字段，博客和新聞稿缺乏。 這是表格格式的樣子，所以你很容易看到......

                   blog       press release      reminder
---------------------------------------------------
entered by field   yes        yes                yes
body field         yes        yes                yes
title field        yes        yes                --
time field         --         --                 yes

我正在創建一個名為content的主表，鏈接到專門的表blogs press releases reminders 。 我想到了2個結構

第一種結構......這就是我使用的內容管理系統如何做到的，但我不想盲目地遵循他們的步驟，因為我的需求是不一樣的。 將所有共享字段放在主content表中。 因此content表不僅具有鏈接到專用表的type和type id ， content表還將具有像body一樣的公共字段和entered by 。 其他3個表只有它們唯一的字段。

content table    B=blogs table   PR=press releases table     R=reminders table
------------------------------------------------------------------------------
id               id              id                          id
type=B/PR/R      title           title                       hour
type id
body
entered by

第二種結構。 content表只有鏈接到其他3個表所需的type和type id ，這意味着公共字段在3個表中重復。

content table    B=blogs table   PR=press releases table     R=reminders table
------------------------------------------------------------------------------
id               id              id                          id
type=B/PR/R      entered by      entered by                  entered by 
type id          body            body                        body
                 title           title                       hour

我應該選哪個？ 我認為第一個結構更好，因為我可以搜索所有內容，無論是博客還是新聞稿或特定單詞的提醒。 如果我想搜索僅適用於blogs和press releases的title ，我仍然需要查看其他表格，但是......

那么哪種結構更好，為什么你這么想？ 我也願意接受與這些不同的其他想法或改進2。

Answer 1

第一種結構是經典的超類型 - 子類型方法，並推薦使用。 我建議使用像ContentID這樣的完整table-name-id來命名主鍵，以避免可能的混淆。

Answer 2

第一個是更好的構造，它允許內容在內容表中具有一組特定的必需或公共數據，然后在子表中具有專用數據。 這也允許您在將來添加更多類型，其他需求仍然可以重用內容中的公共元素，但保留任何唯一數據。

另一個關鍵問題是，如果需要這些數據，例如，所有提醒都需要一個小時，並且所有博客/新聞稿都需要標題。 如果需要它們，則確保始終填充這些子表。 如果他們不是那么也許你應該看看扁平化結構（是弗吉尼亞你有時應該非規范化）。

所以你的內容表只是變成（nn = not null，n = nullable）id（nn），type id（nn），type（nn），body（nn），由（nn）輸入，title（n），小時（N）。 我通常發現這樣做的主要原因是，如果您創建的不同數據實體非常相似，那么隨着時間的推移，它們可能會合並。 例如，此時的提醒不需要標題，但將來可能需要。

Answer 3

我很快就會沒有任何類型的“類型”字段，而是制作四個表：內容，博客，新聞發布和提醒。 內容具有輸入，正文和標題的公共字段。 對於每個博客，新聞發布和提醒，他們都有一個id是主鍵，也是內容id的外鍵。 這使得1：1“is-a”關系。 提醒可以有額外的時間字段。 要確定內容行的條目類型，請執行連接選擇。

這在性能方面可能不是最好的，但它更好地規范化。

Answer 4

我認為你應該考慮共同領域。 他們真的需要匹配嗎？

如果他們需要匹配，將它放在一個表中就更容易了。