如何在同一张表上实现每个用户的自动增量?

发布于 2024-09-01 03:21:09 字数 1327 浏览 10 评论 0原文

我希望多个用户共享数据库中的相同表,但每个用户都有一个 auto_increment 值。我将使用嵌入式数据库 JavaDB,据我所知它不支持此功能。我该如何实施?

我应该在插入上实现一个触发器来查找用户最后插入的行,然后添加一个,还是有更好的替代方案?或者在应用程序代码中实现这个更好?

或者这只是一个坏主意?我认为这比为每个用户创建新表更容易维护。

示例:

table
+----+-------------+---------+------+
| ID | ID_PER_USER | USER_ID | DATA |
+----+-------------+---------+------+
|  1 |           1 |       2 | 3454 |
|  2 |           2 |       2 | 6567 |
|  3 |           1 |       3 | 6788 |
|  4 |           3 |       2 | 1133 |
|  5 |           4 |       2 | 4534 |
|  6 |           2 |       3 | 4366 |
|  7 |           3 |       3 | 7887 |
+----+-------------+---------+------+

SELECT * FROM table WHERE USER_ID = 3
+----+-------------+---------+------+
| ID | ID_PER_USER | USER_ID | DATA |
+----+-------------+---------+------+
|  3 |           1 |       3 | 6788 |
|  6 |           2 |       3 | 4366 |
|  7 |           3 |       3 | 7887 |
+----+-------------+---------+------+

SELECT * FROM table WHERE USER_ID = 2
+----+-------------+---------+------+
| ID | ID_PER_USER | USER_ID | DATA |
+----+-------------+---------+------+
|  1 |           1 |       2 | 3454 |
|  2 |           2 |       2 | 6567 |
|  4 |           3 |       2 | 1133 |
|  5 |           4 |       2 | 4534 |
+----+-------------+---------+------+

I would like to have multiple users that share the same tables in the database, but have one auto_increment value per user. I will use an embedded database, JavaDB and as what I know it doesn't support this functionality. How can I implement it?

Should I implement a trigger on inserts that lookup the users last inserted row, and then add one, or are there any better alternative? Or is it better to implement this in the application code?

Or is this just a bad idea? I think this is easier to maintain than creating new tables for every user.

Example:

table
+----+-------------+---------+------+
| ID | ID_PER_USER | USER_ID | DATA |
+----+-------------+---------+------+
|  1 |           1 |       2 | 3454 |
|  2 |           2 |       2 | 6567 |
|  3 |           1 |       3 | 6788 |
|  4 |           3 |       2 | 1133 |
|  5 |           4 |       2 | 4534 |
|  6 |           2 |       3 | 4366 |
|  7 |           3 |       3 | 7887 |
+----+-------------+---------+------+

SELECT * FROM table WHERE USER_ID = 3
+----+-------------+---------+------+
| ID | ID_PER_USER | USER_ID | DATA |
+----+-------------+---------+------+
|  3 |           1 |       3 | 6788 |
|  6 |           2 |       3 | 4366 |
|  7 |           3 |       3 | 7887 |
+----+-------------+---------+------+

SELECT * FROM table WHERE USER_ID = 2
+----+-------------+---------+------+
| ID | ID_PER_USER | USER_ID | DATA |
+----+-------------+---------+------+
|  1 |           1 |       2 | 3454 |
|  2 |           2 |       2 | 6567 |
|  4 |           3 |       2 | 1133 |
|  5 |           4 |       2 | 4534 |
+----+-------------+---------+------+

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

江湖正好 2024-09-08 03:21:09

如果您可以保证每个用户只有一个会话,那么这样做是非常安全的。如果一个用户可以拥有多个会话,那么无论您是在触发器中还是在应用程序代码中执行此操作,您都需要采用独占表锁,以确保您所在的会话是唯一获得下一个数字的会话。

但不要为每个用户分配一张桌子。这会让你的 sql 变得非常丑陋,并阻止任何类型的 sql 计划共享。

使用时间戳而不是序列号可能会为您提供更好的服务。

If you can guarantee that there will only be one session per user, then it would be pretty safe to do. If a user can have more than one session then whether you do this in a trigger or in the application code you will need to take an exclusive table lock to make sure that the session you are in is the only one to get that next number.

But don't go for a table per user. That would make your sql really ugly and prevent any sort of sql plan sharing.

You may be better served by using a timestamp instead of a serial number.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文