10

好朋友告诉我公司的高层，平面文件是要走的路，我们应该为我们所做的一切从 SQL Server 切换到它们。我们有超过 300 台服务器和数百个不同的数据库。从我参与的少数人来看，我们有超过 100 亿条记录，其中不少人每天有超过 10 万条新记录，谁知道有多少更新……我和其他几个人需要做出回应说为什么我们不应该这样做。我们的大部分东西都是带有一些旧版 ASP 的 ASP.NET。我们认为制作一个简单的控制台应用程序来测试/计时平面文件（存储在网络上）和网络上的 SQL 之间的相同交互，执行大型插入、搜索、更新等以及网络随机断开连接之类的事情。这将向他们展示平面文件的糟糕程度，

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

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

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

如果我现在不能阻止它，我担心有一天这将成为 Daily WTF 上的一个很棒的帖子。

此外

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

4

19 回答 19

13

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

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

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

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

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

于 2010-06-11T15:31:50.240 回答
9

我还要提到数据损坏。大多数现代 SQL 数据库可能会导致服务器断电，或者服务器实例崩溃，而您不会（不应该）丢失数据。平面文件并非如此。

另外我会提到搜索时间。甚至可以编写一个包含 100 万个条目的简单平面文件数据库，并显示搜索时间与 MS SQL。使用索引，您应该能够以数千倍的速度搜索 SQL 数据库。

我也会小心你注销平面文件的速度。我什至会说“这在很多情况下都是个好主意，但在我们的情况下......”。这样你就不会听起来像是没有在听其他观点。在这种情况下机智是需要考虑的主要问题。他们可能大错特错，但你必须让你的老板相信这一点。

于 2010-06-11T15:31:02.043 回答
5

他们从使用平面文件中获得了什么？转换过程将是数百小时 - 他们支付的小时数。平面文件多快能从该投资中产生正回报？提供粗略的成本估算。将技术考虑转化为金钱（成本），并将问题放在他们的角度。

除了数据转换之外，还要加上复制数据库功能的隐性成本……

  • 索引
  • 事务处理
  • 日志记录
  • 访问控制
  • 表现
  • 安全
于 2010-06-11T15:51:07.720 回答
4

数据库允许您通过搜索任意数量的不同列轻松地为数据建立索引，以便能够对特定记录或记录组进行索引。

对于平面文件，您必须编写自己的索引机制。当数据库已经为您完成所有这些工作时，无需再次完成所有这些工作。

于 2010-06-11T15:19:40.707 回答
4

如果您使用“文本文件”，则需要在其上构建一个界面，Microsoft 已经为您完成了该界面并将其称为 SQL Server。

询问您的经理是否有必要将所有这些资源用于构建一个自制的数据库系统（因为实际上就是这样），或者将这些资源用于专注于业务是否会更好。

  • 性能：SQL Server 是为存储方便搜索的数据而构建的。它优化了内存中的数据结构，并考虑了搜索/插入/删除。由于定期查询的数据保存在内存中，因此降低了磁盘的使用率。

  • 业务合作伙伴：如果您计划与第 3 方公司进行 B2B，SQL Server 具有内置功能，称为链接服务器。如果您只有一堆文件，您的业务伙伴将放弃您，因为无法进行数据互连。除非您想再次重新发明轮子，并为您拥有的每个业务合作伙伴构建一个界面。

  • 集群：您可以轻松地在 SQL Server 中集群服务器以获得高可用性和速度，这远远超过基于文本的解决方案所能实现的。

于 2010-06-11T15:51:11.747 回答
2

你的清单有一个很好的开始。我要添加的项目包括：

  1. 数据完整性 - SQL 引擎提供内置机制（关系、约束、触发器等），可以非常简单地减少系统中“坏”数据的数量。如果您使用平面文件，则需要单独手动编码所有数据约束。
  2. Add-Hoc 数据检索 - SQL 引擎通过使用 SELECT 语句，提供了一种过滤和汇总数据的方法，只需很少的代码。如果您使用的是平面文件，则需要更多代码才能获得相同的结果。

如果您想花时间构建数据引擎，可以复制这些项目，但重点是什么？SQL 引擎已经提供了这些好处。

于 2010-06-11T15:30:54.307 回答
2

我想我什至不能开始列出原因。我想我的头要爆炸了。我会冒险尝试帮助你...

  • 模拟网络中断并显示此时其中一个文件发生的情况
  • 演示由于文本文件未通过 ACID 测试而导致半提交事务的恐怖
  • 如果它是一个多用户应用程序，显示当 500 个连接都试图更新同一个文本文件时客户端必须等待多长时间
  • 尝试礼貌地解释为什么做出业务决策的最佳方法是听从你花钱的专业人士和了解领域（在本例中为 IT）的专业人士的意见，而不是听你的不知道的朋友的意见（可能会忽略最后一点）
  • 提到一个事实，即 99%（虚构的数字）的商业世界使用关系数据库来存储他们的重要数据，而不是文本文件，这可能是有原因的
  • 显示当有人进入文本文件并输入“哈哈！”时，您的应用程序会发生什么情况。对于应该是整数的列
于 2010-06-11T15:33:50.563 回答
2

您的列表是坚持使用数据库的一个很好的开始。

但是，我建议如果您正在与技术人员交谈，请在推荐中回避技术原因，因为它们可能会让人觉得有偏见。

以下是我反对平面文件数据存储的 2 点：

1) 安全性 - HIPPA 审核要求患者数据保持在安全的环境中。通用数据库系统（Oracle、Microsoft SQL、MySQL）具有实现符合 HIPPA 的安全访问的方法。充其量在平面文件上这样做是很困难的。

旁注：我还看到医疗实践对数据库中的患者姓名进行加密，以增加额外的保护和合规层，以确保即使他们的数据库受到损害，患者记录也不存在风险。

2) 报告——来自任何结构化数据库系统的报告都是简单而常见的。有成千上万的开发人员可以执行此任务。从平面文件报告将需要高于平均水平的开发人员。而且，由于没有普遍接受的从平面文件数据库报告的方法，一个开发人员可能会做与另一个不同的事情。这可能会影响能够在本土平面文件系统上工作的人才库，并最终因必须支持这种类型的系统而推高成本。

我希望这会有所帮助。

于 2010-06-11T16:57:56.597 回答
2

如果您是一家上市公司，股东会很高兴知道这是正在认真考虑的。“我们”都知道，鉴于您的业务规模和范围，这是一个荒谬的建议。 患者记录必须受到保护，不仅免受安全漏洞的影响，而且免受 不负责任的损失风险 ——生命可能取决于数据。如果高管们关心病人，这应该是他们最关心的问题。

从 74 年开始，我一直在使用 IBM 370 大型机，在 DB2 取代普通的旧平面文件、VSAM 和 ISAM 的那一天是具有里程碑意义的一天。在我使用 4 种风格的 RDBMS 的 25 年中，除了流数据之外，还没有回头看平面文件存储。

如果我持有“你”的股票，在项目启动的那一刻匆忙抛售似乎是合适的......

于 2010-06-11T18:08:40.987 回答
1

如何使用纯文本文件创建关系模型？

或者您打算为每个实体使用不同的文件？

于 2010-06-11T15:17:00.927 回答
1

专业文件系统：

  1. 稳定（更少的代码行=更少的错误，更容易理解，更可靠）
  2. 使用庞大的数据块更快
  3. 搜索/排序有点慢（但sort 可以比 SQL 更快order by）

例如，您选择了一个文件系统来创建日志文件。除非您需要对数据进行复杂的分析，否则登录数据库是没有用的。

专业数据库：

  1. 事务（包括并发访问）
  2. 它可以搜索大量记录（但不能搜索大量数据）
  3. 使用查询以各种方式切割数据很容易（好吧，如果你知道你的 SQL 和你的数据库的特殊“奇怪”）

因此，如果您需要很少添加数据但经常搜索它，通过某些标准或聚合值选择部分数据，那么数据库适合您。

于 2010-06-11T15:24:02.347 回答
1

NTFS 不能很好地支持大量的 .txt 文件。根据平面文件系统的开发方式，硬盘驱动器的运行状况可能会成为一个问题。许多较旧的文件系统使用大量的小型 .txt 文件来存储数据。这是一个糟糕的设计，但往往会随着平面文件系统变老而发生。

碎片成为一个问题，您会在这里和那里丢失一个文本文件，从而导致您丢失少量数据。就数据库设计而言，硬盘驱动器的健康状况不应成为问题。

于 2010-06-11T15:26:46.340 回答
1

对于您的雇主而言，这确实是一个主要的 WTF，如果他认真地提议所有内容的平面文件......

您已经知道原因（哦 - 将复制/负载平衡添加到您的列表中） - 您现在需要做的是让他相信它们。我在这方面的方法有两个方面。

首先，我会在您当前使用的任何工具中编写一个脚本，以使用 SQL 执行基本操作，并对其进行计时。然后，我将编写另一个脚本，您真诚地尝试在其中尝试使纯文本解决方案正常工作，然后突出显示性能上的差异。给他两套代码，这样他就知道你没有作弊。

指出技术在发展，仅仅因为某人在 20 年前取得了成功，这并不能自动赋予他们现在可信的意见。

您可能还想提及在文本文件中解码/编码信息的错误范围，有人窃取它们是微不足道的，以及调整当前代码库以使用文本文件的成本（证明您的估计是合理的）。

然后我会问一些严肃的管理问题——其中最重要的，我会直接问这个问题，是“你为什么准备在技术问题上推翻你的技术人员”，基于另一个人的意见——尤其是当那个人不那么熟悉的时候随着我们的设置，我们......

然后我也会使用这句话“我并不是要贬低你，但我真的觉得为了公司的利益我必须在这一点上进行干预......”

另一种方法——扭转局面——让 Wonderful 先生提供关于为什么文本文件是前进方向的论据。然后，您将要么 a) 学到一些东西（不太可能），要么 b) 能够彻底摧毁他的论点。

祝你好运 - 我感觉到你的痛苦......

马丁

于 2010-06-11T15:43:18.517 回答
1

我建议你先进行报复，现在就在 Daily WTF 上发帖。

至于你的问题：一个商业原因是你的老板为什么要重写你所有的系统。实际上，您必须从头开始编写自己的数据库系统。

出于开发原因，您将无法访问 SQL Server 生态系统、所有库、工具和实用程序。

也许提出这个建议的人实际上是在考虑与您的公司竞争。

于 2010-06-11T15:58:05.607 回答
1

反驳这一论点的最简单方法 - 命名一家使用平面文件处理这种规模数据的财富 500 强公司？

现在命名一家不使用关系数据库的财富 500 强公司...

结案。

于 2010-06-11T16:16:14.313 回答
0

这里的东西真的很可疑。对于正确使用术语（“平面文件”）但不知道一个想法是多么愚蠢的人来说，它只是没有加起来。我愿意成为你的经理是非技术人员，但你的经理正在与之交谈的人是。这听起来更像是一个迷失的翻译问题。

您确定它们并不意味着没有 SQL，就好像您处于以文档为中心的环境中一样，在某些方面远离关系数据库确实是有意义的，同时仍然具有传统 RDBMS 的许多优点。

因此，与其解释为什么 SQL 比平面文件更好，我倒转问题并询问平面文件要解决的问题是什么。我认为这是一个沟通问题。

如果不是这样，并且您的公司实际上正在考虑用“朋友”的建议用自制的平面文件系统替换其数据库，那么说服您的经理为什么他错了是您最不担心的事情。相反，除尘并开始传播您的简历。

于 2010-06-11T19:17:36.250 回答
0

• 进行如此大规模的重写/切换所需的时间和巨额的美元成本

这不仅仅是引入新错误的时间。重写这些比例会导致当前工作的东西被破坏。

我建议给他一个成本估算，估算只为一个系统进行这种重写的时间，然后是需要更改的系统数量。一旦他们有了成本估算，他们就会尽可能快地运行。

经理喜欢数字，所以要进行正式的书面决策分析。将这两个提案按收益和风险并列与数值进行比较。当您花费 0 维护成本和 100,000,000 转换成本时，他们就会明白这一点。

于 2010-06-11T19:23:07.723 回答
0

不区分平面文件和sql的人，不理解你之前说的所有论点。

解释必须尽可能简单，如下所示：
SQL 是围绕平面文件的某种搜索/并发包装器。
当前存在的所有问题，即使公司要从零开始编写包装器，也将继续存在。

此外，您必须提供一些其他方法来解决当前问题，使用高级 BLL 等智能词或安装/卸载脚本环境。:)

于 2010-06-13T12:39:58.850 回答
0

你必须说行政。不用说，让他们意识到他们在这里太过分了。这是一些弹药：

数据库理论是核心计算机科学。我们正在谈论构建一个可扩展的系统，该系统可以处理数百万条记录并容忍灾难，而不会让每个人都破产。

这是博士级专家的工作。20 年来，他们一直在完善该领域，而最棒的地方在于：它使我们能够专注于构建业务系统。

If you have to, come right out and say that this just isn't done in the enterprise. It would be costly and the result would be inferior. It's exactly the kind of wheel that developers love to reinvent, and in my opinion the only time you should is if the result is going to be a product or service that you can sell. And it won't be.

于 2010-06-13T12:58:54.110 回答