用什么论据来解释为什么 SQL Server 比平面文件好得多答案

【问题标题】：What arguments to use to explain why SQL Server is far better than a flat file用什么论据来解释为什么 SQL Server 比平面文件好得多
【发布时间】：2011-03-02 17:25:31
【问题描述】：

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

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

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

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

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

另外

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

【问题讨论】：

你确定他们不是在提倡 No-SQL 方法吗？这是当今的热门话题。如果他们提倡 NoSQL，您可能会想以不同的方式解决这个问题。
@jamone：滚出去！说真的 - 如果那些“高层”有其他“朋友”告诉他们知道什么......
是的，我得出了这个结论，而不仅仅是基于此。我要看看能不能再坚持几个月，以便更好地安排。
遗憾的是，这个确切的论点已经向我提出过一次，并在 thedailywtf.com：thedailywtf.com/Articles/…
也许你会争辩说 MySQL 是分层在平面文件系统之上的中间件，以提供更高的效率并使 99% 的程序员更容易编程，不像老板的朋友那样“熟练”：- )

标签： sql-server flat-file

【解决方案1】：

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

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

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

如果您必须这样做，请直接站出来说这只是在企业中没有完成。这将是昂贵的，结果会很差。这正是开发人员喜欢重新发明的那种轮子，在我看来，您唯一应该是如果结果将是您可以销售的产品或服务。而且不会。

【讨论】：

【解决方案2】：

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

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

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

【讨论】：

【解决方案3】：

•完成如此大规模的任务所需的时间重写/切换和巨额成本

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

我建议给他一个成本估算，估算仅针对一个系统进行此类重写所需的时间，然后估算需要更改的系统数量。一旦他们有了成本估算，他们就会尽快完成。

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

【讨论】：

【解决方案4】：

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

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

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

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

【讨论】：

我希望这是一个通信错误。这位“朋友”简要解释了几年前他是如何做事的，现在他非常富有，所以它奏效了。使用数千个文本文件存储数据与使用“臃肿且昂贵的数据库软件”非常清楚......他们也希望我们从现在开始使用 Power Basic。我们所做的 90% 以上是基于 Intranet 的 Web 应用程序，因此除非我们切换到所有基于客户端的应用程序，否则无法使用 power basic。
哇，太可怕了。你应该把这个帖子发给他们。并开始寻找另一份工作。 :)

【解决方案5】：

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

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

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

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

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

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

希望对你有帮助。

【讨论】：

【解决方案6】：

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

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

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

【讨论】：

它是私有的。否则我会去董事会，我希望他们会比只有 1 个所有者更容易说服。
即使是私有企业 - 如果这以任何方式对客户造成损害，公司可能/将要对严重和故意疏忽负责。

【解决方案7】：

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

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

结案。

【讨论】：

嗯...谷歌？ Google BigTable 不是关系数据库。当然，它也不完全是一个平面文件。而且 Google 也不一定是一个可以效仿的好例子——很少很少有公司使用足够的数据量来证明按照 Google 的方式做事是合理的。
是的，我知道 Google 会这样做，但鉴于他们编写了自己的操作系统和文件系统，以使一切都按照现在的方式运行，我觉得这很容易解释为什么他们可以/做到了我们不能/不应该

【解决方案8】：

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

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

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

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

【讨论】：

【解决方案9】：

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

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

性能：SQL Server 专为方便地存储可搜索数据而构建。它优化了内存中的数据结构，并考虑了搜索/插入/删除。由于定期查询的数据保存在内存中，因此降低了磁盘的使用率。
业务合作伙伴：如果您计划与第 3 方公司进行 B2B，SQL Server 为其内置了称为链接服务器的功能。如果您只有一堆文件，您的业务伙伴将放弃您，因为无法进行数据互连。除非您想重新发明轮子，并为您拥有的每个业务合作伙伴构建一个界面。
集群：您可以轻松地在 SQL Server 中集群服务器以获得高可用性和速度，远远超过基于文本的解决方案所能提供的能力。

【讨论】：

【解决方案10】：

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

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

索引
事务处理
日志记录
访问控制
性能
安全性

【讨论】：

如果他们有数百个数据库，我可以建议一个比仅仅“数百小时”更大的数字吗？
年，而且更有可能。
好点！使用实际美元价值呈现所有隐藏成本肯定有助于让上级倾听。

【解决方案11】：

对于你的雇主来说，这确实是一个主要的 WTF，如果他认真地为所有事情提出平面文件......

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

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

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

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

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

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

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

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

马丁

【讨论】：

我很想扭转局面，但据我所知，几个月前他已经说服了高层。但 IT 才刚刚开始发现。我认为现在由我们来反击......
提出一个可信的理由反对它，并得到公司中真正能拼写“IT”的每个人的普遍支持，如果你仍然被否决，请辞职。如果没有腰带式武器和有人告诉我管理套件在哪里，我认为我无法在您的环境中工作......
考虑性能试验。我们都知道，性能并不是其中最重要的方面（想想 ACID），但它很容易证明，并且不应该超出管理人员的智慧......
@jamone：我认为他在他的后壁橱里有一项竞争业务，并且正在寻找一种方法来通过在这家公司的轮子上插一根棍子来赚更多的钱...... :)

【解决方案12】：

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

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

【讨论】：

【解决方案13】：

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

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

【讨论】：

因为一些多年没有发展的百万富翁告诉我们的老板这是我们必须做的......

【解决方案14】：

数据完整性。首先，您可以在数据库中强制执行它，而不能在平面文件中强制执行。其次，您可以确保在不同实体之间具有参照完整性，以防止出现孤立行。
存储效率取决于数据的性质。如果数据自然地分解为实体，那么从平面文件的情况下需要编写额外代码以连接数据的角度来看，数据库将比大量平面文件更有效。
本机查询功能。您可以本机查询数据库，而不能使用平面文件。对于平面文件，您必须将文件加载到其他环境（例如 C# 应用程序）并使用其功能对其进行查询。
格式完整性。数据库格式更严格，这意味着更一致。平面文件可以很容易地以读取平面文件的代码中断的方式进行更改。差异与＃3有关。在数据库中，如果架构发生变化，您仍然可以使用本机工具对其进行查询。如果平面文件格式发生变化，您必须有效地进行搜索，因为读取它的代码可能会被破坏。
“通用”语言。 SQL 在某种程度上无处不在，因为平面文件的结构更具延展性。

【讨论】：

【解决方案15】：

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

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

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

【讨论】：

机智上的好点。我一定要指出我们确实一直在使用平面文件。错误记录等。它们确实有其用途。
+1 表示“机智”。不管你如何发展你的论点——要委婉一点，否则它几乎会立即被注销（你也跟着）。

【解决方案16】：

您的列表有一个很好的开始。我要添加的项目包括：

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

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

【讨论】：

【解决方案17】：

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

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

【讨论】：

【解决方案18】：

专业文件系统：

稳定（代码行数更少 = 错误更少，更容易理解，更可靠）
处理大量数据块时速度更快
搜索/排序有点慢（但sort 可以比 SQL 的 order by 快）

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

专业数据库：

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

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

【讨论】：

幸运的是，没有使用 Blob，但在一种情况下，在这种情况下，它的范围如此有限，它不是问题。

【解决方案19】：

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

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

【讨论】：

我真的不知道如何将关系模型映射到文本文件。我从没想过会发生这样的事情。
这是一个反问。你不能:)但我认为这将是你的主要问题，如果你关心你的数据的健全性。甚至在交易之前。
当然你“可以”。文本文件可以代表任何东西。在最基本的级别，每个表一个文件。不过，我从来没有想过这样做……如果我没记错的话，Interbase/Firebird 具有定义所有内容的系统表，包括系统表（一种鸡/蛋问题）。我不确定其他数据库。