如何对任务进行双重检查（如何将其存储在数据库中）？
我有一个数据库，在不同的表中存储不同类型的任务和更多项目。 在许多这样的表中（它们的结构不同），我需要一种方法来做到这一点，即必须仔细检查该项目，这意味着该项目无法“保存”（我的意思是它当然会被保存）在其他人进入程序并确认之前。
正确的说法应该是什么：
- 每个表都应该有一列“IsConfirmed”，然后当那个人想要确认所有内容时，程序会遍历所有表并创建一个项目列表未检查的。
- 应该有第三个表来保存必须确认的该行的表名和 ID。
- 我希望你有比上面两个丑陋的更好的想法。
I have a DB that stores different types of tasks and more items in different tables.
In many of these tables (that their structure is different) I need a way to do it that the item has to be double-checked, meaning that the item can't be 'saved' (I mean of course it will be saved) before someone else goes in the program and confirms it.
What should be the right way to say which item is confirmed:
- Each of these tables should have a column "IsConfirmed", then when that guy wants to confirm all the stuff, the program walks thru all the tables and creates a list of the items that are not checked.
- There should be a third table that holds the table name and Id of that row that has to be confirmed.
- I hope you have a better idea than the two uglies above.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于一个实体来说，双重确认状态是否只发生一次？还是可以被拒绝，需要再次确认？在后一种情况下，您需要保留所有这些历史记录吗？您是否需要跟踪每次确认的人员（例如，这样就不会由同一个人执行两次确认）？
简单的情况：
第一次确认时：
第二次确认时：
被拒绝时：
现在显然您的后台作业只能处理 Processed = 0 和ConfirmCount = 2 的行。然后当它处理该行时：
如果您有比这更复杂的场景，请提供更多详细信息，包括双重确认过程的目标。
Is the double-confirmed status something that happens exactly once for an entity? Or can it be rejected and need to go through confirmation again? In the latter case, do you need to keep all of this history? Do you need to keep track of who confirmed each time (e.g. so you don't have the same person performing both confirmations)?
The simple case:
When the first confirmation:
On second confirmation:
When rejected:
Now obviously your background job can only treat rows where Processed = 0 and ConfirmCount = 2. Then when it has processed that row:
If you have a more complex scenario than this, please provide more details, including the goals of the double-confirm process.
考虑添加一个新表来保存要确认的记录（例如TasksToBeConfirmed）。确认记录后，将这些记录移至永久表（任务）。
添加“IsConfirmed”列的缺点是，几乎每个使用该表的 SQL 语句都必须对“IsConfirmed”进行过滤，以防止获取未经确认的记录。每次错过这一点，就会引入缺陷。
如果您需要确认和未确认的记录，请使用 UNION。
这种模式需要更多的编码和实现工作，但根据我的经验，它可以显着提高性能并减少缺陷。
Consider adding a new table to hold the records to be confirmed (e.g. TasksToBeConfirmed). Once the records are confirmed, move those records to the permanent table (Tasks).
The disadvantage of adding an "IsConfirmed" column is that virtually every SQL statement that uses the table will have to filter on "IsConfirmed" to prevent getting unconfirmed records. Every time this is missed, a defect is introduced.
In cases where you need confirmed and unconfirmed records, use UNION.
This pattern is a little more work to code and implement, but in my experience, significantly improves performance and reduces defects.