SQL Server 是否原生支持 EAV
我喜欢 CouchDB 和 MongoDB 的灵活模式功能，但我也喜欢 SQL Server 的关系“连接”功能。我真正想要的是能够拥有诸如 PERSON、COMPANY 和 ORDER 之类的表，这些表基本上是“开放模式”，其中每个表都有一个 ID，但其余列定义为 json 样式 {ID:12,名字：“Pete”，姓氏：“smith”，身高：“180”}，但是我可以直接或通过多对多外部参照表有效地将人员加入公司。有谁知道 SQL Server 是否有计划在 SQL 中合并“开放模式”，或者 Mongo 或 Couch 是否有计划支持高效连接？非常感谢。
I love the flexible schema capabilities of CouchDB and MongoDB, but I also love the relational 'join' capability of SQL Server. What I really want is the ability to have tables such as PERSON, COMPANY and ORDER that are basically 'open-schema' where each table has an ID but the rest of the columns are defined json-style {ID:12,firstname:"Pete",surname:"smith",height:"180"}, but where I can efficiently join PERSON to COMPANY either directly or via a many-to-many xref table. Does anyone know if SQL Server has any plans to incorporate 'open schema' in SQL, or whether Mongo or Couch have plans to support efficient joining? Thanks very much.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
CouchDB 提供了多种方法来建立各种文档/实体之间的关系。查看 wiki 上的这篇文章开始使用。
来自关系背景的人倾向于在尝试解决问题时继续使用相同的术语和思维方式。了解 NoSQL 解决方案非常不同，这一点非常重要，否则它们就没有现有的真正用途。您应该真正努力了解这些不同的 NoSQL 解决方案是如何工作的，以便您可以将它们与您的应用程序的要求进行比较，看看它是否合适。
CouchDB offers a number of ways to establish relationships between your various documents/entities. Check out this article on the wiki to get started.
The tendency, when coming from a relational background, is to continue using the same terminology and mindset whenever you try to solve problems. It's very important to understand that NoSQL solutions are very different, otherwise they have no real purpose for existing. You should really seek to understand how these various NoSQL solutions work so you can compare them with your application's requirements to see if it's an appropriate fit.
MongoDB = NoSQL = 无连接 - 从来没有。
如果由于数据模型或项目要求而需要 JOIN：请继续使用 RDBMS。
MongoDB 中的替代方案：
非规范化
使用嵌入文档
多个查询
MongoDB = NoSQL = No Joins - never ever.
If you need JOINs due to your data model or project requirements: stay with a RDBMS.
Alternatives in MongoDB:
denormalization
using embedded documents
multiple queries
尽管这对于大规模查询来说效率很低，但从技术角度来看，使用 XML 数据类型将允许您存储您想要的任何可以随行变化的结构。
As much as this would be inefficient to Query on a large scale, from a technical standpoint, using the XML datatype would allow you to store whatever structure you wanted that can vary by row.
据我所知，但分配自己的 EAV 并不难，毕竟只有 3 个表:)
实体 1..* 属性 1..* 值
假设您使用 .NET，定义您的 EAV 接口，创建一些 POCO，并让实体框架或您选择的 ORM 为您连接关联。 LINQ 非常适合此类操作。
它还允许您创建混合模型，其中部分架构已知，但您仍然希望自定义数据具有灵活性。如果您在设计域模型时考虑到这一点（即在模型中使用 EAV 接口），则可以将 EAV 烘焙到 EF 数据上下文（或其他内容）中，以自动加载每个实体的属性及其值。您的 EF 实体只需要知道它属于哪个表实体。
当然，这不是完美的解决方案，因为您（可能）正在以性能换取灵活性。根据您想要保留的数据量和性能要求，它可能更适合大多数架构已知且较小百分比未知的模型。 YMMV。
Not that I'm aware of, but it's not that hard to role your own EAV, it's only 3 tables after all :)
Entity 1..* Attribute 1..* Values
Assuming you're using .NET, define your EAV interfaces, create some POCO's and let Entity Framework or your ORM of choice wire up the associations for you. LINQ works great for this sort of operation.
It also allows you to create a hybrid model, where parts of the schema are known but you still want flexibility for custom data. If you design your domain model with this in mind (i.e. use the EAV interfaces in your model) the EAV can be baked in to the EF data context (or whatever) to automate the loading of attributes and their values for each entity. Your EF entity just needs to know which table entity it belongs to.
Of course it's not the perfect solution, as you're (potentially) trading performance for flexibility. Depending on the amount of data you want to persist and the performance requirements, it may be more suited to models where most of the schema is known and a smaller percentage is unknown. YMMV.