
系统(即数据库)管理其数据完整性听起来像是常识,在简单场景中,这确实是常识。然而,当业务规则变得复杂时,在中心位置验证数据就变得更加困难。
当系统(即数据库)无法再强制执行数据的形状时,必须有其他东西来承担这个责任。这种情况何时会发生?
美国的电话号码格式是(区号)(前缀)-(号码),这里有一个例子:(734) 555-3212。为了简单起见,我们将在本文中讨论数据库,但数据存储不一定必须是数据库。
美国的电话号码总是有十位数字(我们忽略国际数字)。电话号码可以有多种格式:
- xxx.xxx.xxxx
- xxx-xxx-xxxx
- (xxx) xxx-xxxx
- (xxx) xxx.xxxx
大多数数据库仅限于数据类型(即数字、字符串、日期等),不支持格式化。许多应用程序选择使用字符串数据类型来存储电话号码。然而,字符串数据类型接受任何字符串。为了确保电话号码有效,我们需要额外的验证层。
在连接到单个数据库的单个应用程序中,数据验证通常在应用程序中执行。
当您的架构增长到两个或更多应用程序共享数据库时,可能会发生两种情况:
1. 每个应用程序都有自己的数据验证:
2. 有一个中央服务,应用程序调用它来验证数据并持久化数据:
在多个地方进行数据验证的风险是验证可能不同步。对一个应用程序有效的格式可能对另一个应用程序无效。在最坏的情况下,错误的格式会抛出错误,或者在极端情况下,使应用程序崩溃。
最好的情况是集中化数据验证,这样存储在数据库中的格式对整个组织都是一致的。当然也有例外情况,我假设多个应用程序读写共享数据库。
作者:Chuck Conway 专注于软件工程和生成式人工智能。在社交媒体上与他联系:X (@chuckconway) 或访问他的 YouTube。