集中管理您的数据完整性

系统（即数据库）管理自身的数据完整性听起来很合理，在简单的场景中确实如此。然而，当业务规则变得复杂时，在中央位置验证数据就变得更加困难。

当系统（即数据库）无法再强制执行数据的结构时，必须由其他东西来弥补这一空缺。这种情况何时会发生？

美国的电话号码格式是（区号）（前缀）–（号码），例如：(734) 555-3212。为了简单起见，我们将在本文中讨论数据库，但数据存储不一定是数据库。

美国的电话号码总是有十位数字（我们忽略国际号码）。电话号码可以有多种格式：

• xxx.xxx.xxxx
• xxx-xxx-xxxx
• (xxx) xxx-xxxx
• (xxx) xxx.xxxx

大多数数据库仅限于数据类型（即数字、字符串、日期等），不支持格式化。许多应用程序选择使用字符串数据类型来存储电话号码。然而，字符串数据类型接受任何字符串。为了确保电话号码有效，我们需要一个额外的验证层。

在单个应用程序连接到单个数据库的情况下，数据验证通常在应用程序中强制执行。

当您的架构增长到两个或多个应用程序共享一个数据库时，会发生两件事：

1. 每个应用程序都有自己的数据验证：

2. 有一个中央服务，应用程序调用它来验证数据并持久化数据：

在多个位置进行数据验证的风险是验证可能不同步。对一个应用程序有效的格式可能对另一个应用程序无效。在最坏的情况下，错误的格式会抛出错误，或在极端情况下导致应用程序崩溃。

最佳做法是集中管理数据验证，以便存储在数据库中的格式对整个组织保持一致。当然也有例外情况，我假设多个应用程序读取和写入共享数据库。