我刚开始学习数据库，在设计数据库时，我注意到很多建议，比如在这个线程中，建议不要对每个用户使用一个表，而是将所有数据保存在一个大表中，并在需要时进行查询。但我还是不明白，因为在很多情况下，每个用户一张表似乎效率很高。
假设我有一个10000个客户的数据库，让他们跟踪他们的订单。每个客户的订单都很少，比如10个左右。这样，每个客户登录后，都要经过一个大表才能为这个客户获取数据，但是，如果每个用户都保留一个表，就可以直接得到客户需要的数据。
另一个例子是，一个餐厅信息系统跟踪所有餐厅的菜单（比如，在[foodname，price]对中），因为每个餐厅有不同数量的菜，你不能真正把每个菜单放在一行中，你只能用[foodname，price，restaurant]行做一个巨大的table。但是餐馆很多，所以当用户需要某个餐馆的菜单时，你需要浏览所有餐馆的数据，显然效率低下。
对于这两个例子，如果我不想为每个用户创建每个表，我想不出一个设计数据库的好方法。所以我的问题是：如果我们想避免每个表都按用户设计，我们应该如何为这类情况设计一个数据库？
2条答案
按热度按时间5m1hhzi41#
数据库被设计成精确高效地执行您描述的各种查找，即使所有用户都在一个表中。只要您按用户id创建索引（或者将用户id作为主键的一部分），那么数据库将按用户id对表进行排序，这样就可以使用二进制搜索高效地查找任何特定的用户。
“table”也不是你想的那样。表用于以对程序员有用的方式对数据进行逻辑分组。从理论上讲，您使用的任何数据库都可能只包含一个大表，但是如果您知道user表的行是这样的，而message表的行（或其他什么）是这样的，那么对数据库进行推理通常会更容易。事实上，许多数据库实际上只有一个大的底层“表”，所有数据都存在于其中。因此，从效率的Angular 来看，两个用户是在“同一个表”中还是在“不同的表”中通常根本不重要。
数据库管理软件是基于这样一个假设编写的：您将拥有相对较少的表（在极端情况下可能有几十个，甚至几百个）。所以，按照数据库文档的建议去做。
ncgqoxb02#
sql数据库的设计完全符合您所建议的场景类型。它们可以非常高效地处理数百万或数十亿行。试图将每个客户划分到一个单独的表中的复杂性是巨大的。
您唯一需要担心的是，您的表上有索引，这样您就不必扫描这10亿条记录来查找适用于您的客户的记录。
一旦索引就位，那么所有示例场景都将成为简单而高效的查询。