在研究内容管理系统时,我遇到了一些困难。回到我的数据模型,我注意到一些问题可能随着时间的推移变得更加普遍。
也就是说,我想维护一个由用户修改记录的审计跟踪(更改日志)(甚至会记录用户记录的修改)。由于包含任意数量的模块,我不能对主键使用按表自动递增字段,因为它在试图将主键维护在单个表中时不可避免地会导致冲突。
审计跟踪将记录
user_id
,
record_id
,
timestamp
,
action
(插入/更新/删除),以及
archive
(旧记录的序列化副本)
我已经考虑了一些可能的解决方案,例如生成
UUID
应用程序逻辑中的主键(以确保跨数据库平台的兼容性)。
我考虑过的另一个选择(我相信即使考虑到这种方法,共识也会是否定的)是,创建一个
RecordKey
表,以维护全局自动递增的键。然而,我相信有更好的方法来实现这一点。
最后,我很想知道在尝试实现这一点时应该考虑哪些选择。例如,我打算允许(至少开始)mysql和sqlite3存储的选项,但我担心每个数据库如何处理
UUID
S.
编辑使我的问题不那么含糊:
对于我的问题,使用全局ID是推荐的解决方案吗?如果是这样,使用128位UUID(应用程序或数据库生成)我可以在表设计中做些什么来帮助最大限度地提高查询效率?
