我正在创建用户个人资料。所有字段都是基于他们自己的表格查找，如喜欢的电影，喜欢的音乐，喜欢的食物，体育等...这些不是文本字段，而是自动建议系统维护列表中的字段。这些都在他们自己的表中的原因是他们有更多的独特的colunms。
因此，要在用户输入处读取数据，这是可以的，但在此之后出现两个问题：
1）写入数据：由于这是M：M关系，我需要20个不同的表格？
2）在配置文件加载时读取数据：我需要连接所有这20个表来获取用户的数据吗？
我还有哪些其他选项可以存储所有这些用户详细信息？我唯一关心的是性能，因为这是一个社交网站。 20个连接并不好。但我不确定其他技术。我正在使用mysql和php。
我能想到的唯一其他选择是将数据存储在数组中的数组中，尽管我不知道搜索的效果如何。
答案 0 :(得分：1)
如果速度有问题，请使用“数据库设计”和“查询优化”标记发布架构，并包含此问题的链接。
稍后。 。 无聊。所以我自己做了测试。我没有时间做20个连接，但是5个左连接，在一个拥有一百万个用户的表上，每个连接表中有50多万行返回大约400毫秒。 （PostgreSQL 9.0.2）现在重新开始工作。 。
还是以后。 。 仍然无聊。我添加了更多表，更多数据，更多左外连接。根据特定电子邮件地址的数据，更多联接仍然可以更快。 （你猜对了吗？）我跑的最后一个测试，从“用户”中选择了几十个随机电子邮件地址，
run time (milliseconds)
--
median 40
maximum 222
minimum 0.4 ("Four tenths of a millisecond", not a typo.)
如果我以后仍感到无聊，我会把一个程序打到一起
答案 1 :(得分：0)
20个连接不好
谁说？我不担心查询中的连接数，除非您发现它确实成为一个问题。关系数据库是设计的，可以解决相互关联的表格。
现在，关于你是否真的需要 20个连接完全是另一个问题。您应该发布一个示例查询和数据库设计的一些相关部分，我们可以告诉您是否有任何问题。
答案 2 :(得分：0)
您可以将用户个人资料存储在非关系型数据存储中，例如MongoDB。
这不仅可以避免连接混乱，而且可以更轻松地动态更改用户配置文件架构，并避免编写大量数据访问代码。
答案 3 :(得分：0)
根据您的性能要求，20个连接可能是也可能不是问题。但是如果你想在负载下进行亚秒级响应，那么避免这种情况确实很好。但是，如果这仅在用户登录时发生，并且您希望每秒不超过几次登录，并且您没有其他大量数据库负载等，那么性能可能是非常容忍的。
如果你不能把它们中的一些结合起来，我会感到惊讶。我认为许多配置文件属性可以在一个共同的结构中表示 PersonId，TraitType，string1，string2，int1，int2，date1，date2。如果在您的代码中，您正在执行类似OO表示数据的任何操作，那么您可以将traittypes映射到完全代表该类型的类，因此您的程序可能不需要在此表的抽象级别上工作设计代表。
答案 4 :(得分：0)
是否需要在配置文件加载时加载所有数据？在我看来，您的参考表NAMES代表了Profile本身的某种可供性，当用户激活它时，执行查询该表中的项目，不是吗？
我不是专业的网络程序员，所以我可能会把这一切都搞错了。但似乎配置文件加载并向用户显示总计/导航界面的数量，对吧？使用一些按钮/字形，用户可以通过哪些方式导航和/或请求更多信息。
在配置文件加载时，会显示顶级配置文件信息，以及（过于简化）某些按钮，可能位于标题窗口小部件“我的收藏夹”下。按钮可能存在于“PLaces”，“Food / Drink”，“Music”等等。当用户激活其中一个时，会针对该特定表（以及任何相关联接）执行查询以返回特定于“Places”的数据例如。
也许它与Web不同（我将很快学习），但我尝试在有意义时请求数据，并在用户可能期望短暂的访问时间时请求数据。按钮单击通常是用户预期响应稍有滞后的点。
答案 5 :(得分：0)
减少连接数的一种方法是将所有20种类型共有的数据存储在一个表中。该表与20个专用表的关系遵循gen-spec设计模式。查看“泛化专业化关系建模”，了解如何在表格中实现gen-spec模式。
如果这样做，您只会在需要时引用专用表。
我不确定您的使用模式，所以我不能说这个建议是否适用于您的情况。但值得研究。