RDBMS use a completely different approach to data storage than object or key-value databases.

关系模型假设您不知道将来需要什么数据,或者将来如何访问数据.这在我的经验中被证明是一个非常可靠的假设.

这就是sql dbms将允许您根据需要添加索引的原因之一,并让您放弃已证明无用的索引.它将允许您添加约束,因为它们变得已知 – 有时需要添加更多表的约束 – 随需求变化而丢弃约束.当您发现更多有助于了解的内容时,它会让您添加列.它将允许您用视图替换表,并用表替换视图.一些dbms将允许您创建物化视图 – 它们对查询速度的影响可能会非常显着,并且会对磁盘使用造成影响,具有破坏性.

有用的数据库扩展了其覆盖根据关系模型设计的sql数据库使初始设计中没有人想到的功能相对容易,并且不会破坏系统的其他部分.所以他们经常被要求做最初设计师没想到的事情.

所有这些事情

>随着时间的推移添加和删除索引,
>随着时间的推移添加和删除约束,
>随着时间的推移添加和删除列,
>随着时间的推移添加和删除表格,

对磁盘使用的估计看起来像是浪费时间.任何一个人都可以大幅度地更改数据库所需的磁盘空间.

您可以相当准确地计算行和页面所需的空间. (尝试Google“YourDBMSname行布局”和“YourDBMSname页面布局”.)但是,当您尝试乘以所需的行数时,您必须估计行数.这让你处于史蒂夫·麦康奈(Steve McConnell)所说的“cone of uncertainty”的大端.

如果您自己的公司在多个项目中没有测量多个项目的磁盘使用情况,估计以上这些项目点的影响只是猜测.

自从上世纪70年代以来,我所工作的财富100强公司拥有一个运行数据库. 40多年来,数以百计的应用程序以超过25种编程语言编写,每天都会播放这些东西. (我认为它最初建立在IBM的IMS上;今天它运行在Oracle上.)

即使在几年前,没有人会想到他们的数据库将用于将工程图纸和物料清单翻译成中文,并且还要生产他们需要将成品从中国出来的海关文件.实施这些新功能需要存储有关每个部分的附加数据以及其实际库存中的每个设计文档.在这个项目的初期,我们的估计是相当遥远的.这是圆锥的大端. (我们估计有几件事情,而不是磁盘使用,我们被要求成功,所以无论我想到什么设计,都有人需要提供所需的磁盘空间).但是当我们上线的时候,我们知道每个估计,因为我们已经完成了这项工作. (那是圆锥的窄端)

那么,如何减轻数据库设计和部署环境中的猜测风险？从1972年开始吸取教训.

建立一个原型,并测量它.

Chemical engineers learned long ago that a process that works in the
laboratory cannot be implemented in a factory in only one step. An
intermediate step called the pilot plant is necessary to give
experience in scaling quantities up and in operating in nonprotective
environments. . . .

. . . Project after project designs a set of algorithms and then plunges into construction of customer-deliverable software on a schedule that demands delivery of the first thing built. . . .

The management question,therefore,is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway,or to promise to deliver the throwaway to customers.

弗雷德布鲁克斯小姐,在神话人月,第116页.