我可以像这样为我的 CMS 创建我的数据库设计吗？

Question

我正在设计一个标准的 CMS 数据库结构。这些是我的实体 tables:

ServicesPage
  --ServicesPageId
  --HeaderTitle
  --HeaderParagraph
AboutPage
  --AboutPageId
  --HeaderTitle
  --HeaderParagraph
ContentColumns (A section that can belong to pages)
  --Id
  --Title
  --Paragraph
  --Image
  --FK_PageId

...和其他页面

ServicesPage 有很多 ContentColumns
ContentColumns 只属于一个 ServicesPage
关于页面有很多内容列
ContentColumns 只属于一个 AboutPage

PageId 将包含内容列所属页面的 Id。因此，例如 AboutPage id = 1、ServicesPage = 2。每条 ContentColumn 条记录都有其所属页面的 ID

我认为这可行，但我遇到了 FK 合并冲突。

我真的很困惑，我做过很多次数据库设计，但从来没有做过 CMS。我认为这是让我感到困惑的概念。

我偶然发现我应该有一个页面 table

Pages
  --PageId
  --PageName ( Don't really need this column ? )

Pagestable应该有一对一ServicesPage和一对一AboutPage，其他所有页面也应该在这里。

现在的情况与我想出的相比有什么问题？我想了解我在这里的想法和做错了什么。

能否将一个 table 的外键 link 转换为多个 table（例如我在 ContentColumn table 中的 PageId）？对我来说，我的做法很有意义，因为您可以将页面 ID table link 中的任何页面 ID 添加到每个页面 ContentCol。

非常感谢您的帮助。

Answer 1

我想在您的数据库设计中提供一些观点。

首先：一个外键约束总是引用一个目标table.

所以你不能在一列中合并两个 F.Ks。（除非你不想使用 DBMS 约束并在代码中处理这个约束，否则我不推荐这样做）

其次：你的第二个设计（Page table）比第一个设计好。您可以通过 Page table 并将其 F.K 用于 ContentColumns 来解决第一个设计弱点。那么你应该使用 Page P.K 作为 F.K 到 ServicePage 和 AboutPage.

第三：我建议您可以将AboutPage和ServicePage合并为一个table并使用另一个table来保存它们的类型。

您的 ServicePage 和 AboutPage 在列中看起来非常相似。我建议使用这些 tables 而不是您的 AboutPage、ServicePage 或 Page tables：

a PageType table: 这个 table 将你的页面类型作为记录（AboutPage、ServicePage 和其他你将来可能拥有的页面类型）
a Page table 保存您的所有页面。 PageType 和 Page 之间存在一对多关系。您应该使用 PageType P.K 作为 F.K in Page.

然后你可以使用 Page P.K 作为 F.K in ContentColumns.

通过这种设计，您可以在运行时定义任何页面类型并动态控制它们。

我可以像这样为我的 CMS 创建我的数据库设计吗？

Can I create my database design for my CMS like this?

.net

sql

database-design

entity-relationship