基本数据库设计和复杂性

Question

我正在设计一个系统，它有一个用于存储用户和与用户相关的信息的数据库。 更具体地说，表中的每个用户都具有非常少的信息。 像Name，Password，uid之类的东西。

然后每个用户都有零个或多个容器，我最初这样做的方法是在数据库中创建第二个表，该表保存容器并有一个引用拥有它的用户的字段。 像containerName，content，owner这样的东西。

因此，对容器中数据的查询看起来像：

SELECT content
  FROM containers
 WHERE (containerName='someContainer' AND owner='someOwner');

我的问题是，如果这是一个好方法，我认为可扩展性说我们有成千上万的用户说...每个5个容器（但每个用户可以有不同数量的容器，但5可能是一个典型的情况） 。 我担心的是，当一个查询中我想要的5 * 1000个条目中有5个条目时，搜索数据库会变慢。 （我们通常只想从我们的查询中获取特定容器的内容，我们正在查看数据库，基本上有4995个条目的开销，我是对的？如果我订阅了一百万用户会发生什么，它会成为一个巨大的表，只是直觉上感觉像个坏主意。

我对它的第二个看法就是每个用户都有表格，但是这并不是一个非常好的解决方案，因为这会给我1000个数据库中的表格（也是凭直觉）似乎是一个糟糕的方式做到这一点。

任何帮助理解如何设计这将是非常感谢，我希望它清晰易懂。

Answer 1

处理此问题的方法是在owner字段上创建INDEX 。 这样，MySQL优化了对owner = 'some value'条件的查询。

另见： http ： //dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html

你说1000张表不可扩展是对的。 一旦你开始达到几百万条记录，你可能会考虑进行分片（根据用户属性将记录分成几个位置）......但到那时你已经非常成功了我认为;-)

Answer 2

如果它是RBMS（如Oracle / MySQL）数据库，则可以在经常查询的列上创建索引，以优化表遍历和查询。 为PRIMARY和（可选）for FOREIGN键自动创建索引。