Question

我有一个用户表来控制对网站的访问。我们目前有几百个用户，这可能最终会增加到几万个。我们要求允许“临时”用户。这些临时用户将有一个超时的令牌，永远不会再次使用。这些令牌可能会在很大程度上超过一般用户。我的问题是这些临时用户是应该存储在常规表中还是存储在他们自己的表中。

我的倾向与用户ID在别处用作外键的表相同，对临时用户仍然有用。整个ID的独特性非常重要。但是，我很高兴用户表中将填充许多永远不需要再使用的记录，从而减慢了表格。

我考虑的另一个选项是创建用户记录，捕获id，删除记录，然后在另一个表中使用id。因此，我保留了id的唯一性，但减少了桌子的膨胀。我不介意外键是否引用不同的表。

任何人都有类似的问题并有任何想法？

Answer 1

只要您索引ID或将其作为主键，表的大小就不会影响性能。

我建议在那里保留用户记录以保留外键约束 - 如果需要，添加外键将提高检索数据时的性能，而不是“软”外键。

如果有意义，您可以将用户与临时用户分开。

Answer 2

使用相同的表格。至于性能问题：添加一个表示“临时”的列，并且只要您不希望临时用户将其过滤为“false”。这不会减慢表格的速度（如果你还为该表添加一个索引，那就更多了。）

Answer 3

我们目前有几百个用户，这可能最终会增长到几万人。

所以你想到的是30,000到40,000个用户。除非您的用户表设计错误或索引编制不佳，否则许多用户的10倍应该不会对性能产生太大影响。但是在SO上提出这个问题不是解决问题的最佳方法。

最好的方法是在开发计算机上构建一个用户表，用你期望的10倍填充它并进行测试。我在这做了。它花了我1:53（一分53秒），这包括停下来喝一杯茶。选择一个用户需要0.049ms，并使用索引扫描。

以下是使用PostgreSQL的方法。

create table users (
  user_id integer primary key,
  user_name varchar(15) not null default '01234567890123',
  -- Use as many other text columns as you need. For testing your scenario,
  -- the values don't matter. They just make the table wider, slower, and
  -- more realistic.
  other_text_1 varchar(30) not null default '01234567890123456789012345678'
);

insert into users (user_id)
select generate_series(1,300000);

analyze users;

explain analyze
select * 
from users
where user_id = 200676;

Index Scan using users_pkey on users  (cost=0.00..8.30 rows=1 width=49) (actual time=0.014..0.015 rows=1 loops=1)
  Index Cond: (user_id = 200676)
Total runtime: 0.049 ms

对于更复杂或更随机的数据，请使用脚本语言。（Perl，ruby，python ......）

我应该为临时用户创建单独的数据库表

3 个答案: