数据库是神话般的资源，我们已经滥用了它们。如果你拥有一个超级稳定安全的关系数据库，那么它就可能大包大揽，它就可能变成一把锤子，用来解决一切视为钉子的问题。
在Tandem，我了解到支持公司业务的数据库是一个复杂而复杂的生物。它不仅需要提供对客户数据的访问，还需要在线DDL，高可用性，归档，异地磁带轮换和管理，在线备份，访问控制，监视和操作支持，甚至复制到远程数据中心。
当你公司拥有一个或多个DBA（数据库管理员）以及一个数据中心中的设置，公司中的每个新应用程序也都希望使用您的数据库！这是合理的，很快，他们不断地表创建表库和管理表的数据库，并且随着新功能和新应用程序被更多地添加到共享数据库系统。
随着数据库在公司运营中变得越来越重要，它变得 至关重要。需要保障数据库以24 x 7或尽可能接近的速度运行所需的所有方面，都得到了越来越多的关注。当数据库关闭时，公司也关闭了，那不是一件好事。（单点风险）
最初，每个应用程序使用其自己的表，并确保注意自己的业务。最终，读取另一个应用程序的表似乎比协商如何使用消息或接口调用另一个应用程序要容易得多。很快，一个确定的趋势增加了：应用程序和表格的熵和相互缠绕。跨表为不同应用程序进行事务更新变得很普遍。
扫描件、照片等大文件的存储
很多文档，照片甚至是电影都保存到关系数据库种，由于SQL可以接受Blob，因此它们可以将大量数据存储在数据库中。
- 这对数据库的使用者来说非常好！ 轻松，干净地存储您的随机数据，并具有备份，高可用性和神奇的存储容量。此外，数据可以与数据库中的其他内容进行事务性更新。不用担心，可以为您的数据提供最好的照顾！生活是美好的！
- 对于数据库管理员来说，这是一场噩梦！ 突然之间，您的数据库开始变得越来越胖。很快，您将购买更多昂贵的存储解决方案。诸如照片和文档图像之类的不可变数据共存于 支持您的数据库的 SAN（存储区域网络）上。这是低效的，因为SAN是设计用于就地更新的极其昂贵的高端硬件。
从数据库中提取这些珍贵而庞大的数据项并不像看起来那样容易。但是扫描纸质文档和其他介质的一成不变的性质对我们存储它们具有巨大的帮助。您可以为文档分配128位UUID，并将文档存储在其他位置。然后，可以将该标识符保存在与某些关系记录关联的数据库中。
很快，您意识到，尽管这可以将存储容量转移到更便宜的存储介质上，但仍存在挑战：
- 系统更新是非事务性的。 通常，您需要通过以下方式更新新的统一系统：
- 步骤1： 在数据库上的transaction-T1中，更新关系系统，说您打算将UUID-X对象插入应用程序可理解的表的列中。另一列管理持有不可变对象的存储区中对象的状态。
- 步骤2： 使用UUID-X将不可变对象复制到新存储中。
- 步骤3： 最后，在transaction-T2中，在附加列中更新对象的状态，以便您知道应用程序可以使用该对象。
这可能是什么问题？
- 糟糕，稍后您会发现多步插入失败可能会导致问题。 步骤1之后和步骤2之前的故障会导致放弃和不完整的插入，如在应用程序中查看表时所见。在第2步之后和第3步之前的故障使不可变存储中的废弃对象无用。
为了解决这个问题，您需要一个正在进行的插入和删除的边表。这样可以帮助实现事务处理的锁定记录。
接下来，您将意识到也最好为正在进行的工作加上时间戳，以便您可以注意到什么时候由于插入失败而足以保证清理。
- 几个月或几年后，当前的blob的不变存储已达到容量极限。 现在，您需要另一个程序来更新关系系统中的所有表以包括存储ID。这样您就可以在其他新的存储介质中继续保存blob。
这时需要引入新的一个中间者，能将Blob的管理推到新的专用表中，使用这种新的中间间接级别，您可以更轻松地管理跨数据中心的复制，甚至可以将不可变的Blob存储迁移到新的数据中心。
数据库泥球
软件工程中最大的问题之一就是解开泥泞的 大球。这些相互交织，相互依存的大量代码有时可能包含由成千上万的软件工程师策划的数千万行代码。 很多时候，共享宝贵的数据库所带来的社会和经济压力造成了您自己的大泥潭。一旦应用程序文化鼓励不受限制地访问任何表，就很难更改。在文化上很难，而且很难进行软件工程来完成更改。
改变必须是渐进的。您必须同时驾驶胡萝卜和棍子。这可以通过以下方法演变成实现解纠缠的新方法：
- 创建管道以使跨应用程序的异步工作变得容易，并且
- 跨应用程序截断对表的访问。 有时人们只是需要表的只读副本。这些是从真相之源那里异步更新的结果。
这样，有时需要多年的成功投资才能摆脱困境。
即使您将同一数据库从集中式系统转移到分布式系统，几乎可以肯定的是，在获得一定扩展的同时，应用程序的性能肯定会受到某些影响。协调锁和并发将面临不同的性能挑战，并且过渡阶段将是一条艰难之路。将应用程序调整到分布式数据库需要耐心和洞察力。
结论
如果一个公司中拥有许多数据库也是烦人又昂贵，特别是在操作数据库方面遇到的挑战。我可以给数据库用户的最佳建议是谨慎谨慎地使用它。如果可能的话：
- 管理Blob。 创建一种规范化的机制来处理Blob，即使您将它们在短期内保留在数据库中，之后再将其移至其他位置，
- 隔离应用程序。 使其他应用程序远离其他应用程序的表，
- 在应用程序之间使用消息传递。 将应用程序与某种形式的异步消息连接起来，即使该消息只是简单地实现为在单独事务中排队和出队的数据库表中的行。结合隔离应用程序，可以使得向多个数据库的迁移变得切实可行。