在多用户saas应用程序中生成序列号

Question

人们如何在典型的saas应用程序中为特定用户生成auto_incrementing整数？

例如,特定用户的所有发票的发票编号应为auto_incrementing并从1开始.在这种情况下,不能使用rails id字段,因为它在所有用户之间共享.

在我的头脑中,我可以计算用户拥有的所有发票,然后添加1,但有没有人知道任何更好的解决方案？

Answer 1

任何关系数据库的典型解决方案可能是这样的表

user_invoice_numbers (user_id int primary key clustered, last_id int)

以及存储过程或 SQL 查询，例如

update user_invoice_numbers set last_id = last_id + 1 where user_id = @user_id
select last_id from user_invoice_numbers where user_id = @user_id

它适用于用户（如果每个用户有几个同时运行的事务），但不适用于公司（例如，当您需要company_invoice_numbers时），因为同一公司内不同用户的事务可能会相互阻塞，并且会出现性能瓶颈在此表中。

您应该检查的最重要的功能要求是您的系统是否允许发票编号存在间隙。当您使用标准 auto_increment 时，您允许间隙，因为在我知道的大多数数据库中，当您回滚事务时，增量的数字将不会回滚。考虑到这一点，您可以使用以下准则之一来提高性能

1)排除用于从长时间运行的事务中获取新号码的过程。我们假设插入发票过程是一个长时间运行的事务，具有复杂的服务器端逻辑。在这种情况下，您首先获取一个新的 id ，然后在单独的事务中插入新发票。如果回滚最后一笔交易，自动编号不会减少。但user_invoice_numbers不会被长时间锁定，因此很多并发用户可以同时插入发票

2）不要使用传统的事务数据库来存储每个用户的最后一个ID的数据。当您需要维护简单的键和值列表时，有很多小型但快速的数据库引擎可以为您完成这项工作。键/值数据库列表。可能memcached是最受欢迎的。过去，我看到过一些项目使用 Windows 注册表甚至文件系统来实现简单的键/值存储。有一个目录，其中每个文件名都是密钥，每个文件内都有最后一个 id。这个粗略的解决方案仍然比使用 SQL 表更好，因为锁的发出和释放非常快，并且不涉及事务范围。

好吧，如果我的优化建议对于您的项目来说似乎过于复杂，那么现在就忘记这一点，直到您真正遇到性能问题。在大多数项目中，带有附加表的简单方法将运行得相当快。