文件存储的局限性

初看起来，将数据存储在电脑的单个文件或共享驱动器中似乎很简单。然而，当数据量增长或需要多人访问时，这种方式很快就会遇到明显问题。设想一下，如果只用电子表格或文本文件来管理客户信息、产品库存或销售记录会怎样。我们来分析一下使用简单文件存储时常遇到的问题。

数据冗余

数据冗余是常见问题之一。这意味着同一条信息不必要地在多个文件中重复。设想一家小公司存储客户信息，客户的姓名和地址可能出现在：

• 一个列出所有客户的文件（customers.csv）。
• 一个记录销售订单的文件（orders_2024_q1.xlsx）。
• 一个单独的营销邮件列表文件（mailing_list.txt）。

将同一个地址存储在三个不同的地方是冗余的。这会占用额外的存储空间，但更重要的是，它会导致其他问题。

数据不一致性

冗余常常导致数据不一致。如果客户搬家并更新了地址，有人必须记住在所有三个文件（customers.csv、orders_2024_q1.xlsx 和 mailing_list.txt）中都进行更改。如果即使只有一个文件未更新，系统现在就会保存关于同一个客户的冲突信息。哪个地址才是正确的？这种不一致可能导致错误，例如将订单寄到错误地点或将营销材料寄到旧地址。手动确保数据在多个文件之间保持一致既困难又容易出错。

数据访问困难

获取特定信息可能成为一项复杂的工作。假设您需要查找住在某个特定城市的所有客户的订单。使用基于文件的系统，您可能需要：

1. 打开customers.csv文件，找到哪些客户住在那个城市。
2. 打开可能存在的多个orders文件（例如，orders_2024_q1.xlsx、orders_2023_q4.xlsx 等）。
3. 手动交叉核对客户列表与每个文件中的订单信息。

这个过程缓慢、繁琐，并且随着文件数量和数据量的增加而变得不切实际。回答即使是稍微复杂的问题也需要大量的手动工作，或者为每个特定查询编写自定义程序，这非常低效。

数据完整性问题

文件系统通常在执行文件内数据规则方面提供的支持有限。例如：

• 如何确保order_id在所有订单文件中始终是唯一的？
• 如何保证库存文件中的quantity字段始终是正数？
• 如何确保日期以一致的格式输入（MM/DD/YYYY 对 YYYY-MM-DD）？

如果没有强制执行此类完整性约束的机制，数据质量可能因拼写错误、无效输入或不一致的格式而受到影响，从而使数据不可靠。电子表格可能提供一些基本验证，但它通常应用不一致且容易被绕过。

并发访问异常

当多个用户或应用程序需要同时访问和修改数据时，基于文件的系统常常难以应对。设想两名销售人员在同一时间尝试更新库存电子表格中同一产品的数量。

• 丢失更新： 代理A读取数量（例如10），代理B读取数量（10）。代理A卖出2个，写回8。代理B卖出3个，写回7。代理A的更新丢失了，因为代理B的写入覆盖了它。最终数量应该是5，但记录为7。
• 文件锁定： 另一种情况是，操作系统可能会在一名用户打开文件时锁定整个文件，阻止其他任何人进行更改，直到第一个用户关闭文件。这避免了丢失更新，但严重限制了工作效率，因为一次只能有一个人处理该文件。

这些并发问题使得使用简单的文件构建可靠的多用户应用程序变得困难。

安全和访问控制问题

使用单个文件管理谁可以查看或修改特定数据是很困难的。虽然操作系统提供文件级权限（读取、写入、执行），但这些权限通常适用于整个文件。很难授予用户只读取电子表格中某些列（如产品名称和价格）而不能读取其他列（如利润率）的权限，或者允许一组用户更新客户地址，而另一组用户只能查看。管理众多文件的细粒度访问控制会成为一项重大的管理负担。

这些局限性表明，尽管文件系统非常适合存储文档、程序和非结构化数据，但它们不适合高效、一致且可靠地管理结构化信息，尤其是在大规模应用时。这正是数据库系统旨在解决的问题。