在一个针对新闻/内容平台的项目中，我们的团队正在讨论使用schema.org词汇表作为直接资源来对数据库和域逻辑进行建模。
示例：NewsArticle实体在schema.org上具有以下层次结构：
Thing > CreativeWork > Article > NewsArticle
我们的域对每个域都有一个类，并使用扩展来构成层次结构。将相同的模式放置在数据库上，这意味着我们将创建四个表（或者可能使用文档数据库）。
每个级别中的字段都将放在“正确的”类/表上，这意味着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定义的实体之间进行访问（由于它不是关系模型，因此不提供它们）。那仅仅是从他们的模型向本质上必须具有关系的事物过渡的开始。在对象模型中，将没有PK / FK，而将具有对象引用。从物理模型开始将使重用其他工具包变得更加困难。最后，如果没有大量额外的代码，您的自定义对象堆栈将不会轻易地序列化为HTML中的schema.org的结构。
不同的形式主义要求不同的模型。理解这些之间的映射（以及数据需求可追溯性）确实很重要，但是我认为您应该放弃这样的想法，即按原样重用那些模型，因为这可能不会发生。阻抗不匹配是您无法消除的。您只能根据自己的最佳方式做出明智的决定，以应对/管理这些决定。
随意窃取他们的命名约定，结构和思想，但我会放弃逐字重用。此外，他们的模型最适合您的查询负载的机会是什么？
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句