Mysql 将表与多个内容类型关联是否会导致问题？

我有多种内容类型，但它们都有一些相似之处。我想知道什么时候对不同的内容类型使用相同的表会有问题？这是个问题吗？若然，原因为何

这里有一个例子：我有五种内容，它们都有一个标题。所以，我不能对所有五种内容类型都使用“标题”表吗

扩展该示例：从技术上讲，标题是一个名称。人和地方都有名字。把我所有的内容标题、人名和地名都放在一个“名称”表中会不会不好？为什么要分为地名、人名、内容和标题

我有不同种类的内容。在数据库中，它们看起来非常相似，但应用程序以不同的方式使用内容，产生不同的输出。我是否需要为每种内容类型创建一个新表，因为它具有不同类型的依赖关系，或者我应该只允许空值吗？

我不会这么做

如果在多个表中有多个相同的列，您确实应该将它们规范化为一个表

例如，几种类型的用户都需要不同的列，但都有一些共同的特征（例如姓名、地址、电话号码、电子邮件地址） 这些可以规范化为1个表，然后所有其他表通过外键引用该表。（见附件）

---

您的示例只显示了一个公共列，不值得进行规范化。它甚至会降低获取数据的性能，因为您需要连接两个表才能获取所有数据；其中1个（带有标题的一个）包含大量数据，您不需要从中获取所有数据，从而使服务器更加紧张。

虽然规范化是避免冗余和确保一致性的一个非常好的做法，但有时会对性能造成不利影响。例如，对于一个

person

表，其中有

name

、

address

、

dob

等列，在同一个表中有一张

图片

，这样的性能不是很好。一张图片可以很容易地达到1MB左右，而其余的列所占的空间可能不会超过1K。想象一下，即使你只想列出居住在某个城市的人的姓名和地址——如果你把所有内容都放在同一张表中，也需要读取多少数据块

---

如果内容大小不同，并且您可能必须在同一查询中仅检索某些类型的内容，那么将它们存储在单独的表中所获得的性能收益将很容易超过标准化。

要以这种方式表示数据，最好使用表（即，

名称

）和子表（即，

name_type

），然后使用FK约束。使用

FK约束

，因为

InnoDB

不支持列约束，而

MyISAM

引擎不适合这种情况（它的健壮性和功能丰富性要差得多，实际上应该只用于性能）

---

这种规范化很好，但应该使用自由格式的列类型，如

VARCHAR（40）

，而不是使用

ENUM

。使用触发器限制输入，使其与您想要支持的类型匹配。

很抱歉，但您提供的信息在我看来似乎与自身冲突。如果我正在规范化表，我将创建新表，对吗？因此，我不确定是否知道您的意思。是的，在规范化过程中，您将为多个表中的多个公共列创建一个新表，规范化是无用的，只会给服务器带来更多压力，而不会给您带来任何规范化好处。这些表只是3列表：标题id、标题内容、标题状态。它们基本上完全相同，并且不包含任何其他内容。您不会有“标题id”在非规范化版本中。但是，如果所有表中已有2个公共列（标题内容、标题状态），然后将它们规范化是完全明智的：p-虽然只有一个公共列“title”，是的，设计这个数据库是一个有趣的过程。我会再考虑一下。你肯定给了我一些想法。我仍然担心可能会有一些问题，比如它可能会混淆，或者有

内容类型

IIdentifier——一个添加的列——可能会导致问题。我想这是一个低成本的列，但却牺牲了分布在肮脏地方的许多表。这很有趣，我没有想到，Raihan。我正在处理的数据库可能被称为“超规范化”数据库例如，我没有一个包含姓名、地址和dob的person表。我有一个person id表、一个name表、一个address表和一个dob表。“规范化是简化数据库设计以实现最佳结构的过程”.Normalization genrally意味着在表中拆分关系。它还意味着不要过度拆分。

Person{pid，name，address，pictuire}

将是

Person

关系的规范化结构（除非您想进一步分解

address

）。将其拆分为

Person{pid，name，address}

和

个人图片{pid，pictuire}

不是一个规范化的结构，但从性能角度来看可能更好。这就是我在帖子中的意思。@wolfpack，这不是超规范化的，它只是一个非常糟糕的设计。有多少人的出生日期不止一个？没有理由将其从person表中删除。地址是一对多的关系，应该是在一个社交网站上，我会说大约有1/50的人有多个DOB。不过，我可以看出保留在person表中是多么合理。：）无论如何，考虑到这种标准化水平，你能理解我为什么考虑合并姓名表吗？但无论如何