Chu*_*huu 15 sql database-design temporal-database database-normalization anchor-modeling
我目前正在尝试创建一个数据库,其中很大一部分数据是暂时的.在阅读了许多这样做的技术(大多数涉及6nf标准化)后,我遇到了锚点建模.
我正在开发的模式非常类似于Anchor Modeling模型,特别是因为用例(Temporal Data + Known Unknowns)是如此相似,我很想完全接受它.
我遇到的两个最大的问题是,我找不到任何详细说明这种方法的负面影响的内容,而且我找不到任何对生产中用于战争故事和陷阱的组织的引用,这些都是我需要注意的.
我想知道这里是否有人熟悉,可以简要地阐述一些否定因素(因为积极因素在研究论文及其网站上得到了很好的宣传),以及在生产环境中使用它的任何经验.
Dam*_*vic 15
以下是我所知道的几点
DB对象的数量太大而无法手动维护,因此请确保始终使用设计器来发展架构.
目前,设计人员完全支持MS SQL Server,因此如果您必须始终端口代码,您可能需要等到目标数据库完全受支持.我知道它在下拉框中有Oracle,但是......
不要期望(也不要求)开发人员理解它,他们必须通过5NF视图访问模型 - 这很好.问题是表是通过视图上的(而不是)触发器加载的,这可能(或可能不)是性能问题.
期望您可能需要编写一些额外的维护过程(对于每个时间属性),这些过程不是自动生成的(尚未).例如,我经常需要一个时间属性的修剪程序 - 在两个连续的时间事件中删除相同ID的相同值记录.
生成的视图和视图上的查询可以很好地解决,因此您将来可能会编写任何内容.但是,"其他人"将在视图上查看视图的查询 - 这并不总能很好地解决.因此,您可能需要比平时更多地监控查询.
令人伤心的是,我最近使用这种方法来重构我的仓库的一部分,它就像一个魅力.诚然,仓库没有这里列出的大部分问题.
我建议创建一个演示系统和测试,测试,测试......,尤其是第3点 - 通过触发器加载是必要的.
关于上面的第4点.重述控制几乎完成,这样您就可以防止两个连续的相同值随时间推移.
一般评论,加入并不一定是坏事.阅读:为什么加入是一件好事.
6NF在锚建模中的一大好处是非破坏性模式演化.换句话说,数据库模型的每个先前版本都可用作当前模型中的子集.此外,由于更改由架构中的扩展(新表)表示,因此升级数据库几乎是即时的,可以安全地在线完成(即使在生产环境中).这种好处将在5NF中丢失.
我没有读过任何关于它的论文,但由于它基于6NF,我预计它会受到6NF之后的任何问题的影响.
6NF要求每个表由候选键和不超过一个非键列组成.因此,在最坏的情况下,您需要9个连接才能生成10列结果集.但是你也可以设计一个数据库,比如200个5NF的表,30个BCNF的表,只有5个6NF的表.(我认为这本身就不再是Anchor Modeling,这似乎把所有表都放在6NF中,但我可能错了.)
神话人月仍然与此相关.
因此,管理问题不在于是否建立一个试点系统并将其扔掉.你会那样做的.唯一的问题是,是否提前计划建造一次性计划,或承诺向客户提供一次性计划.
小弗雷德布鲁克斯,在神话人月,第116页.
你能用多少便宜的原型来测试你预期的最坏情况？