用什么论据来解释为什么SQLServer比平面文件好得多

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

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

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

5. “通用”语言。在平面文件的结构更具可塑性的地方,SQL有点无处不在。

我还要提到数据损坏。大多数现代的SQL数据库可能会在服务器上断电,或者服务器实例崩溃,而您不会(不应该)丢失数据。平面文件不是这样的。

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

在数据转换的基础上,再加上复制数据库功能的隐藏成本。。。

• 索引
• 登录中
• 性能

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

对于平面文件,您必须编写自己的索引机制。当数据库已经为您做了这些工作时,就不需要再做这些工作了。

如果你使用“文本文件”,你需要在上面建立一个微软已经为你做过的叫做sqlserver的界面。

问问你的经理,把所有这些资源花在建立一个自制的数据库系统上是否对你的公司有意义(因为事实就是这样),或者把这些资源花在业务上是否更好。

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

• 集群:您可以轻松地在SQLServer中对服务器进行集群,以获得高可用性和高速度,这比使用基于文本的解决方案所能实现的要多得多。

你的单子开头不错。我要补充的项目包括:

1. 数据完整性—SQL引擎提供了内置机制(关系、约束、触发器等),使减少系统中“坏”数据的数量变得非常简单。如果使用平面文件,则需要分别手工编写所有数据约束。
2. 添加Hoc数据检索-通过使用SELECT语句,SQL引擎提供了一种用很少的代码过滤和汇总数据的方法。如果您使用的是平面文件,则需要相当多的代码才能获得相同的结果。

如果您想花时间构建一个数据引擎,那么可以复制这些项,但有什么意义呢?SQL引擎已经提供了这些好处。

我想我甚至不能列出原因。我想我的头要爆炸了。我愿意冒这个险来帮助你。。。

• 模拟网络中断,并显示其中一个文件在该点上发生了什么
• 如果是多用户应用程序,请显示当500个连接都试图更新同一文本文件时,客户端需要等待多长时间
• 试着礼貌地解释为什么做商业决策的最佳方法是倾听那些你付钱的专业人士,他们知道这个领域(在本例中,是IT),而不是你的朋友,他们一点线索都没有(也许可以省略最后一点)
• 提到99%的商业世界使用关系数据库作为重要数据,而不是文本文件,这可能是有原因的
• 显示当有人进入文本文件并键入“哈哈!”时,应用程序会发生什么对于一个应该是整数的列

不负责任的损失敞口 -生命可能取决于数据 . 如果高管们关心病人,这应该是他们最关心的。

从1974年起,我就开始使用ibm370大型机,DB2从普通的老平面文件、VSAM和ISAM接管的那一天是里程碑式的一天。在我使用4种风格的RDBMS的25年中,我没有回顾过平面文件存储,除了流式数据。

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

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

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

1) 安全性-HIPA审核要求患者数据保持在安全的环境中。常见的数据库系统(Oracle、microsoftsql、MySQL)都有实现HIPPA兼容的安全访问的方法。在平面文件上这样做最多也很困难。

旁注:我还见过一些医疗实践,它们在数据库中加密患者姓名,以添加额外的保护层;合规性,以确保即使他们的数据库受损,患者记录也不会有风险。

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

我希望这有帮助。

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

或者您是否计划为每个实体使用不同的文件?

Pro文件系统:

1. 稳定(更少的代码行=更少的错误,更容易理解,更可靠)
3. 搜索/排序有点慢(但是 sort 可以 order by

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

专业数据库:

2. 事务(包括并发访问)
3. 它可以 搜索 通过大量的记录(但不是通过大量的数据)
4. 使用查询以各种方式分割数据是很容易的(如果您了解SQL和DB的特殊“奇怪之处”)

因此,如果您很少需要添加数据,但需要经常搜索数据,请根据特定条件或聚合值选择数据的一部分,DB就是您的选择。

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

你已经知道原因了(哦-把复制/负载平衡添加到你的列表中)-你现在需要做的是说服他。我在这个问题上的态度是双重的。

首先,我将使用您当前使用的任何工具编写一个脚本,以使用SQL执行基本操作,并对其进行计时。然后我会写另一个脚本,在这个脚本中,您真诚地尝试让一个平面文本解决方案工作,然后强调性能上的差异。把两套密码都给他,让他知道你没有作弊。

指出技术是不断发展的,仅仅因为某人在20年前取得了成功,这并不能自动使他们有资格获得可信的意见。

您可能还想提到在文本文件中解码/编码信息时出现错误的范围,有人窃取这些信息是微不足道的,以及调整当前代码库以使用文本文件的成本(证明您的估计是正确的)。

然后,我会问一些严肃的管理问题——其中最重要的是,我会直接问这个问题,就是“为什么你准备在技术问题上否决你的技术人员”基于另一个人的意见——特别是当所说的个人对我们的设置不像我们那么熟悉的时候。。。

我也会用“我不是有意贬低你,但我真的觉得为了公司的利益,我必须在这一点上进行干预……”

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

我建议你先报仇,现在就发到每日WTF上。

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

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

驳斥这一论点的最简单方法——举出一家财富500强公司的名字,它使用平面文件处理如此规模的数据?

现在举出一家财富500强公司,它不使用关系数据库。。。

结案。

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

因此,我不想解释为什么SQL比平面文件好,而是想反问一下平面文件要解决什么问题。我敢打赌这是个沟通问题。

如果不是这样,而且你的公司真的在考虑根据“一个朋友”的建议,用一个自己开发的平面文件系统替换数据库,那么说服你的经理他为什么错了是你最不担心的。相反,掸去灰尘,开始传阅你的简历。

重写/切换和巨大的成本

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

目前存在的所有问题,即使公司打算从零开始编写包装器,也将继续存在。

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

中坚分子 计算机科学。我们讨论的是构建一个可扩展的系统,它可以处理数百万条记录,并且能够承受灾难,而不会让每个人都破产。

如果有必要的话,直接出来说这不是在企业里做的。这将是昂贵的,结果将是低劣的。这正是开发人员喜欢重新发明的轮子,在我看来 应该 如果结果是你可以销售的产品或服务。不会的。