即使数据在概念上可能不相关，我是否应该标准化类似的模式？

发布于 2024-10-28 18:07:34 字数 898 浏览 1 评论 0原文

假设我有一个事物表，我需要保留一些关于谁、何时以及何地对这些事物进行了某些操作的审计信息。

基本模式可能如下所示：

Things
  - ID
  - ThingName
  - CreatedOn
  - CreatedBy
  - CreatedIn
  - LastModifiedOn
  - LastModifiedBy
  - LastModifiedIn
  - HiddenOn (nullable)
  - HiddenBy (nullable)
  - HiddenIn (nullable)

这让我有点烦恼。来自 OOP，并且考虑到这些数据将主要由 linq-to-sql 消耗，感觉我可以将重复字段提取到一个单独的结构中，这也将充当某种模式契约：

Actions
  - ID
  - ExecutedOn
  - ExecutedBy
  - ExecutedIn

Things
  - ID
  - ThingName
  - CreatedAction -> Actions.ID
  - LastModifiedAction -> Actions.ID
  - HiddenAction (nullable) -> Actions.ID

然后我可以重用操作表，用于存储数据库中可能拥有的其他事物的相同审核信息。会有很多外键指向该表。

我担心聚合与数据库许多部分相关的数据从长远来看是否会导致问题。我想知道，

这会成为插入争用的根源（使用 SQL Server 2008）吗？
通过这些字段进行搜索是否会变得更加昂贵，因为会有更多的行，我可以通过在鉴别器上对其进行索引来减轻这种情况吗？
一般来说，好主意还是坏主意？

谢谢

原文

Lets say I have a table of things, and I need to keep some auditing information on who, when and where was something done to the things.

A basic schema could look like:

Things
  - ID
  - ThingName
  - CreatedOn
  - CreatedBy
  - CreatedIn
  - LastModifiedOn
  - LastModifiedBy
  - LastModifiedIn
  - HiddenOn (nullable)
  - HiddenBy (nullable)
  - HiddenIn (nullable)

This bugs me a bit. Coming from OOP, and given that this data will be primarily consumed by linq-to-sql, it feels like I could extract the repeated fields into a separate structure, which would also act as a schema contract of sorts:

Actions
  - ID
  - ExecutedOn
  - ExecutedBy
  - ExecutedIn

Things
  - ID
  - ThingName
  - CreatedAction -> Actions.ID
  - LastModifiedAction -> Actions.ID
  - HiddenAction (nullable) -> Actions.ID

I could then reuse the Actions table for storing the same auditing information for other Things I might have in the database. There would be a lot of foreign keys pointing to this table.

I'm concerned on whether aggregating data related to many parts of the database could cause problems in the long run. I'm wondering,

Would this become a source of insert contention (Working with SQL Server 2008)?
Would searching by those fields become more expensive because there will be a lot more rows, and could I mitigate that by indexing it on a discriminator?
Generally, good idea or bad?

Thanks

分享到QQ

分享到微博

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

发布评论

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

青春有你 2024-11-04 18:07:34

总的来说，这似乎是一个相当可靠的设计，尽管很大程度上取决于实际业务环境的具体情况和细节。一些想法：

您正在跟踪许多实体：多种事物，以及“操作”实体。行动不再是事物的一部分，它是它自己的事物。（幸运的是，您不需要输入操作来记录操作上完成的工作，对吧？）
如果您想快速提取对某种特定事物采取的操作，您可能需要有一列（您的“鉴别器”） ”）在 Actions 表中表示采取该 Action 的事物的种类。（仅仅为了确定类型而必须连接 N 个不同的事物表往往会降低性能。）
单个操作是否可以对多个事物产生影响（例如，创建一个新事物并修改现有事物））？建模起来会更复杂。
在这里，您可以在“操作”表中记录对某个事物执行的所有操作，并且在事物表中仅记录 3 种操作类型（创建、修改、隐藏）中最近执行的操作。当采取其中一种类型的新操作时，最后一个操作（如果有）将从事物表中删除……但该“旧”操作事件仍记录在操作表中。对于您的业务目的来说，数据是有用的还是不相关的？
至于插入争用，这取决于您使用的 RDBMS。这是一个老问题，大多数现代系统已经非常擅长处理它。构建、测试、观察阻塞和长事务问题，你应该没问题。
如果表变大，则建立索引。如果您经常按操作类型搜索或过滤，请添加该鉴别器列并将其包含在索引中（同样，不同的 RDBMS 有不同的索引功能，请阅读文档以了解什么最适合您。）

好主意吗？坏主意？完全取决于您的业务环境的性质及其数据保存/检索要求。希望这可以帮助您进行分析和决策。