自增&递减整数字段在sqlite数据库中可用吗？
我正在使用 id 获取数据，id 是整数主键或整数。
但是在删除任何行之后...
之后，如果我们进行选择查询以显示全部。
但它会强制关闭，因为缺少一个 id。
我希望 id 本身可以采用自动增量 & 递减。
当我在末尾删除一条记录（ig id=7）时，在此之后我添加一行，那么 id 必须是 7 而不是 8。当我删除中间的一行（ig id=3）时，所有行都会自动指定加入。
你的想法可以帮助我。
I am fetching my data with id which is Integer primary key or integer.
But after deleting any row...
After that if we make select query to show all.
But it will give force close because one id is missing.
I want that id can itself take auto increment & decrement.
when i delete a record at the end(i.g. id=7) after this i add a row then id must be 7 not 8. as same when i delete a row in middle(i.g. id=3) then all the row auto specify by acceding.
your idea can help me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
大多数具有自动递增列的系统都会跟踪最后插入的值（或下一个要插入的值），并且不会重新发出数字（给出相同的数字两次），即使最后发出的数字已从表中删除。
从你所问的来看，SQLite 是另一个这样的系统。
如果系统中存在任何并发性，那么这是有风险的，但对于单用户、一次单个应用程序的系统，您可能会逃脱：
找到下一个可用值。根据 SQLite 的行为方式，您也许可以将其嵌入到 INSERT 语句的 VALUES 列表中：
这可能不起作用；您可能必须将其作为两个操作来完成。请注意，如果存在任何并发性，则两个语句形式是一个坏主意TM。主键唯一约束通常可以防止灾难，但是两个并发语句之一会失败，因为它尝试插入另一个刚刚插入的值 - 因此它必须重试并希望获得最好的结果。显然，手机的并发性比网络服务器要低，因此问题相应地也不那么严重。但要小心。
但总的来说，最好是让序列中出现间隙而不用担心它。通常无需担心它们。如果你必须担心差距，那么首先就不要让人们制造差距。或者，当您执行删除操作创建一行时，移动现有行以填补空白。当添加新行时，最后的删除仍然会产生间隙，这就是为什么最好克服“它必须是连续的数字序列”的心态。自增保证唯一性；它不保证连续性。
Most systems with auto-incrementing columns keep track of the last value inserted (or the next one to be inserted) and do not ever reissue a number (give the same number twice), even if the last number issued has been removed from the table.
Judging from what you are asking, SQLite is another such system.
If there is any concurrency in the system, then this is risky, but for a single-user, single-app-at-a-time system, you might get away with:
to find the next available value. Depending on how SQLite behaves, you might be able to embed that in the VALUES list of an INSERT statement:
That may not work; you may have to do this as two operations. Note that if there is any concurrency, the two statement form is a bad ideaTM. The primary key unique constraint normally prevents disaster, but one of two concurrent statements fails because it tries to insert a value that the other just inserted - so it has to retry and hope for the best. Clearly, a cell phone has less concurrency than, say, a web server so the problem is correspondingly less severe. But be careful.
On the whole, though, it is best to let gaps appear in the sequence without worrying about it. It is usually not necessary to worry about them. If you must worry about gaps, don't let people make them in the first place. Or move an existing row to fill in the gap when you do a delete that creates one. That still leaves deletes at the end creating gaps when new rows are added, which is why it is best to get over the "it must be a contiguous sequence of numbers" mentality. Auto-increment guarantees uniqueness; it does not guarantee contiguity.