应用错误收集

启动项目时，我经常会想到几个不同的架构。经过粗略的猜测后，我意识到有些人对增长或存储空间的优化程度低于其他人。显然，列值的大小是主要的。但表元数据，索引和行标题也都起作用。

此外，RDBMS使用与对象或键值数据库完全不同的数据存储方法。

尝试计算数据库存储的成本（或所需空间）有哪些好资源？

注意，我的问题与选择数据库无关，而是知道如何正确使用最有效的每个数据库设计。 PostgreSQL，MySQL，CouchDB等数据库都有不同的目标用例和多种方法来解决同样的问题。因此，了解每个解决方案的存储成本将有助于为架构选择最佳解决方案。

RDBMS使用与对象或键值数据库完全不同的数据存储方法。

关系模型假设您不知道将来需要哪些数据，或者将来如何访问数据。根据我的经验，这被证明是一个非常可靠的假设。

这就是SQL dbms允许您在需要时添加索引的一个原因，并让您删除已经证明无用的索引。它将允许您在已知约束时添加约束 - 有时需要添加更多表的约束 - 并在需求更改时删除约束。当您发现更多可以了解的内容时，它会让您添加列。它将允许您用视图替换表并用表替换视图。一些dbms将允许您创建物化视图 - 它们对查询速度的影响可能是巨大的，它们对磁盘使用的影响是毁灭性的。

有用的数据库可扩展其范围。根据关系模型设计的SQL数据库使得在初始设计期间添加没有人梦寐以求的功能变得相对容易，并且不会破坏系统的其他部分。所以他们被称为经常被要求做他们最初设计师无法想象的事情。

所有这些事情

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

对磁盘使用情况进行任何估计都会浪费时间。单独使用其中任何一个都可以彻底改变数据库所需的磁盘空间。

您可以非常准确地计算行和页面所需的空间。（尝试使用Google获取“YourDBMSname行布局”和“YourDBMSname页面布局”。）但是当您尝试乘以所需的行数时，您必须估计行数。这让你成为Steve McConnell称之为“cone of uncertainty”的大结局。

如果你没有在你自己的公司测量多个项目中的磁盘使用情况，估计上述那些要点的影响就是猜测。

我工作的最后一家财富100强企业拥有一个自20世纪70年代以来一直投入生产的运营数据库。数百个应用程序，在40年的时间里用超过25种编程语言编写，每天都会发生这种情况。（我认为它最初建立在IBM的IMS上;今天它运行在Oracle上。）

即使在几年前，也没有人想到他们的数据库会用于将工程图纸和物料清单翻译成中文，还可以生成他们需要的成品以外的中国海关文件。实现这些新功能需要在其实时库存中存储关于每个部件和每个设计文档的附加数据。在该项目的早期，我们的估计相当遥远。那是锥形的大头。（我们估计了几件事，但没有磁盘使用。我们被要求成功，所以无论我想出什么设计，都需要有人提供所需的磁盘空间。）但是当我们上线时，我们知道每个人的确切价值估计，因为我们已经完成了工作。（那是锥形的窄端。）

那么，您如何降低数据库设计和部署环境中猜测的风险？从1972年开始上课。

构建原型并进行测量。

  化学工程师很久以前就知道了一个有效的过程   实验室不能只在一个工厂实施。一个   中间步骤称为试验工厂是必要的   在非保护性方面扩大数量和操作的经验   环境。。。。

。。。项目之后的项目设计了一套算法，然后按照要求交付第一件事物的时间表投入到客户可交付软件的构建中。。。

因此，管理问题不是是否建立一个试验系统并扔掉它。你将这样做。唯一的问题是，是否提前计划建造一次性，或承诺向客户提供一次性。

小弗雷德布鲁克斯， The Mythical Man-Month ，第116页。

如何计算数据库设计存储成本？

2 个答案: