我应该选择哪两种数据库设置？

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以避免可能的混淆。