【问题标题】:Storing historical changes to data in SQL for reporting在 SQL 中存储对数据的历史更改以进行报告
【发布时间】:2021-11-20 11:30:03
【问题描述】:

我管理一个预订应用程序,我已通过 PR 以启用报告,我被要求提供的报告之一是显示给定日期范围内资源的直到化的报告。

我正在尝试找出存储资源历史更改的最佳方式,以便准确报告利用率百分比。

例如。

1 月 1 日到 1 月 12 日,可能有 10 个资源,如果每天都预订了所有 10 个资源,那么我会显示 100% 直到,但是,如果有人在未来的任何时候再添加 10 个资源,我的数字将不正确如果在添加这些资源后在上述日期范围内再次运行报告。

我想如果有资源的添加/删除,我可能会将计数存储在一个不同的表中,但这是最好的解决方案吗?从报告的角度来看,当我稍后查询数据时感觉非常混乱,因为我可能在一天内可能会有多行添加,例如我需要处理。

我想接触这里的思想,看看是否有不同的角度可以让我探索思想,让我找到更好的解决方案。

我的应用程序是一个 dotnet 5 webapp,在 Azure 中运行,该应用程序与 Azure 函数 API 对话,后者又使用 Azure SQL 进行持久性。

提前非常感谢您给我的任何建议!

【问题讨论】:

  • 可能最好的解决方案是使用为system versioning提供的支持
  • “资源”是否会跟踪(有列)何时“添加”和“删除”?你有单独的表 | ResourcePKey | Added | Removed | 吗?在您的示例(1.-12. Jan 的计算)中,您是否考虑过如何在 6 日添加的资源中进行计算?
  • @Fildor 感谢您的回复,目前资源没有添加/删除的数据,但是,这是我可以添加的,一个非常有用的建议谢谢,我没有充分考虑在日期范围的中间添加资源和添加/删除日期列将使这种对账更容易。目前还没有额外的表格,我目前处于范围/发现阶段,我上面的描述是此时的建议。 :-)
  • 感谢您的建议@Stu 我现在就去看看!

标签: sql .net azure .net-core azure-sql-database


【解决方案1】:

时态表允许您跟踪和分析数据更改的完整历史记录,而无需自定义编码。保存任何历史数据将使用额外的数据库存储和其他 CPU 资源,因为每个 CRUD 操作都将作为单独的实体保存在时态表中。

根据您是开始新开发还是升级现有应用程序,您将创建临时表或通过添加临时属性来修改现有表。在 SQL Server Management Studio (SSMS) 上或作为 Transact-SQL 语句执行这些操作。

  1. 在 SSMS 中,使用 Tables -> New -> System-Versioned Table... 路径为现有表创建临时表。

  1. 使用 T-SQL 创建时态表。

注意:每个时态表的强制性元素是 PERIOD 定义和 SYSTEM_VERSIONING 子句,并引用另一个将存储历史行版本的用户表:

CREATE TABLE WebsiteUserInfo
(  
    [UserID] int NOT NULL PRIMARY KEY CLUSTERED
  , [UserName] nvarchar(100) NOT NULL
  , [PagesVisited] int NOT NULL
  , [ValidFrom] datetime2 (0) GENERATED ALWAYS AS ROW START
  , [ValidTo] datetime2 (0) GENERATED ALWAYS AS ROW END
  , PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
 )  
 WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.WebsiteUserInfoHistory));

您还可以将现有表扩展为临时表,如下例所示:

ALTER TABLE WebsiteUserInfo
ADD
    ValidFrom datetime2 (0) GENERATED ALWAYS AS ROW START HIDDEN  
        constraint DF_ValidFrom DEFAULT DATEADD(SECOND, -1, SYSUTCDATETIME())
    , ValidTo datetime2 (0)  GENERATED ALWAYS AS ROW END HIDDEN
        constraint DF_ValidTo DEFAULT '9999.12.31 23:59:59.99'
    , PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo);

ALTER TABLE WebsiteUserInfo  
SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.WebsiteUserInfoHistory));
GO

CREATE CLUSTERED COLUMNSTORE INDEX IX_WebsiteUserInfoHistory
ON dbo.WebsiteUserInfoHistory
WITH (DROP_EXISTING = ON);

来源:https://docs.microsoft.com/en-us/azure/azure-sql/temporal-tables

【讨论】:

    猜你喜欢
    • 2010-09-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-06-30
    • 1970-01-01
    • 2015-07-11
    相关资源
    最近更新 更多