父子关系：objectID —— parentID
关联关系：objectID —— targetID

时间字段：不考虑存储空间的问题时，通常用DateTime字段类型；
关系表主键： RelationID

XXX信息表： XXX 或者 XXXInfo  信息实体
XXX信息快照表： XXXSnap  信息行记录的复制，可用于回溯和恢复
XXX信息日志表： XXXLog   信息变更记录，仅用于记录变更记录，通常包括:变更类型，变更内容（系统备注），操作人员备注；在时间轴上更为精细；在数据轴上，比较粗粒度。
XXX信息记录表： XXXRecord  信息变更历史，强调有意义的经历，比如工作经历、薪水发放记录等
XXX信息细节表： XXXDetail  信息的相关明细记录 

关于逻辑删和实际删除的操作：
如果表之间关联较少（最好只有一个表），可以考虑物理删除；
如果涉及多个表的操作，最好做逻辑删除；可以在日后的维护时，对大量的垃圾数据进行批量清理。
逻辑删除可以放入一个标记字段（或者某个状态字段，或者单独的一个逻辑删除标识字段），在正常业务逻辑对数据操作时，要增加对删除逻辑数据的过滤。

关于可审计的操作：

（1）所有的写操作保留操作日志；操作日志通常仅用于查询变化，不用于业务判断。可以有不同的粒度：系统级日志、功能级日志、数据级日志。

（2）关键操作，还要对原记录生成快照；通过快照，可以形成链表式的回溯检索；

（3）当前资源始终为最新内容；同时记录最新快照。

（4）快照记录：记录某一个记录变化前的镜像数据，可以通过前后的快照、或者跟当前记录比较，得出变化的内容；优点的是记录全面，缺点是冗余数据较多，尤其当只有个别数据发生变化时。另外的一种变通办法是，把易变的字段放入快照中，减小快照的冗余字段。

快照记录还有另外的一个问题是对审计的支持不够，尤其是在反映将来、现在、过去（快照）的过程变化时，会有些问题。当需要支持某一个变化的审批过程时，应该还需要另外的表来支持。

（5）变动记录：在一条变动记录中，同时记录下变化前和变化后的变化了的数据内容，比快照直观一些，但如果可变化的字段较多时，而实际变化又很少的时候，会显得比较啰嗦。可以有两种方式：

（a）将表中所有易变字段都计入一个表中，每一个字段都包括变化前后的记录（变为两个字段）；优点是可以适应多种业务数据的变化支持，缺点是冗余字段多；

（b）如果业务变动较少，可以根据业务变化的不同，增加不同的业务变化的前后数据的支持；优点是冗余数据少，缺点是如果业务变动类型多时，会需要增加不同的表来支持，另外对业务变化也支持不够；