使用 schema.org 作为数据库模式是一种合理的方法吗？

Question

在新闻/内容平台的项目中，我们的团队正在讨论使用 schema.org 词汇作为直接来源来建模我们的数据库和领域逻辑。

示例：NewsArticle实体在 schema.org 上具有以下层次结构：

Thing > CreativeWork > Article > NewsArticle 

我们的域将为它们中的每一个都有一个类，并使用扩展来构建层次结构。相同的模式将应用于数据库，这意味着我们将创建四个表（或者可能使用文档数据库）。

每个级别中的字段将放置在“正确”的类/表中，这意味着 NewsArticle 实例需要获取所有先前的层次结构内容才能组成其完整表示。

即使认为 schema.org 将是一个很好的参考，可以帮助我们进行领域模型设计、如何命名字段等，但直接匹配似乎很幼稚，甚至有害，没有明显的好处来补偿应该出现的投资和膨胀。

您看到这种方法有什么好处吗？你看到问题了吗？

ps：这与使用 schema.org 和相关词汇（rdf/a、rNews）来标记网页（我鼓励这样做）无关。

Answer 1

tl;dr，不要将这些模式作为数据库模型或逻辑的基础，而是保持与您所做的事情之间的清晰映射，以及这些模式（如果它们对您很重要）。

（下面是较长的版本）

当您编写复杂的 Web 应用程序时，您将无法避免对多个模型的需求。可能有一个 RDBMS 物理模型，可能有一个 OOP“对象模型”，并且可能会有一个 Web 前端数据模型（无论是在 JSON 中，还是在使用 schema.org 的内容的 HTML DOM 中）。这些模型将采用不同的形式，并且具有不同的优点和缺点。

就在 RDBMS 和对象层次结构之间，无论您做什么，您几乎都会遇到对象关系阻抗不匹配的情况。这是一个非常困难的问题，为此存在各种 MVC 框架和数据绑定工具来帮助您将 OOP 对象与数据库构造配对。

现在，如果您直接在数据库中使用 schema.org 的结构，似乎这会让您的生活变得更轻松，因为模型在任何地方都是相同的。但由于阻抗不匹配，根本不可能。当您在数据库中执行此操作时，首先要定义主/外键关系，以获取 schema.org 定义的实体之间的关系（他们不提供这些关系，因为它不是关系模型）。这只是他们的模型转向本质上必须是相关的东西的开始。在你的对象模型中，你不会有 PK/FK，你会有对象引用。从物理模型开始将使重用其他工具包变得更加困难。最后，如果您不需要编写大量额外代码，您的自定义对象堆栈将无法轻松序列化为 HTML 中的 schema.org 结构。

不同的形式主义需要不同的模型。了解这些（以及数据需求可追溯性）之间的映射非常重要，但我认为您应该放弃按原样重用这些模型的想法，因为这可能不会发生。阻抗不匹配是无法消除的问题。您只能就如何应对/管理它们做出明智的决定。

随意窃取他们的命名约定、结构和想法，但我会放弃逐字重用它。另外，他们的模型最适合您的查询负载的可能性有多大？