我應該選擇哪兩種數據庫設置？

Question

我有3種類型的內容：博客，新聞稿和提醒。他們都有body和entered by字段。博客和新聞稿中有一個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一個主錶鏈接到專門的表格blogspress releasesreminders。我以爲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表只有type和type id需要鏈接到其他3個表，這意味着共同字段在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 

我應該去哪？我認爲第一種結構更好，因爲我可以搜索所有內容，無論是博客還是新聞稿，或是提供特定單詞。我還有其他表中查找，如果我要搜索title這是隻提供給blogs和press releases，但是......

所以其結構更是精益求精，你爲什麼這麼認爲？我也開放給其他的想法，或者是從這些2

Answer 1

第一個是更好的構建，它允許內容有一組特定的內容表中的子表需要或普通數據，然後專門的數據。這還允許您在未來添加更多類型的其他需求，這些需求仍然可以重用內容中的通用元素，但保留任何唯一的數據。

的另外一個關鍵問題是，如果需要的數據，例如做提醒需要一個小時，做所有的博客/新聞稿需要一個稱謂。如果他們需要，那麼你確保這些子表總是被填充。如果他們不那麼也許你應該看看扁平化結構（是的弗吉尼亞，你應該有時反規範化）。 （nn），類型id（nn），類型（nn），主體（nn），由（nn）輸入，title（012） （n），小時（n）。我通常發現這樣做的主要原因是，如果您創建的不同數據實體非常相似，那麼隨着時間的推移它們可能會合並。例如，此時的提醒不需要標題，但將來可能會有。

Answer 2

我想你應該想想常見的不同領域的改進。 他們真的需要匹配嗎？

如果需要匹配，只需將它放在一張表中即可。

Answer 3

我寧願去無任何形式的「類型」字段的，而不是讓四個表：內容，博客，pressreleases和提醒。內容具有輸入的常用字段，正文和標題。對於每一個博客，新聞發佈和提醒，他們都有一個ID，這是一個主鍵，也是一個內容ID的外鍵。這使1：1「是 - 一個」關係。提醒可以有額外的時間字段。要確定內容行是什麼類型的條目，請執行聯合選擇。

這可能不是最好的表現，但它更好的標準化。

Answer 4

第一個結構是一個經典的超類型子類型的方法，並建議。我只是建議使用完整的表名稱id來命名主鍵，如ContentID以避免可能的混淆。