CMS结构的好或坏主意？

Question

所以，我打算制作一个CMS，我只想要一些选项。

这个想法很简单，但似乎没有其他人这样做，所以这个想法一定有问题吗？

基本上，我会有一个名为'fields'的表。该表将包含各个数据字段。然后我会有一个名为data_node的第二个表，它是一组用于创建数据对象的字段。

因此，data_node将是一篇博文。该data_node将具有4个字段。标题，内容，创作，出版。

字段表有4个条目，data_node表有1个条目

在PHP级别，您将拥有可访问数据节点的模块。

这有不足之处吗？一个表可以做很多工作但是对于中型网站来说这不是问题吗？

Answer 1

您定义的内容基本上是EAV结构。 EAV通常用三个表来实现，一个定义实体（在您的情况下是帖子），一个定义属性（标题，内容，创建，发布等），一个为给定实体提供单个值并给定属性。

正如您明显推断的那样，EAV结构允许非常灵活地存储同类数据，因为您将所有定义为“是”的内容抽象为另一层数据。好处是灵活性，但缺点很多：

• 您无法强制执行引用完整性（无法在物理级别定义特定类型的实体必须包含某些字段的值，包括实体之间的关系）
• 存储效率低下，因为您必须设计最小公分母。换句话说，如果您要存储博客文章的内容，那么您存储的每个值都必须存储在一个非常大的字符字段中。在应用程序中使用非字符数据（如日期或数字）时，必须将其转换为字符串或从字符串转换
• 加入写作变得单调乏味。虽然6NF数据库设计也是如此，但这不是一个不可逾越的障碍，值得注意。对于需要转换为结果集中的列的任何字段（换句话说，如果您只想为帖子返回单行，使用您已定义为列的字段而不是返回多行对于帖子，您已定义为行的字段）需要自己的连接。这是（或者不应该，取决于你的RDBMS ...如果你使用PHP我假设你正在使用MySQL，我不能聪明地说它如何处理许多连接）不是一个问题的数据库，但是编写查询会很麻烦。

EAV结构有其自己的位置，但通常在开发系统时，个别最终用户希望为实体定义自定义属性，而无需更改应用程序或数据库。除非您需要这种灵活性，否则成本要高于收益。

Answer 2

几年前，我开发了一个使用这种架构的系统，用于由欧盟资助的科学项目。这是一个很好的实验。

缺点，根据我的经验：

• 您将不得不忘记传统的sql方法的参照完整性。没有外键，没有'删除级联'等。
• 你会做很多元编程。这是一个很好的挑战，但在你习惯它之前，突然变得非常难以纠正错误。
• 并非所有字段都具有相同的数据类型。您的表'字段'将需要更多列，或者您必须将所有内容转换为VARCHAR并返回。