将数据存储在链接表中
Supoose 我有以下内容:
tbl_options =========== id name 1 experience 2 languages 3 hourly_rate tbl_option_attributes ===================== id option_id name value 1 1 beginner 1 2 1 advanced 2 3 2 english 1 4 2 french 2 5 2 spanish 3 6 3 £10 p/h 10 7 3 £20 p/h 20 tbl_user_options ================ user_id option_id value 1 1 2 1 2 1 1 2 2 1 2 3 1 3 20
在上面的示例中 tbl_user_options 存储用户的选项数据。我们可以为某些选项存储多个条目。
现在我希望扩展这一点,即对于“语言”,我希望用户能够指定他们对某种语言的熟练程度(基础/中级/高级)。还有其他字段将具有扩展属性。
所以我的问题是,这些扩展属性可以存储在同一个表(tbl_user_options)中还是我需要创建更多表?显然,如果我输入“语言熟练程度”字段,它将不适用于其他字段。但这样我就只有一个用户选项表需要管理。你怎么认为?
编辑:这就是我的建议
tbl_user_options ================ user_id option_id value lang_prof 1 1 2 null 1 2 1 2 1 2 2 3 1 2 3 3 1 3 20 null
Supoose I have the following:
tbl_options =========== id name 1 experience 2 languages 3 hourly_rate tbl_option_attributes ===================== id option_id name value 1 1 beginner 1 2 1 advanced 2 3 2 english 1 4 2 french 2 5 2 spanish 3 6 3 £10 p/h 10 7 3 £20 p/h 20 tbl_user_options ================ user_id option_id value 1 1 2 1 2 1 1 2 2 1 2 3 1 3 20
In the above example tbl_user_options stores option data for the user. We can store multiple entries for some options.
Now I wish to extend this, i.e. for "languages" I want the user to be able to specify their proficiency in a language (basic/intermediate/advanced). There will also be other fields that will have extended attributes.
So my question is, can these extended attributes be stored in the same table (tbl_user_options) or do I need to create more tables? Obviously if I put in a field "language_proficiency" it won't apply to the other fields. But this way I only have one user options table to manage. What do you think?
EDIT: This is what I propose
tbl_user_options ================ user_id option_id value lang_prof 1 1 2 null 1 2 1 2 1 2 2 3 1 2 3 3 1 3 20 null
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我的直觉是将用户/语言/熟练程度关系分成自己的表。即使您将其与其他选项保存在同一个表中,您也需要编写特殊的代码来处理语言情况,因此您不妨使用新的表结构。
My gut instinct would be to split the User/Language/Proficiency relationship out into its own tables. Even if you kept it in the same table with your other options, you'd need to write special code to handle the language case, so you might as well use a new table structure.
除非您的数据模型不断变化,否则我宁愿使用
tbl_languages
和tabl_user_languages
表来存储这些类型的数据:设计一个“太通用”的系统是图灵关系 SQL 数据库的 tarpit 陷阱。基于文档的数据库更适合任意键值存储。
除了某些优化之外,您的数据库模型应尽可能匹配您的领域模型,以最大限度地减少对象关系阻抗不匹配。
通过此设计,您只需两个内部联接即可显示用户语言熟练程度和每小时费率的合理表:
您可以选择将语言熟练程度列表拆分到
tbl_proficies
表中,其中1 ==初级
、2 == 高级
、3 == 专家
并将其加入到tbl_user_languages
中。Unless your data model is in constant flux, I would rather have
tbl_languages
andtabl_user_languages
tables to store those types of data:Designing a system that is "too generic" is a Turing tarpit trap for a relational SQL database. A document-based database is better suited to arbitrary key-value stores.
Excepting certain optimisations, your database model should match your domain model as closely as possible to minimise the object-relational impedance mismatch.
This design lets you display a sensible table of user language proficiencies and hourly rates with only two inner joins:
Optionally you can split out a list of language proficiencies into a
tbl_profiencies
table, where1 == Beginner
,2 == Advanced
,3 == Expert
and join it ontotbl_user_languages
.我认为将“语言”作为选项是错误的。在阅读您的文本时,在我看来,英语是一个选项,并且它可能具有来自 option_attributes 的属性。
i'm thinking it's a mistake to put "languages" as an option. while reading your text it seems to me that english is an option, and it might have an attribute from option_attributes.