在启动项目时，我经常会想到几个不同的模式。经过粗略的猜测，我意识到有些在增长或存储空间方面的优化程度不如其他。显然，列值的大小是最重要的。但表元数据、索引和行标题也都起到了一定的作用。
此外，RDBMS使用与对象或键值数据库完全不同的数据存储方法。
有哪些好的资源可以用来计算数据库存储的成本（或所需的空间）
注意，我的问题与选择数据库无关，而是知道如何最有效地利用每个数据库的设计。PostgreSQL、MySQL、CouchDB等数据库都有不同的目标用例和解决同一问题的多种方法。因此，了解每个解决方案的存储成本将有助于为架构选择最佳解决方案。
RDBMS使用与对象或键值数据库完全不同的数据存储方法。
关系模型假设您不知道将来需要什么数据，也不知道将来如何访问数据。根据我的经验，这是一个非常可靠的假设。
这就是SQL dbms允许您根据需要添加索引，并允许您删除已证明毫无用处的索引的原因之一。它将允许您添加已知的约束（有时需要添加更多表的约束），并在需求变化时删除约束。它将允许您在发现更多值得了解的内容时添加列。它将允许您用视图替换表，并用表替换视图。一些dbms将允许您创建物化视图——它们对查询速度的影响可能是巨大的，对磁盘使用率的影响是毁灭性的。
有用的数据库扩展了它们的覆盖范围。根据关系模型设计的SQL数据库可以相对容易地添加初始设计过程中无人想到的功能，并且不会破坏系统的其他部分。因此，他们经常被要求做他们最初的设计师没有想到的事情。
所有这些东西
- 随时间增加和减少索引
- 随时间增加和减少约束
- 随着时间的推移添加和删除列
- 随着时间的推移添加和删除表
让对磁盘使用情况的任何估计看起来都像是在浪费时间。其中任何一个单独使用都可以极大地改变数据库所需的磁盘空间。
您可以相当准确地计算一行和一页所需的空间。（试试谷歌上的"YourDBMSname行布局"one_answers"YourBMSname页面布局"。）但当你试图乘以所需的行数时，你必须估计行数。这会让你处于史蒂夫·麦康奈尔所说的"不确定性锥"的顶端。
如果您还没有在自己的公司测量过多个项目中磁盘的使用情况，那么估计上面这些要点的影响只是猜测。
我工作的最后一家财富100强公司有一个运营数据库，自20世纪70年代以来一直在生产。在40年的时间里，每天都有数百个应用程序用超过25种编程语言编写。（我认为它最初是建立在IBM的IMS上的；现在它运行在Oracle上。）
即使在几年前，那里也没有人想到他们的数据库会被用来将工程图纸和材料清单翻译成中文，还可以用来制作将成品运出中国所需的海关文件。实现这些新功能需要在其实时库存中存储关于每个零件和每个设计文档的额外数据。在那个项目的早期，我们的估计是非常遥远的。这是锥体的大末端。（我们估计了几件事，但没有估计磁盘使用量。我们必须成功，所以无论我想出什么设计，都需要有人来提供所需的磁盘空间。）但当我们上线时，我们知道每个估计的确切价值，因为我们已经完成了这项工作。（那是圆锥体的窄端。）
那么，在数据库设计和部署环境中，如何降低猜测的风险呢？吸取1972年的教训。
构建一个原型，并对其进行测量。
化学工程师很久以前就知道实验室不可能只在一个工厂里一步到位。一称为中试装置的中间步骤对于扩大数量和在非保护条件下操作的经验环境。
一个又一个项目设计了一套算法，然后按照要求交付第一个构建的东西的时间表，投入到客户可交付软件的构建中。
因此，管理问题不在于是否建立一个试点系统并将其扔掉。你会那样做。唯一的问题是，是提前计划构建一次性产品，还是承诺将一次性产品交付给客户。
小弗雷德·布鲁克斯，《神话人物月》，第116页。
这是一篇我觉得有用的AskTom文章。不过这是Oracle特有的。
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:266215435203