共用一个大数据库是一种商业自杀? - Charlton

21-09-29 banq

您可以通过多种方式进行商业自杀,但可能没有比尝试伟大的架构目标(所有应用程序都与之对话的单一权威数据库)所产生的死亡更慢、更痛苦的死亡方式了。

如果我们有一个单一的数据库,那么我们将所有的业务信息放在一个地方,所有人都可以访问,易于报告,降低维护成本,所有应用程序的一致性,以及许多其他良好的目标。

然而,所有这些崇高的理想都隐藏了一个更根本的问题,即单一的数据库并不能解决其中的任何一个问题,并且将它们中的大多数变成了更大的问题。

 

所有信息都集中在一个地方——单一权威(单点风险)

从表面上看,这听起来像是一个伟大的目标——毕竟开发人员都在努力遵循“不要重复自己”的格言——而且许多地方的数据显然违反了这一原则。

出现在许多应用程序和许多存储机制中的数据会导致各种大规模问题;不一致、重复、复制、重复的业务逻辑和代码,基本上都归结为——你最终得到意大利面条式的数据。意大利面数据很像意大利面代码,它会蔓延开来,纠缠在一起,如果不把自己裹在意大利面酱里,就很难拆开。这显然是一件“坏事”。

 

那么有什么问题呢?

首先也是最明显的错误是所有应用程序都有不同的要求和不同的“世界观”。尽管理论上可能存在针对整个组织的“客户”的某些概念,但即使是这种最基本的数据项在各个部门之间甚至单个部门内的各个应用程序之间也存在很大差异。

你可以解决这个问题,就像许多以数据库为中心的人所做的那样,并说“这就是问题所在,我们需要标准化所有这些应用程序以使用一个真正的客户”。但这遗漏了问题定义中真正重要的词:“需求”,客户在业务的不同上下文是不同的。

您的数据库人员可能会说“好吧,您的应用程序中的客户可能会因您的要求不同而有所不同,但您只需将其放入我们的一个真正的客户中即可”,现在你正试图从基于需求的客户映射到一个真正的客户,并花费过多的时间在你的应用程序中维护这个翻译层。当那个真正的客户发生变化时,他无疑会因为新的应用程序需要他被扩展以处理他们需要的更多数据,需要重新访问以前的每个应用程序,其中大部分不需要重写,整个应用程序需要再次进行回归测试。并且您必须为与您的单一权限数据库通信的每个应用程序执行此操作。

 

关于唯一真正权威的真相

事实是,数据必须有上下文——没有上下文,数据毫无价值,绝对和完全没有价值。存储在数据库中的数据没有上下文,因此没有价值。上下文由读取和写入该数据的应用程序提供,因此它们是唯一重要的东西,它们的需求也是唯一重要的东西。这意味着,他们需要特定于其应用程序的数据,其结构方式可以使该应用程序满足业务目标,并使该应用程序满足非功能性要求,例如弹性、可靠性和一致性。

 

那么为什么有人想要一个真正的权威数据库呢?

好吧,用传统术语来说,很容易理解为什么数据库管理员和数据库开发人员想要它——这是他们的命脉,他们存在的全部理由。更重要的是他们成长的文化——数据很重要,数据是宇宙的中心,数据必须是一致的、统一的、纯粹的。

但撇开数据库开发人员不谈,更重要的是,公司为什么需要一个真正的权威数据库 (OTADB)?毕竟,这篇文章的标题说这是“商业自杀”,那为什么没有传达给管理层呢?

好吧——OTADB 的承诺是它将减少重复错误、减少浪费、减少重复工作并降低维护成本——所有这些都是非常理想的业务目标。事实上,对于那些提倡这种方法的人(再次是那些数据库管理员和开发人员),OTADB 听起来非常有吸引力。从表面上看,它实现了所有这些目标。

失败的地方在于,这个软件开发的圣杯总是遥不可及,他们从来没有设法实现它。开发的每个应用程序都开始使 OTADB 变得更糟,人们开始对其进行黑客攻击以使其满足业务需求,这不是因为开发人员想要一起黑客攻击,而是因为 OTADB 的限制迫使他们这样做如果他们要提供任何类型的功能。

他们指责这些黑客破坏了他们对 One True Authority 数据库的愿景,数据库管理员告诉他们,他们必须与应用程序团队抗争以阻止他们搞砸他们的好数据库,但 OTADB 不再像那些讨厌的人那样满足崇高的目标开发团队已经为每个人搞砸了。

 

顺其自然

这是我们一开始试图实现的真正商业目标……避免企业自杀。

当每个应用程序都对自己的数据、自己的行为负责,并且只负责让“企业”知道他们进行了一些其他事情可能需要了解的更改时,您就有了自己的解决方案。

在良好的开发术语中,我们有适当的关注点分离……应用程序对其数据负责,并且仅对它们的数据负责。他们决定是否关心来自其他应用程序的数据——他们不会被迫使用它,也不会被迫解决它。

 

1
猜你喜欢