从嵌入式 SQL 迁移到 ODBC 的工具 [关闭]

Posted 2023-03-31

【中文标题】从嵌入式 SQL 迁移到 ODBC 的工具 [关闭]

【英文标题】：Tool to migrate from Embedded SQL to ODBC [closed]

【发布时间】：2013-01-20 14:26:14

【问题描述】：

我有一堆通过嵌入式 SQL 访问数据库（Oracle、DB2 和 Sybase）的 C 代码：基本代码是相同的，但是使用三种不同的预编译器，构建了三种可执行文件，每个数据库/平台一个。

我工作得很好，但我们现在需要迁移到使用 ODBC 访问的解决方案。

问题是：可以使用哪些工具/api？一种直接的方法似乎是编写自定义预编译器（或修改现有的）来包装所有 SQL 和主机变量调用，以调用 ODBC 连接。

有人可以推荐用于该任务的工具或 api 以使其保持简单吗？

或者它是一种更简单的方法，另一种方法？

谢谢

【参考方案1】：

对于此类情况，通常没有现成的答案；人们的代码库中总是有许多惊喜，而这种组合使 COT 工具无法在个别情况下变得经济。

您想要的是一个program transformation system (PTS)，它带有一个 C 前端，可以定制以解析嵌入式 SQL。此类工具可以应用源到源重写规则（“如果你看到 this 模式，则将其替换为 that 模式”）来解决问题。

这些工具需要一些技术上的努力来配置。在您的情况下，您必须调整 C 前端来处理嵌入式 SQL；这通常不在 C 解析器中。 （如何以当前形式处理这些东西？）C 预处理器会有问题，因为人们用它做滥用的事情，这确实违反了解析器对宇宙的嵌套结构视图。然后你必须编写和测试规则。

这项工作是一种沉没成本，可以与手工完成工作或一些更临时的脚本（例如 Perl）的工作进行交易，后者部分完成工作，让您清理它。我们的经验是，低于 100K SLOC 的麻烦是不值得的，超过 1M SLOC 您没有机会进行手动/临时修复，并且您的里程会有所不同。

在这些中等大小的情况下，您可以为权衡取舍而苦恼；这也需要精力和时间。有时，最好还是硬着头皮做任何可以清理的事情。

我们的 DMS 软件再造工具包就是这些 PTS 之一。它有一个可定制的 C 解析器和预处理器，正是为了帮助处理这些配置问题。我相信，***文章中提到的其他 PTS 没有任何与它们相关的严重 C 解析器。 （我是 DMS 背后的人）。

【讨论】：

幸运的是，代码库（> 300 万行代码）坚持硬编码规则。编写自定义解析器似乎是“可能的”，而且成本不高（通过 antlr）。我认为我们会碰壁，然后让更多像你这样的专业和有才华的人。谢谢

很多人认为编写解析器既简单又必要。它不是，尤其是对于像 C 这样的真正语言。而且，请参阅我关于“解析后的生活”semanticdesigns.com/Products/DMS/LifeAfterParsing.html 的文章。不过，我认为您对此类项目在政治上如何下放的想法是正确的。