3

这绝对是疯子......

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

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

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

我发现目前的完成方式存在巨大问题：

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

大家怎么看？

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

这种方法还有什么问题？

任何评论都将不胜感激，因为我正试图向同事传达这太疯狂了......

4

2 回答 2

1

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

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

我可以看到这种设计背后的原因：

  • 存储过程代码过于特定于数据库，所以我们不会使用存储过程，而是使用 SQL 语句。

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

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

于 2012-07-20T09:47:49.010 回答
0

大家怎么看？

我认为这是过度工程的典型案例：谁改变了他们的数据库提供者？它真的带来了什么吗？

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

在我看来，两者兼而有之：这很糟糕，但如果他们已经这样运行了一段时间，那么它一定会起作用。

这种方法还有什么问题？

事实上，每次重新计算执行计划可能是最大的问题：
性能损失如此之大！我说可能是因为性能并不总是要求（过度优化也不是更好；）
真正错误的是他们重新发明了轮子：LINQ 本身就是这样做的。
这意味着随着 LINQ 随着时间的推移得到改进，该公司将逐渐落后，因为他们不会从改进中受益。

如果您有任何影响力，请尝试与他们讨论 LINQ。

于 2012-07-20T11:31:30.557 回答