数据库表是否包含另一个表的条目？
我正在围绕重新设计处理数据的方式设计 Java 应用程序的新版本（使用嵌入式 H2 数据库）。 这是我的计划：
- 条目表-
- 条目 ID
- 条目名称
- 属性表-
- 媒体资源 ID
- 属性名称
- （个体属性）值表-
- 值 ID
- 条目 ID
- （值列...）
- （单个条目）值表-
- 属性名称
- （个人财产）值 ID
每个条目可以有多个属性（包括同一类型的多个属性）。 每个属性都有自己的存储其值的方式。 我需要查找为给定条目定义的所有属性，也许还需要查找每个给定属性的所有条目。
这是一个好方法吗？
编辑：我不确定我是否解释得很好......
I'm designing a new revision of my Java application (using an embedded H2 database) around a redesign of the way I'll be handling my data. Here's how I have it planned:
- Entries table-
- Entry ID
- Entry name
- Properties table-
- Property ID
- Property name
- (Individual property) value table-
- Value ID
- Entry ID
- (Value columns...)
- (Individual entry) value table-
- Property name
- (Individual property) value ID
Each entry can have multiple properties (including multiple properties of the same type). Each property has its own way of storing its values. I need to look up all properties defined for a given entry, and maybe all entries for each given property.
Is this a good way to do it?
Edit: I'm not sure I explained it well...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在我看来，这是一种非常糟糕的数据建模方式，但这是一种非常象牙塔的看待情况的方式，因为我没有在实践中使用过这个模型。 顺便说一下，它被称为“实体-属性-值”方法。 我不喜欢它的原因是它非常不像模式，因为大多数 SQL 功能都必须以某种方式复制。
它肯定有一个时间和地点（例如，如果您打算对具有不同模型的许多对象进行建模）或者具有经常更改的模式。 但我个人认为这很可怕。
In my opinion, that's a very bad way to model data, but this is a very ivory-tower way of looking at the situation as I haven't had to use this model in practice. By the way, it's called the "Entity-Attribute-Value" approach. And the reason I dislike it is because it's very un-schema-like in that most SQL functionality has to be replicated in some way.
There's definitely a time and a place for it (like if you intend to model many objects that have disparate models) or that have schemas that change frequently. But I personally think it's terrible.
如果我理解正确，我会使用交集或 联结 表而不是您所描述的表。
因此，您可以创建一个查询来获取每个 Entery 的所有属性，或每个 Property 的所有 Enteries。
If I understand you correctly, I would use intersection or junction tables instead of what you described.
So you can create a query to get you all the Properties per Entery, or all the Enteries per Property.
我同意未知谷歌的观点。 这也称为内部平台效应。
I agree with Unknown Google. This is also called the Inner-platform effect.