tsd*_*own 4 database-design web-applications ruby-on-rails application-design
我们正在建立一个简单的基于网络的系统,有人添加一个记录,例如CMS页面,在网站上显示之前得到负责人的批准.
如果作者随后决定稍后编辑该页面,我们希望基于实时副本创建草稿,在批准后它将替换旧的实时页面.
我们考虑过进行完整的版本控制,但相信我们可以通过以下方式保持这种简单:只需一个草稿,2.只是一个现场,或者3.一个草稿和一个现场.
跨多个"事物"而不仅仅是页面需要此功能.
最后一个问题:你认为将这两个记录存储在同一个表中会更好,还是镜像表会更好？
我想这可能取决于但我不喜欢有两个具有相同结构的表的理想.稍微慢一点的操作(因为我们必须在显示数据时一直查询草稿)是值得的吗？
当状态发生变化时,从表到表移动东西是个坏主意.
如果要向工作流添加其他状态,则必须添加更多表.
这只是一个状态变化 - 这就是关系数据库的优化.
一个表,多个状态是标准方法.
如果您发现事情的速度非常慢 - 并且您可以证明基于状态的查询是整个原因 - 您可以求助于"物化视图"或类似技术,其中状态更改(以及由此产生的移动)由RDBMS.
每个州的表是一个坏主意.
您无法轻松添加状态.您还必须添加表格,这会让您感到痛苦.此外,您必须使用新表名更新代码以反映新工作流.
如果状态只是一个列,则添加新状态是在代码中添加新值和新的if语句.状态更改只是更新,而不是"删除插入".
数据永远持续,每次用户有一个聪明的想法时,工作流程就会出现.不要因为想要改变工作流程而惩罚他们.
你不能轻易拥有子状态.许多状态机实际上是多个嵌套的状态机.使用table-per-state添加子状态会创建更多具有更多规则的表.
如果状态只是一个列,则嵌套的子状态只是另一个在代码中带有新if语句的列.状态更改只是更新,而不是"删除插入".
您不能轻易拥有并行状态机.很多时候有许多并行状态代码更改.有时会有手动工作流程(批准)和自动化蠕虫流程(归档,复制到数据仓库等).对于每州状态和并行状态机,没有办法合理地实现它
如果每个状态只是一列,则并行状态机只是并行更新.
不。一种实体类型，一张表。
重新考虑的原因：
草稿记录的数量以千比一的比例超过现场记录。
安全条件要求直接访问数据库的某些用户在 GRANT/REVOKE 级别对草稿或实时记录具有某些权限，但对其他类型的记录不具有某些权限。
要考虑的第二种设计是一个用于 Items 的表和一个用于 LiveItems 的表。第二个表仅包含活动项目的 ID。这样您就可以维护您的单表设计，但您可以通过将单列表连接回主表来找到 LiveItem。
| 归档时间： |
|
| 查看次数： |
935 次 |
| 最近记录： |