sql-server - 使用什么论据来解释为什么 SQL Server 比平面文件好得多

Question

好 friend 告诉我公司的高层，平面文件是正确的选择，我们所做的一切都应该从 SQL Server 切换到它们。我们拥有 300 多台服务器和数百个不同的数据库。仅从我参与的少数几家公司来看，我们就拥有超过 100 亿条记录，其中不少记录每天超过 10 万条新记录，谁知道有多少更新……我和其他几个人需要做出回应说为什么我们不应该这样做。我们的大部分内容都是 ASP.NET 以及一些遗留的 ASP。我们认为制作一个简单的控制台应用程序来测试/计算平面文件(存储在网络上)和通过网络的 SQL 之间的相同交互，执行大量插入、搜索、更新等以及网络随机断开等操作。这将向他们展示平面文件有多么糟糕，尤其是当您处理数百万条记录时。

我应该在回复中使用哪些内容？我应该如何使用我的演示代码来说明这一点？

到目前为止我的排序列表:

• 安全
• 并发访问
• 处理大量数据时的性能
• 进行如此大规模的重写/切换需要大量的时间和巨大的成本
• 缺乏交易
• PITA 将关系数据映射到平面文件
• NTFS 不能很好地支持目录中的大量文件
• 缺乏临时数据搜索/操作
• 加强数据完整性
• 从网络中断中恢复
• 客户端在等待其他客户端更改提交时出现延迟
• 大多数人很久以前就不再使用平面文件进行此类存储了，这是有充分理由的
• 负载平衡/复制

如果我现在无法阻止的话，我担心有一天这会成为 Daily WTF 上的一篇很棒的帖子。

另外

有谁知道 HIPPA 的任何内容是否可以在这场战斗中使用？我们的许多记录都是患者记录...

Answer 1

1. 数据完整性。首先，您可以在数据库中强制执行它，但不能在平面文件中强制执行。其次，您可以确保不同实体之间具有引用完整性，以防止孤立行。

2. 存储效率取决于数据的性质。如果数据自然地分解为实体，那么从在平面文件的情况下需要编写附加代码来连接数据的角度来看，数据库将比大量平面文件更有效。

3. native 查询功能。您可以 native 查询数据库，但不能使用平面文件。对于平面文件，您必须将文件加载到其他环境(例如 C# 应用程序)并使用其功能对其进行查询。

4. 格式完整性。数据库格式更加严格，这意味着更加一致。平面文件很容易发生更改，从而导致读取平面文件的代码崩溃。差异与#3 有关。在数据库中，如果架构发生更改，您仍然可以使用 native 工具对其进行查询。如果平面文件格式发生变化，您必须有效地进行搜索，因为读取它的代码可能会被破坏。

5. “通用”语言。 SQL 在某种程度上是普遍存在的，因为平面文件的结构更具延展性。