Sof*_*tic 10 database database-design
我看到很多数据库设计在所有表上都有以下审计列......
从一个角度来看,我从以下视图中看到了表...
我看到很多设计师盲目地将所有审核专栏都放到了所有表中,这种做法是否良好,如果是的话可能是什么原因......
我只是想知道,因为对我而言似乎不合逻辑.我很难弄清楚他们为什么这样设计数据库？我不是说他们错了或是对的,只是想知道为什么？
如果有其他审计模式或解决方案,您也可以建议我......
感谢致敬
这些列是为了 DBA 和数据库开发人员的利益。它们只是提供了一种快速机制来回答诸如“此记录上次更改时间是什么时候？”之类的问题。“谁改的？” 它们不够健壮或不够细粒度，无法满足 SOX、HIPAA 或其他任何要求。
在每个表上都有这些列更容易。所有数据都可以更改，因此了解更改何时发生非常有用，尤其是在数据不应该更改的情况下。通过使用数据字典生成脚本，可以自动化添加它们的过程。
通过触发器或某些类似机制独立于应用程序填充这些列是一种很好的做法。这些列是元数据，应用程序不应该真正意识到它们。
依靠成熟的审计跟踪来提供此功能通常不是一种选择。出于合规目的收集的审计数据通常具有受限访问权限，并且实际上可能存储在单独的物理位置。
数据审计是许多业务系统所必需的内部控制(请参阅Sarbanes Oxley,了解原因).它必须在数据库级别,以确保捕获所有更改,尤其是未经授权的更改.
即使使用查找表,未经授权的更改也可能会对您的系统产生影响,因此了解谁进行了更改以及何时进行更改非常重要.什么时候特别重要,因为它有助于dbas知道在多大程度上获取备份以便意外或恶意地更改信息.
我们认为我们所有的员工都值得信赖,但许多盗窃的个人数据和破坏公司数据的恶意变更来自内部资源(这就是为什么让许多心怀不满的员工很危险),几乎所有的欺诈行为都是如此.然而,大多数程序员似乎认为他们只需要防范外部威胁.
当然,您仍然会有一些人可以进行未经授权的更改,但您无法阻止系统管理员执行此操作.但至少通过审计可以限制数据损坏的可能性(在雇用dbas时要特别小心,并且不允许在数据库服务器上使用其他任何管理员权限).
许多应用程序是使用某种 OOP 语言开发的，其中通常有一个像BusinessObject这样的类，其中包含通常被认为有用的信息，例如审计字段。并非所有子类化实体都需要它，但如果需要的话它就在那里。由于数据库的开销很小，并且客户端有可能根据审计字段请求另一个奇怪的统计数据，因此拥有它们比根本没有它们更好。如果某些内容代表静态信息列表（例如国家/地区名称），我通常根本不会将其放入数据库中 - 枚举数据类型就是为了此类目的而创建的。
| 归档时间： |
|
| 查看次数： |
12628 次 |
| 最近记录： |