理解大型mysql数据关系

Question

我正在尝试自学如何使用SQL，也就是mysql。

我想要了解的是如何在同一个表中处理许多不同类型的数据。假设我正在构建一个web应用程序，并且我有许多不同的内容类型(博客项目、评论项目、文件、页面、表单)，我需要为每种内容类型存储不同的数据字段。我应该为每个不同的内容类型创建一个新的表，因为每个内容类型都有自己独特的字段要求，或者有更好的方法来做到这一点？为每种类型的内容创建一个新的表似乎有点多。如果我的web应用程序中有30种类型的内容，那么仅针对这些类型就有30个表格，这似乎有点多。而且，如果我有一个新的内容类型，我必须创建一个包含该类型所需的所有必需字段的新表。

当我有许多不同类型的内容，每个内容都需要不同的数据字段才能进入数据库时，有没有更好的方法来做这样的事情？我可以通过某种方式查看内容的类型，然后选择另一个包含所有不同字段类型的表吗？

有点不知道该怎么做。

Answer 1

举个例子：

堆栈溢出本身对问题和答案使用相同的数据库表(称为Posts)。尽管这两种类型的数据不完全相同，但网站创建者认为它们足够相似，可以将它们放入一个表中。有一个PostTypeId字段表示这篇文章是一个问题还是一个答案。对于答案，标题字段将为空，对于问题，其他列可能会被忽略。

另一方面，注释在不同的表中。当然，从理论上讲，您可以将它们放入相同的Posts表中，并有一个用于评论的PostTypeId。但是这会产生额外的开销(因为注释的轻量级)，因此创建一个新表是合理的。

我知道这不是一个真正的答案，其他开发人员甚至可能决定将问题和答案放在不同的表中；但它提供了一些观点。长话短说:这取决于:)

Answer 2

草图交互

首先试着不去考虑数据库设计，而是实体应该如何在它们之间进行交互。可以把它看作是每个实体都有自己的Class，它表示所需的数据。

拿起纸和笔，勾勒出你在这些实体之间的交互，关于你试图实现的交互(或关系)，总是一个很好的开始。Learning the Database design process

的可扩展性和重用

例如，你想要一个User，它可以发布评论。每个BlogPost都可以有一组Tag和相关的Comment。Attachment可以注入到BlogPost中，也可以注入到Comment中。

可重用性和可扩展性是关键。在绘制交互草图时，请尝试隔离依赖关系。以面向对象的方式来考虑它。让我们更深入地研究一下Attachment。您可以创建一个附件表，然后通过创建BlogPostAttachment和CommentAttachment来扩展附件，您可以在其中轻松地创建这些可靠实体之间的关系。这创建了一个容易扩展的内容类型，你可以在例如。UserDetailsAttachment

拯救的ORM

通过研究Doctrine或Propel等Object relational mappers的示例代码用法，您可以掌握一些关于表可扩展性的想法。实际的例子总是最好的。

您可能会对感兴趣的与相关的SO问题

• Good Resources for Relational Database Design
• Good PHP ORM Library?
• How should a programmer learn great database design?

我知道，这是一个很长的路要走，但考虑到创建具有许多关系和实体类型的大型数据库应用程序的因素，从长远来看，最好使用ORM的帮助

Answer 3

你不必害怕使用很多很多的表-数据库会很高兴地处理很多表，而不会有任何抱怨。如果您让每种内容类型都有自己的表，您将获得某些优势：

1. Simplicity：每个表都可以相当简单，约束也很简单。例如，如果ContentType1有一个与另一个表有关系的字段，您可以在数据库设计中使用外键，并且RDBMS将为you.
2. Indexing efficiency处理数据完整性:如果ContentType2需要按日期索引，而ContentType3需要按名称索引(举个简单的例子)，将它们放在两个单独的表中意味着每个索引只针对它需要的数据，而不存在其他任何数据。将它们组合在一个表中意味着您需要两个索引来覆盖组合的数据集，这样会更加混乱，并且会占用更多的磁盘空间。

如果您需要输出一个组合了两种内容类型的列表，那么两个表的联合是很容易的；如果您需要经常处理大量数据，那么索引视图可以使其成本更低。

另一方面，如果您有两个非常相似的内容类型(例如，在上面的StackOverflow案例中)，将它们组合到一个表中可以获得一些好处：

你只需要编写一次表-如果做得正确(即两个内容类型非常相似)，这可以使你的代码库更小，如果出现第三个内容类型，它再次与前两个相似，并且以前两个相互匹配的相同方式相似，该表可以直接扩展以存储所有三个内容types.

• Indexing

1. Simplicity：performance。如果获取数据的最常见方法是将两种内容类型组合在一起，并按date (两种内容类型都共有的字段)对它们进行排序，那么使用两个单独的表(这两个表必须重复进行UNIONed，然后再进行排序)效率可能会很低。在一个表中组合这两种内容类型可以让您在日期字段上建立单个索引，从而加快查询速度(但请记住，您可以从索引视图中获得类似的好处)。

如果使用normalize rigorously，您将拥有一个数据库，其中每个实体类型在数据库中都有自己的表。但是，以各种方式进行反规范化(例如在一个表中组合两种实体类型)可能会带来好处，这可能会超过成本(取决于数据的大小和形状)。我建议至少在一开始采用keeping all content types separate的策略，如果有必要的话，可以考虑将它们组合成一个tactical denormalization。