我们正在寻找一种合理的数据库结构解决方案，以便我们如何在我们的数据库中为用户存储密钥对，该数据库将位于网站后面。该网站将拥有数千个用户，针对每个用户，将至少有一个唯一密钥对。密钥对将是VARCHAR（34）和VARCHAR（51）。用户将从一个唯一的密钥对开始，但这可能最终成为数千个唯一密钥对。当访问密钥对时，它们可以按任何顺序完成，但我们确实想添加一个字段来表示可以跳过密钥对。
我们如何最好地为此构建数据库？
解决方案一：具有用户ID，密钥公开，密钥私有和忽略为列的所有用户的单个表。这将最终成为一个庞大的表。
解决方案二：每个用户一个表，将动态创建和访问该表。结构将是Key Public，Key Private和Ignore as columns。
如果还有其他更明智的解决方案，请告诉我们。
答案 0 :(得分：1)
许多结构相同的表的动态创建（和访问）几乎从不适合或有用，因为它倾向于将数据绑定到为访问它而构建的应用程序代码，因为所有查询必须动态创建。使用数据库客户端，执行连接，聚合，分析等变得困难或不可能，而不会增加动态SQL的复杂性。所以，我很清楚每个用户创建一个表格。
您所描述的是一种非常典型的一对多关系，其中每个用户至少有一个密钥对，并且该密钥对完全属于该用户。因此，您在上面所说的“解决方案一”就是正确的方法。您可能会误以为将其视为一个潜在的大型表 - 数据库术语中几百万行的表甚至不是特别大。一个达到数亿或数十亿的行很大，并且可能对可伸缩性有不同的考虑。 数千个行很容易管理。
假设有关您的用户的大部分详细信息（唯一的）存储在单独的users表中，并且主键（例如userid），您可以将密钥存储在{{1将keypairs列定义为针对userid的{{1}}。
在最简单的形式中，您甚至可能不需要其他索引，因为FOREIGN KEY约束将在users.userid上创建索引。但是，如果您确实希望每个用户拥有数千个，那么您最终可能需要在FOREIGN KEY对中添加复合索引。每userid只有一行或几十行，我不希望这是必要的。
userid, inactive