存储过程和交换DB技术在哪里？

Question

这绝对是疯了..。

我刚刚开始做一个新的项目，我对我刚才所看到的感到震惊。这个项目是一个位于之上的C# web应用程序。现在所有的存储过程都不是真正的存储过程..。它们只是存储在服务器目录中文本文件中的SQL脚本。当应用程序启动时，它将在目录中查找，并遍历每个文件，读取文本并将其保存在字典中。它还在文本上运行Regex，删除诸如PARAM这样的特殊序列，并将它们替换为正确的符号，例如Oracles大小写中的“：”或SQL SERVER的“@”。然后，当代码想要执行这些语句之一时，它调用一个方法，该方法在字典中找到正确的方法并运行它。

现在看来，这样做是为了防止他们想要交换底层db技术。他们说他们只会用适当的语法将sql文件从目录中交换到文件中，这样就可以了。

现在，我通常希望存储过程实际上是存储过程，并在db上运行。与数据库对话的单独项目(层)。然后，如果db技术发生变化，只需添加另一个数据层项目并交换dlls .

我认为目前的做法存在着巨大的问题：

• 正在创建的db服务器上没有执行计划。
• 大量开销读取数百个文本文件，为每个文本文件构建一个字符串，并在其上运行regex。
• 不检查SQL语法。
• 内存中有所有这些存储过程的大内存脚印

你们都怎么想？

这是真的很糟糕，还是我只是呻吟，因为我从来没有见过这样的事情？

这种方法还有什么问题呢？

任何评论都会非常感谢，因为我试图让同事们明白这是疯狂的.

Answer 1

你们都怎么想？

我认为这是一个典型的过度工程案例:谁改变了他们的DB提供程序？真的是带来了什么吗？

这是真的很糟糕，还是我只是呻吟，因为我从来没有见过这样的事情？

在我看来，这两者都有一点:这很糟糕，但如果他们已经像这样跑了一段时间，那肯定是可行的。

这种方法还有什么问题呢？

实际上，每次重新计算执行计划可能是最大的问题：

太多的性能损失了！我的意思是，可能是因为性能并不总是一个要求(过度优化并不是更好的;)

真正错误的是他们重新发明了轮子: LINQ是天生的。

这意味着随着LINQ的不断改进，公司将逐渐落后，因为他们不会从这些改进中获益。

如果你有任何杠杆力量，试着和他们谈谈LINQ。

Answer 2

为什么不在构建时使用脚本以本机语法(PSQL，then )创建存储过程脚本，然后将其部署到数据库中？我看不出会有太多的工作要做，而且您可以从编译后的存储过程代码中获得所有的好处等等。

我有自己的经验，运行时编译存储过程( Server)是一个很大的性能开销，而在一个生产系统上，这是一个真正的问题。

我可以看出这个设计背后的理由：

• 存储过程代码过于特定于数据库，因此我们将不使用存储过程，而是使用SQL语句。
• 即使SQL语句也可以在其中包含特定于数据库的语法，因此我们将有一些在运行时动态转换它们的hokey方法。

即使您不使用存储过程，我仍然认为转换应该在构建时进行(例如，生成C#代码)，而不是运行时。