Database design 使用schema.org作为rational approuch的数据库模式？

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

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

Thing > CreativeWork > Article > NewsArticle 

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

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

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

你认为这种方法有好处吗？你看到问题了吗

---

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

tl；dr，不要让这些模式成为数据库模型或逻辑的基础，但要维护与您所做工作之间的清晰映射，如果这些模式对您很重要，则维护这些模式

（以下为较长版本）

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

就在RDBMS和对象层次结构之间，无论您做什么，都会遇到类似的问题。这是一个非常困难的问题，有各种MVC框架和数据绑定工具可以帮助您将OOP对象与数据库结构配对

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

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

---

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

不知道您的域，我想您只能靠自己了。不过，我想说，不要放你不需要的东西。这还取决于您使用的技术。例如，如果您打算使用ASP.NET，那么我要说的是上述优势并不适用：Web管理员不会查看您的代码，开发人员会查看。1。确保您理解表继承。2.看@NeilMcGuigan 1）很难说完全理解某件事，但是是猜测，是的，我理解。2） 回答得很好，我熟悉企业建模，我这里的问题是，在给定的上下文中，它在哪里是合适的。现在我觉得它不合适。我将在需要时使用表继承和任何其他模式，但是为了1:1到schema.org的目的使用它们并不是真正的需要，schema.org不是为了这个目的而做的。阻抗不匹配是反对逐字使用的一个很好的理由。但我认为这里的一个关键问题是查询设计。高达90%的查询将通过slug/id进入新闻模型，schema.org不是专门为之设计的。