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