0

网站的个人资料页面包含任何用户的这些类型的字段 -

  1. 一对一字段 - 姓名、年龄、性别
  2. 一对多领域 - 工作经历、教育
  3. 多对多领域 - 语言、奖项、委员会

工具 - MYSQL 和 PHP [但可以更改]

我决定创建一个用户表。

tbl_user -> PK - user_id , FK - profile_id

对于用户一次出现的所有字段，我将它们作为属性添加到表 tbl_user_profile 中。

tbl_user_profile -> PK - profile_id

然后，为了满足一对多的关系，我创建了一堆表 - 这很容易随着时间的推移而增长..

tbl_user_jobs , tbl_user_education
FK - user_id [ INNO DB ]

然后我创建了一堆表作为 MANY_TO_MANY 建模的参考表 -

tbl_ref_awards, tbl_ref_languages, tbl_ref_committee
PK = REF_ID

tbl_user_languages, tbl_user_awards, tbl_user_committee
FK - user_id , REF_ID

现在，我必须使用刚才提到的许多细节来呈现个人资料页面。在每次页面加载时，我必须将表tbl_user_*表与 tbl_user 连接起来并填充到页面中。

我首先猜测这个设计是否可以？其次，在 page 上加入了 [7 次] 一样多的表，我在页面加载中看到了拖累，并且很高兴听到在上述用例中数据库设计的可能改进。已经有索引和 FK 存在。尚未在任何地方添加缓存。

4

1 回答 1

2

这是一种相当合理的数据建模方法；我要做的唯一评论是，我没有将参考表的主键命名为“REF_ID”，而是在表本身之后命名它们 - 例如，award_id。外键同上。

当然，这是一个偏好问题，但它更加一致 - 您已将用户配置文件表的主键命名为“profile_id”。

在现代硬件上，通过适当的索引，除非您处理数亿条记录，否则 7 表连接不应该是性能问题。请发布慢查询的解释，让我们看看我们是否可以提供帮助。

然而，实际上，运行几个小查询来填充页面可能比一个大查询更容易。这是因为 7 表连接当然会为每一行重复所有“一对一”数据，而这只会创建一些混乱的数据处理层。我现在在想，你得到

user_id user_name job_name language_name
-------------------------------------------
1      Bob         Waiter   French
1      Bob         Waiter   German
1      Bob         Waiter   Italian
1      Bob         Plumber  French
1      Bob         Plumber  German
1      Bob         Plumber  Italian

相反，我会在一个查询中检索用户个人资料，在第二个查询中检索用户工作，在第三个查询中检索用户教育，依此类推。这使您的 PHP 代码更加整洁，并减少了您在数据库和 Web 应用程序之间移动的数据量。

于 2013-03-03T15:22:58.070 回答