存储来自多个查找表的用户配置文件数据。如何？

Posted 2023-02-24

【中文标题】存储来自多个查找表的用户配置文件数据。如何？

【英文标题】：Storing user profile data from multiple lookup tables. how?

【发布时间】：2011-01-25 01:14:59

【问题描述】：

我有一个包含大约 50 条数据的用户表。其中一些是宗教、政党、种族、城市、最喜欢的电影等。这些项目中的每一个都是来自以下任一项目的查找值：他们自己的查找表，或者我有一个共同的查找表，用于诸如性别、性别偏好等小项目. 即使是最喜欢的电影也来自电影查找表。

问题是我假设在成员表中所有这些都将存储为 ID 而不是文本？所以首先问： 1) 他们应该还是不应该对查找表有 FK？ 2）如果我们存储ID然后得到实际的答案文本，如城市表中的ID 6 = new york，国籍表中的ID 10 = American等，用于页面上的实际输出，它将如何完成？我们是否需要在读取模式下从每个查找表中选择才能输出文本值？这让我感到害怕，因为在 50 条数据中，其中大约 40 条是基于查找的，因此这意味着在页面读取模式下对 40 个表进行 40 种不同的选择，然后在编辑模式下再次选择以供用户编辑值。

这是如何在具有详细用户配置文件的真实网站中实现的？ （我对每个值都有搜索和分析，所以我需要标识它们）

【参考方案1】：

取决于范围，但这听起来像是一个同步过程 - 设置一个每周/每天/每小时的过程，以将扩展的用户信息重新同步到主表中，并带有与“用户”相关的表的外键（用户名、密码、电子邮件、更新戳记等...）。

【讨论】：

我迷路了。这是个人资料数据，例如您的 facebook 个人资料数据，但有 10 倍以上的字段和所有基于查找的字段，因此只能将输入限制为经过验证的值。

价值验证对这个问题有什么影响？我说的是把你的数据非规范化成一个更容易使用的表，依靠同步过程来运行复杂的查询。

【参考方案2】：

您所描述的是规范化数据库设计和更多平面表设计之间的重大权衡：查询与规范化设计相比要复杂得多，这听起来像您一样。

我认为您从表格中读取的内容比写入表格的内容要多得多？ （一个人的宗教、性别、城市等多久改变一次？）在这种情况下，（仅）如果您在读取端遇到性能问题，您可能会维护表的两种表示形式：一种是可扩展的、规范化的一个像你一样的，一个纯文本的、平面的版本，速度快，查询和阅读小菜一碟。当您更新规范化记录中的记录时，您会更新平面记录中的记录。