跟踪对象的字段更改的最佳架构是什么?

Nic*_*ole 25 sql architecture scalability change-tracking

我们有一个构建在SQL数据库之上的Web应用程序.几种不同类型的对象可以添加注释,其中一些对象需要字段级跟踪,类似于在大多数问题跟踪系统上跟踪字段更改的方式(例如状态,分配,优先级).我们想要显示变更的对象,之前的值是什么,以及新值是什么.

在纯设计级别,跟踪通用表中任何对象的每个更改是最直接的,包括对象类型,对象主键,进行更改的用户的主键,字段名称和列的列.新旧价值观.在我们的例子中,如果用户在进行更改时输入了注释,这些也可以选择具有注释ID.

但是,随着这些数据增长的速度,这是最好的架构吗?通常采用哪些方法将这种类型的功能添加到已经大规模的应用程序中?

[ 编辑 ]我正在开始对这个问题的赏金,主要是因为我想特别找出在处理规模方面最好的架构是什么.Tom H.的答案是提供信息的,但推荐的解决方案似乎是相当大小的效率(对象的每个新状态都是新行,即使许多列没有改变)也不可能,因为我们必须要求能够跟踪用户创建的字段的更改.特别是,我可能会接受一个可以解释常见问题跟踪系统(JIRA或类似)如何实现这一点的答案.

Tom*_*m H 7

您可以选择几种方式.您可以拥有基本上镜像基表的审计表,但也包括更改日期/时间,更改类型和用户.这些可以通过触发器更新.此解决方案通常更适合幕后审计(IMO),而不是解决特定于应用程序的要求.

第二种选择就像你所描述的那样.您可以拥有一个通用表,该表通过类型代码保存每个单独的更改,以显示更改了哪个属性.我个人不喜欢这个解决方案,因为它可以防止对列使用检查约束,也可以防止外键约束.

第三个选项(这是我最初选择的信息)将有一个单独的历史更改表,通过应用程序更新,包括每个表的PK以及您要跟踪的列.它与第一个选项略有不同,因为应用程序将负责根据需要更新表.在您的案例中,我更喜欢这个,因为您确实有一个业务要求,而不是审计等后端技术要求.通过将逻辑放在应用程序中,您可以获得更多灵活性.也许您不想跟踪某些更改,因为它们是维护更新等.

使用第三个选项,您可以在基表中包含"当前"数据,也可以将每个历史记录保留在历史表中的列.然后,您需要查看最新的行以获取对象的当前状态.我更喜欢这样,因为它避免了数据库中重复数据的问题,或者必须查看多个表中的相同数据.

所以,你可能有:

Problem_Ticket(ticket_id,ticket_name)Problem_Ticket_History(ticket_id,change_datetime,description,comment,username)

或者,您可以使用:

Problem_Ticket(ticket_id,ticket_name)Problem_Ticket_Comments(ticket_id,change_datetime,comment,username)Problem_Ticket_Statuses(ticket_id,change_datetime,status_id,username)

  • 或者,您可以使用审计表来捕获大部分信息(从而提供跟踪任何地方所做更改的方法)和一个与change_comments相关的表,以捕获有关GUI更改的注释.只取决于审核记录的重要程度. (2认同)