将数据存储在链接表中

发布于 2024-10-10 10:25:05 字数 1201 浏览 2 评论 0原文

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 技术交流群。

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

发布评论

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

评论(3

明媚殇 2024-10-17 10:25:05

我的直觉是将用户/语言/熟练程度关系分成自己的表。即使您将其与其他选项保存在同一个表中,您也需要编写特殊的代码来处理语言情况,因此您不妨使用新的表结构。

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.

暖风昔人 2024-10-17 10:25:05

除非您的数据模型不断变化,否则我宁愿使用 tbl_languagestabl_user_languages 表来存储这些类型的数据:

tbl_languages
================
lang_id    name
1          English
2          French
3          Spanish

tbl_user_languages
================
user_id    lang_id      proficiency  hourly_rate
1          1            1            20
1          2            2            10
2          2            1            15
2          2            3            20
3          3            2            10

设计一个“太通用”的系统是图灵关系 SQL 数据库的 tarpit 陷阱。基于文档的数据库更适合任意键值存储。

除了某些优化之外,您的数据库模型应尽可能匹配您的领域模型,以最大限度地减少对象关系阻抗不匹配。

通过此设计,您只需两个内部联接即可显示用户语言熟练程度和每小时费率的合理表:

SELECT
    ul.user_id,
    u.name,
    l.name,
    ul.proficiency,
    ul.hourly_rate
FROM tbl_user_languages ul
INNER JOIN tbl_languages l
    ON l.lang_id = ul.lang_id
INNER JOIN tbl_users u
    ON u.user_id = ul.user_id
ORDER BY
    l.name, u.hour

您可以选择将语言熟练程度列表拆分到 tbl_proficies 表中,其中 1 ==初级2 == 高级3 == 专家 并将其加入到tbl_user_languages 中。

Unless your data model is in constant flux, I would rather have tbl_languages and tabl_user_languages tables to store those types of data:

tbl_languages
================
lang_id    name
1          English
2          French
3          Spanish

tbl_user_languages
================
user_id    lang_id      proficiency  hourly_rate
1          1            1            20
1          2            2            10
2          2            1            15
2          2            3            20
3          3            2            10

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:

SELECT
    ul.user_id,
    u.name,
    l.name,
    ul.proficiency,
    ul.hourly_rate
FROM tbl_user_languages ul
INNER JOIN tbl_languages l
    ON l.lang_id = ul.lang_id
INNER JOIN tbl_users u
    ON u.user_id = ul.user_id
ORDER BY
    l.name, u.hour

Optionally you can split out a list of language proficiencies into a tbl_profiencies table, where 1 == Beginner, 2 == Advanced, 3 == Expert and join it onto tbl_user_languages.

陈独秀 2024-10-17 10:25:05

我认为将“语言”作为选项是错误的。在阅读您的文本时,在我看来,英语是一个选项,并且它可能具有来自 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.

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