sql - 在哪里放置存储过程和交换数据库技术？

Question

这绝对是疯狂的......

我刚刚开始从事一个新项目，我对我刚刚看到的感到震惊。该项目是一个位于 Oracle 数据库之上的 C# Web 应用程序。现在所有的存储过程实际上都不是存储过程....它们只是存储在服务器目录中文本文件中的 SQL 脚本。当应用程序启动时，它会在目录中查找并遍历每个文件并读出文本并将其保存在字典中。它还在文本上运行正则表达式，删除像 [PARAM] 这样的特殊序列，并用正确的符号替换它们，例如':' 在 Oracles 案例中或 '@' 对于 SQL SERVER。然后，当代码想要执行这些语句之一时，它会调用一个方法，该方法在字典中找到正确的语句并运行它。

现在这似乎已经完成，以防他们想要交换底层数据库技术。他们说他们只需将 sql 文件从目录中换出以使用适当语法的文件就可以了。

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

我发现当前的处理方式存在大量问题:

• 正在创建的数据库服务器上没有执行计划。
• 大量开销读取数百个文本文件，为每个文件构建一个字符串，并对其运行正则表达式。
• 不检查 SQL 语法。
• 内存占用大，所有这些存储过程都在内存中

你们怎么看？

这真的很糟糕还是我只是在提示，因为我以前从未见过这样的事情？

这种方法还有什么问题？

任何评论都将不胜感激，因为我正试图让同事们知道这太疯狂了......

Answer 1

为什么他们不在构建时使用脚本以 native 语法(PSQL、T-SQL)创建存储过程脚本，然后将其部署到数据库？我看不出这会带来太多工作，而且您可以获得编译存储过程代码等的所有好处。

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

我可以看出这种设计背后的原因:

• 存储过程代码过于特定于数据库，因此我们不会使用存储过程，我们将改用 SQL 语句。

• 即使是 SQL 语句也可以在其中包含特定于数据库的语法，因此我们将有一些 hokey 方法来即时转换它们运行时。

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