在新闻/内容平台的项目中，我们的团队正在围绕使用schema.org词汇作为模拟我们的数据库和域逻辑的直接来源进行辩论。
实施例： NewsArticle实体在schema.org上具有以下层次结构：
Thing > CreativeWork > Article > NewsArticle
我们的域将为每个域都有一个类，并使用扩展来构建层次结构。相同的模式将放在数据库上，这意味着我们将创建四个表（或者可能使用文档dbs）。
每个级别中的字段将放在“右”类/表中，这意味着NewsArticle实例需要获取所有先前的层次结构内容以组成其完整表示。
即使认为schema.org是一个很好的参考，可以帮助我们的域模型设计，如何命名字段等，直接适合似乎天真，甚至有害，没有明显的好处来补偿应该来的投资和膨胀
你看到这个approuch的好处吗？你看到问题吗？
ps：这与使用schema.org和相关词汇表（rdf / a，rNews）标记网页（我鼓励）无关。
答案 0 :(得分：1)
tl; dr，不要将这些模式作为数据库模型或逻辑的基础，而是要保持与您的工作之间的清晰映射，以及这些模式对您的重要性。
（下面的更长版本）
当您编写复杂的Web应用程序时，您将无法避免需要多个模型。可能有一个RDBMS物理模型，可能有一个OOP“对象模型”，并且可能会有一个Web前端数据模型（无论是在JSON中，还是在使用schema.org的东西的HTML DOM中）。这些模型将采用不同的形式，并具有不同的优点和缺点。
在RDBMS和对象层次结构之间，无论你做什么，你都会遇到Object-Relational Impedance Mismatch。这是一个非常难的问题，为此可以使用各种MVC框架和数据绑定工具来帮助您将OOP对象与数据库结构配对。
现在，如果您在数据库中直接使用schema.org的结构，它将显示，就好像这将使您的生活更轻松，因为模型在任何地方都是相同的。但由于阻碍不匹配，它根本就不会。当您在数据库中执行此操作时，首先要定义主/外键关系，以便在schema.org定义的实体之间获取（它们不提供它们，因为它不是关系模型）。这将只是从他们的模型漂移到本质上必须是关系的东西的开始。在您的对象模型中，您将没有PK / FK，您将拥有对象引用。从物理模型开始将更难以重用其他工具包。最后，您的自定义对象堆栈不会轻易地在HTML中序列化为schema.org的结构，而无需编写大量额外代码。
不同的形式主义需要不同的模型。理解这些（和数据需求可追溯性）之间的映射非常重要，但我认为你应该放弃你会按原样重用这些模型的想法，因为它可能不会发生。阻碍不匹配是你不能消失的事情;你只能就如何最好地应对/管理它们做出明智的决定。
随意窃取他们的命名惯例，结构和想法，但我会放弃逐字重复使用它。此外，他们的模型最适合您的查询加载的可能性是多少？