用什么参数来解释为什么SQL Server比平面文件要好得多

时间:2010-06-11 15:15:43

标签: sql-server flat-file

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

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

到目前为止我的排序清单:

  • 安全
  • 并发访问
  • 大量数据的表现
  • 进行如此大规模的重写/切换和巨额费用的时间
  • 缺乏交易
  • PITA将关系数据映射到平面文件
  • NTFS不支持目录中的大量文件
  • 缺乏临时数据搜索/操作
  • 实施数据完整性
  • 从网络中断中恢复
  • 等待其他客户端更改为提交时的客户端延迟
  • 很久以前,大多数人都停止使用平面文件进行此类存储
  • 负载平衡/复制

我担心,如果我现在无法阻止它,那么有一天这将成为每日WTF的一篇伟大帖子。

另外

有没有人知道在这场战斗中是否可以使用HIPPA?我们的许多记录都是患者记录......

19 个答案:

答案 0 :(得分:13)

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

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

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

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

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

答案 1 :(得分:9)

我还提到数据损坏。大多数现代SQL数据库都可能在服务器上被杀死,或者服务器实例崩溃,您不会(不应该)丢失数据。平面文件实际上并非如此。

我也提到了搜索时间。甚至可能用1mil条目编写一个简单的平面文件数据库,并显示与MS SQL相比的搜索时间。使用索引,您应该能够以数千倍的速度搜索SQL数据库。

我还要小心你多快写下平面文件。我甚至说“对很多情况来说这是一个好主意,但在我们的情况下......”。这样你就不会听起来像是在听别人的意见。在这种情况下的策略是一个需要考虑的重点。他们可能是非常错误的,但你必须说服你的老板。

答案 2 :(得分:5)

使用平面文件可以获得什么?转换过程将是数百小时 - 他们支付的小时数。平面文件能够以多快的速度为该投资带来正回报?提供粗略的成本估算。将技术考虑转化为金钱(成本),并将问题放在他们的角度。

除了数据转换之外,还要添加隐藏的成本来复制数据库的功能......

  • 索引
  • 交易处理
  • 登录
  • 访问控制
  • 性能
  • 安全

答案 3 :(得分:4)

数据库允许您通过搜索任意数量的不同列轻松地将数据编入索引,以便能够记录特定记录或记录组。

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

答案 4 :(得分:4)

如果你使用“文本文件”,你需要在它上面构建一个微软已经为你做过的接口,并称之为SQL Server。

向您的经理询问您的公司是否有必要花费所有这些资源来构建自制的数据库系统(因为它实际上就是这样),或者将这些资源更好地用于关注业务。

  • 性能:SQL Server用于存储方便的可搜索数据。它在内存中优化了数据结构,内置了搜索/插入/删除功能。由于定期查询的数据保留在内存中,因此磁盘的使用率会降低。

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

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

答案 5 :(得分:2)

您的列表开始不错。我要添加的项目包括:

  1. 数据完整性 - SQL引擎提供内置机制(关系,约束,触发器等),可以非常简单地减少系统中“坏”数据的数量。如果使用平面文件,则需要单独手动编写所有数据约束。
  2. Add-Hoc数据检索 - SQL引擎通过使用SELECT语句,提供了一种用很少的代码过滤和汇总数据的方法。如果您使用的是平面文件,则需要更多代码才能获得相同的结果。
  3. 如果您想花时间构建数据引擎,可以复制这些项目,但重点是什么? SQL引擎已经提供了这些好处。

答案 6 :(得分:2)

我认为我甚至无法列出原因。我想我的脑袋会爆炸。我会冒险尝试帮助你...

  • 模拟网络中断并显示当时其中一个文件发生的情况
  • 演示半承诺事务的恐怖,因为文本文件未通过ACID测试
  • 如果是多用户应用程序,请显示当500个连接都试图更新同一文本文件时客户端必须等待多长时间
  • 试着礼貌地解释为什么做出商业决策的最佳方法是倾听你付钱的专业人士和知道域名的人(在这种情况下是IT)而不是你的伙伴谁没有线索(也许遗漏了最后一点)
  • 提到这样一个事实:99%(编号)的商业世界使用关系数据库来处理他们的重要数据,而不是文本文件,这可能是其原因
  • 当有人进入文本文件并输入“haha!”时,显示应用程序会发生什么。对于一个应该是整数的列

答案 7 :(得分:2)

您的列表是坚持使用数据库的良好开端。

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

以下是针对平面文件数据存储的2点:

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

旁注:我还看到了医疗实践,它加密了数据库中的患者姓名,以增加额外的保护层次。遵守以确保即使他们的数据库受到损害,患者记录也没有风险。

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

我希望有所帮助。

答案 8 :(得分:2)

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

我从74年开始使用IBM 370大型机,而DB2从普通的旧平面文件接管的那天,VSAM和ISAM是一个里程碑式的日子。在我使用4种风格的RDBMS的25年中,除了流数据之外,还没有回头看平面文件存储。

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

答案 9 :(得分:1)

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

碎片成为一个问题,你在这里和那里丢失了一个文本文件,导致你丢失少量数据。在数据库设计方面,硬盘的健康状况不应成为问题。

答案 10 :(得分:1)

对于你的雇主而言,如果他真的为所有事情提出平面文件,那确实是一个主要的WTF ......

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

首先,我会在您当前用于使用SQL执行基本操作的任何工具中编写脚本,并将其定时。然后我会编写另一个脚本,您真诚地尝试使用平面文本解决方案,然后突出性能差异。给他两套代码,这样他就知道你不是在作弊。

指出技术在不断发展,而且仅仅因为某人在20年前取得了成功,这并不能让他们现在获得可信的意见。

您可能还想提及在文本文件中解码/编码信息时出现错误的范围,对于某人窃取它们来说是微不足道的,以及在调整当前代码库以使用文本时的成本(证明您的估计是合理的)文件。

然后我会提出严肃的管理问题 - 其中最重要的是,我会直接问这个问题,“你为什么准备根据另一个人的意见推翻技术人员的技术问题” - 特别是当说这个人是不像我们那样熟悉我们的设置......

然后我也会用“我不是故意贬低你,但我认真地觉得我必须为了公司的利益而干预这一点......”

另一种方法 - 转换表格 - 让Mr. Wonderful提供关于为什么文本文件是前进的供应论据。然后你要么a)学习一些东西(不太可能),或者b)能够完全摧毁他的论点。

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

马丁

答案 11 :(得分:1)

专业文件系统:

  1. 稳定(减少代码行数=减少错误,更容易理解,更可靠)
  2. 使用大量数据blob更快
  3. 搜索/排序有点慢(但sort 可以比SQL order by更快
  4. 因此,您选择了一个文件系统来创建日志文件。除非您需要对数据进行复杂的分析,否则登录数据库是没用的。

    Pro DB:

    1. 交易(包括并发访问)
    2. 它可以通过大量记录搜索(但不能通过大量数据)
    3. 使用查询以各种方式删除数据很容易(好吧,如果你知道你的SQL和数据库的特殊“奇怪之处”)
    4. 因此,如果您需要很少添加数据但经常搜索数据,请按特定条件或聚合值选择部分数据,数据库适合您。

答案 12 :(得分:1)

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

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

答案 13 :(得分:1)

我建议你现在首先在Daily WTF上发布你的报告。

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

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

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

答案 14 :(得分:1)

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

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

案件结案。

答案 15 :(得分:0)

这里真的很腥。对于某些人来说,术语是正确的(“平面文件”),但不知道这个想法有多么愚蠢,它只是没有加起来。我愿意成为你的经理是非技术性的,但你的经理正在谈论的是。这听起来更像是翻译问题。

你确定它们并不意味着没有SQL,就像你处于以文档为中心的环境一样,离开关系数据库实际上在某些方面确实有意义,同时仍然具有传统RDBMS的许多积极因素

因此,我没有证明为什么SQL比平面文件更好,我会反驳问题并询问平面文件要解决的问题。我想赔钱这是一个沟通问题。

如果不是,贵公司实际上正在考虑用“朋友”的建议替换其本土平面文件系统的数据库,说服你的经理为什么他错了是你最不担心的。相反,尘埃落下并开始传播你的简历。

答案 16 :(得分:0)

  

•做这么大规模的时间   重写/切换和巨额费用

引入新错误不仅仅是时间量。重写这些比例会导致当前工作中断的事情。

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

管理人员喜欢数字,所以做正式的书面决策分析。比较两个提案的好处和风险,并与数值并排。当你花费0来维持和100,000,000转换时,他们就会明白这一点。

答案 17 :(得分:0)

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


解释必须尽可能简单,如下:
SQL是平面文件的某种搜索/并发包装器 目前存在的所有问题,甚至会让公司从零开始写包装。

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

答案 18 :(得分:0)

你必须说执行。不说,让他们意识到他们在这里已经超越了他们的头脑。这是一些弹药:

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

这是博士级专家的工作。他们现在已经在这个领域进行了20年的精炼,最重要的是:它使我们能够专注于构建业务系统。

如果必须,请直接说出这一点并非在企业中完成。这将是昂贵的,结果将是低劣的。这正是开发人员喜欢重新发明的那种轮子,而且在我看来,应该的唯一时间是结果是你可以销售的产品或服务。它不会。