jam*_*one 10 sql-server flat-file
我的公司的高层朋友告诉好朋友,平面文件是可行的方法,我们应该从SQL Server切换到他们所做的一切.我们有超过300台服务器和数百个不同的数据库.从我参与的少数几个中我们有相当多的记录,每天有超过10万条记录,并且知道有多少更新...我和其他几个人需要提出回复说为什么我们不应该这样做.我们的大多数东西都是带有一些传统ASP的ASP.NET.我们认为制作一个简单的控制台应用程序可以测试/计算平面文件(存储在网络上)和网络上的SQL之间的相同交互,这些交互执行大型插入,搜索,更新等以及网络等随机断开的连接.这会告诉他们平面文件有多糟糕,
我应该在回复中使用哪些内容？我应该如何使用我的演示代码来说明这一点？
到目前为止我的排序列表:
我担心,如果我现在无法阻止它,那么有一天这将成为每日WTF上的一篇伟大帖子.
另外
有谁知道有关HIPPA的任何内容都可以用于这场斗争吗？我们的许多记录都是患者记录......
Tho*_*mas 13
数据的完整性.首先,您可以在数据库中强制执行它,而不能在平面文件中强制执行.其次,您可以确保在不同实体之间具有参照完整性以防止孤立行.
存储效率取决于数据的性质.如果数据自然地分解为实体,那么从平面文件的情况下需要编写的附加代码的角度来看,数据库将比许多平面文件更有效,以便加入数据.
本机查询功能.您可以本机查询数据库,而不能使用平面文件.使用平面文件,您必须将文件加载到其他一些环境(例如C#应用程序)中,并使用其功能对其进行查询.
格式完整性.数据库格式更加严格,这意味着更加一致.平面文件很容易改变,因为读取平面文件的代码会中断.差异与#3有关.在数据库中,如果架构发生更改,您仍然可以使用本机工具对其进行查询.如果平面文件格式发生变化,则必须有效地进行搜索,因为读取它的代码可能会被破坏.
"通用"语言.SQL在某种程度上无处不在,因为平面文件的结构更具有可塑性.
我还提到数据损坏.大多数现代SQL数据库都可能在服务器上被杀死,或者服务器实例崩溃,您不会(不应该)丢失数据.平面文件实际上并非如此.
我也提到了搜索时间.甚至可能用1mil条目编写一个简单的平面文件数据库,并显示与MS SQL相比的搜索时间.使用索引,您应该能够以数千倍的速度搜索SQL数据库.
我还要小心你多快写下平面文件.我甚至说"对很多情况来说这是一个好主意,但在我们的情况下......".这样你就不会听起来像是在听别人的意见.在这种情况下的策略是一个需要考虑的重点.他们可能是非常错误的,但你必须说服你的老板.
小智 5
他们从使用平面文件中获得了什么？转换过程将是数百小时 - 他们支付的小时数.平面文件能够以多快的速度为该投资带来正回报？提供粗略的成本估算.将技术考虑因素转化为金钱(成本),并将问题放在他们的角度.
除了数据转换之外,添加隐藏的成本来复制数据库的功能......
| 归档时间： |
|
| 查看次数： |
822 次 |
| 最近记录： |