数据库设计:如何避免EAV?

发布于 2024-11-06 06:19:35 字数 451 浏览 0 评论 0原文

可能的重复:
数据库设计:采用 EAV 还是不采用 EAV?

我' m 建模车辆信息。一辆车辆可以有0个或多个“设备”(例如发动机、车轮、扰流板、CD播放器等)。一个设备可以有 0 个或多个“属性”(例如,发动机的“燃料类型”可能是“柴油”)。

我事先不知道这些设备将是什么(它们将由用户定义),更不用说这些未知设备的属性将是什么。

所以,现在我很想使用 EAV。我是不是走错方向了?我担心我必须做这样的事情:找到所有燃料类型为柴油的车辆等。这对我来说听起来很痛苦。

如果需要的话,有什么替代方法的建议吗?

Possible Duplicate:
Database Design: to EAV or not to EAV?

I'm modeling vehicle information. A vehicle can have 0 or more "equipment" (e.g. engine, wheels, spoiler, CD player, etc.). An equipment can have 0 or more "attributes" (e.g. an engine's "fuel type" might be "diesel").

I don't know in advance what these equipment are going to be (they will be defined by the user) much less what the attributes are going to be for these unknown equipment.

So, now the temptation is for me to use EAV. Am I heading in the wrong way? I'm worried I'll have to do something like this: find all vehicles where fuel type is diesel, etc. Sounds painful to me.

Any suggestions for alternative approach, if needed?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

醉生梦死 2024-11-13 06:19:35

经验法则是:

  1. 如果键/值对可能是 where 子句的一部分或通过 sql 进行操作,那么它可能应该是表中而不是 eav 存储中的适当类型的列。

  2. 如果多个键/值对频繁组合,它们可能属于一个单独的表。

The rules of thumb are:

  1. If a key/value pair might be part of a where clause or manipulated through sql, it should probably be an appropriately typed column in the table rather than in an eav store.

  2. If multiple key/value pairs are frequently combined, they probably belong in a separate table.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文