我将如何在数据库中设计这个
在这一点上，我很困惑，我只是在寻找可以解决这个问题的人，所以你们就是这样。
我正在为我们的组织开发一个基于网络的库存计划。
此时，我希望它尽可能通用，因此我正在查看这样的结构：
所以我看到的是项目类型或类别，每个项目类型都有一组属性并且属性可以共享，每个项目都有一个项目类型，然后给出可以填充值的项目属性，然后这些值必须与属性相关联。
这对其他人有意义吗？在这一点上我很困惑，所以任何想法或建议，甚至阅读材料，可以让我朝着正确的大方向前进，我将不胜感激。
At this point I am confused and am just looking for people to bounce this off of and so you guys are it.
I am working on a web based inventory program for our organization.
At this point I want it to be as generic as possible so I am looking at a structure like this:
So what I am looking at is there are item types or categories, each Item type has a set of properties and properties can be shared, each item has an item type which then gives the item properties that can be filled with values, these values then have to relate back to the properties.
Does this make sense to anyone else? I am confused to no avail at this point so any thoughts or suggestions or even reading material that would put me in the right general direction would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好吧，我看到一个 ItemTypes 表，它定义了类型（类型 id、类型名称）；定义属性的属性表（属性 ID、属性名称）； ItemTypeProperties 表列出了适用于每种类型的属性（即项目类型 id、属性 id）；项目表，其中列出了项目及其类型（项目 ID、项目类型）； ItemProperties 表列出了每个项目的属性值（即项目 id、属性 id、值）。
这有道理吗？
Well, I see an ItemTypes table which defines the types (type id, type name); a Properties table that defines the properties (property id, property name); an ItemTypeProperties table which lists the properties that apply for each type (i.e., item type id, property id); an Items table which lists the items and their types (item id, item type); and an ItemProperties table which lists the values of the properties for each item (i.e., item id, property id, value).
Does this make sense?
通过显示所涉及关系的基数，该图可以更清晰。但我明白设计的本质是什么。
它被称为“实体属性值”模型，又名“开放模式”，这在数据库中并不罕见。但是，您应该意识到这种方法有很大的缺点：
总之，您将必须让您的应用程序或存储过程执行大量管理这些属性的工作，因为除了纯存储和查找之外，数据库无法为您提供太多支持。
请参阅http://en.wikipedia.org/wiki/Entity-attribute-value_model 对于何时此设计可能是个好主意的一个很好的概述。另请查看 http://en.wikipedia.org/wiki/Inner-platform_effect为什么这可能是一件坏事。您必须根据您的应用程序决定这是否适合您。
如果您想要做的是为对象提供持久性，我应该指出，这是面向对象数据库试图以更自然的方式解决的问题。如果您真的对这种设计感到沮丧，并且您可以自由地查看任何可以解决问题的 DBMS，那么您可能会对此进行研究。
The diagram could be clearer by showing cardinality of the relationships involved. But I get what the design basically is.
It's called an "entity-attribute-value" model, aka an "open schema", and it's not an uncommon thing to do in a database. However, you should be aware that there are significant downsides to this approach:
In sum, you are going to have to have your application, or maybe stored procedures, do a bunch of work managing these properties, as the database is not going to be able to give you much support besides pure storage and lookup.
See http://en.wikipedia.org/wiki/Entity-attribute-value_model for a pretty good rundown on when this design might be a good idea. Also check out http://en.wikipedia.org/wiki/Inner-platform_effect on why it might be a bad one. You'll have to decide for your application whether this is the right approach for you.
If what you want to do is provide persistence for objects, I should note that this is a problem that object-oriented databases try to solve in a more natural manner. If you're really frustrated by this design, and you're free to look at whatever DBMS might solve the problem, you might look into that.