Question

我正在使用Django制作我的第一个网站，而且我遇到了数据库设计问题。

我需要存储一些用户的历史记录，而且我不知道每次注册时为每个用户创建这样的表是否更好：

table: $USERNAME$

id  |  some_data  |  some_more  |  even_more

或者从一开始就有一个大表，每个人的数据都在：

table: user_history

id  |  username  |  some_data  |  some_more  |  even_more

我知道如何做第二个，只需在我的Django模型中声明它。如果我应该做第一个，我怎么能在Django？

第一个是按层次结构组织数据，但可能会根据服务的受欢迎程度创建大量表格（这是件坏事吗？）

第二个似乎更适合Django的设计理念（从我到目前为止看到的），并且更容易在用户之间进行比较搜索，但可能会变得很大（用户数量*历史上的平均项目）。 MySQL可以处理10亿条记录吗？（我不会那样做，但提前计划好）

Answer 1

我只是不知道Django是什么，但我确信为每个用户创建一个用于记录的表（或几乎任何东西）都不是一个好习惯。

最好的问候。

Answer 2

肯定第二种格式是你想要的方式。 MySQL非常擅长处理大量行（假设它们在适当的时候被索引和缓存）。例如，维基百科上所有页面的所有版本都存储在其数据库中的一个表上，并且完全正常。

Answer 3

您绝对应该将所有用户存储在一个表中，每个用户一行。这是使用WHERE子句过滤数据的唯一方法。而且我不确定MySQL是否可以处理10亿条记录，但我从未发现记录限制是一个限制因素。我现在不担心记录限制。

Answer 4

你知道，每个高负荷的项目都是从设计精良的东西开始的。精心设计的系统具有更好的视角，可以改进以处理巨大的负载。

另外请记住，即使是twitter / fb / etc中的天才家伙也不知道他们会在一段时间后会遇到什么问题。你也不会知道。解决加载/可扩展性挑战及其预测是一种火箭科学。

所以你现在能做的最好的事情就是从最规范化的数据库和学术解决方案开始，一出现就解决瓶颈。

Answer 5

创建关系数据库时，如果新表包含与原始表明显不同的数据，则只需要创建新表。在这种情况下，所有表都几乎相同，因此您只需要为所有用户使用1个表。

如果要进一步细分，可能不希望将所有用户操作存储在用户表中。您可能希望有1个表用于用户信息，另一个表用于用户历史记录，即：

table: User
Id | UserName | Password | other data

table: User_history
Id | some_data | timestamp

只要在计划搜索的字段上定义正确的索引，就不必担心数据库的速度。随着更多记录被放入您的表中，使用这些索引肯定会加快您的响应时间。我工作的数据库有几个表，有30,000,000条记录，而且没有减速。

Answer 6

绝对不要为每个用户创建一个TABLE。为每个用户创建一行，如果可以考虑某些数据，则每个用户可能有一行和更小的表。

Answer 7

绝对坚持为所有用户使用一个表，考虑复杂的查询，这些查询可能会请求额外的资源来运行多个表而不是一个。运行一些测试，关于资源我相信你会发现一个表最好。

Answer 8

每个人都指出第二个选项是要走的路，我会将 +1 添加到其中。

关于第一个选项，在Django中，您通过声明django.models.Model的子类来创建表，然后当您运行管理命令syncdb时，它将查看所有模型并为所有模型创建缺少的表“管理“模型。可能在运行时调用此行为，但事情并非如此。