我们有一个应用程序，我们在 SQL 文件中添加 SQL 更改，它们在安装期间在测试和其他环境中运行。所以我们大约有 25 人工作，如果有人犯了任何错误，那么它会在测试环境中中断，因为那些是 DDL、DML，有时甚至是语法错误。
现在为了避免我正在考虑构建 SQl 验证器，它将在 SQL 文件中的查询上运行执行计划。 SQL 语句以单行或多行的形式编写。我们必须格式化它们，然后找出语法错误或任何其他错误，然后报告它。因此，在测试中安装时，它应该会损坏并节省大量时间和返工。
现在我们对 SQL 文件进行人工审查，但之后我们也有一些错误没有被捕获并且在测试中出现错误。
任何建议都将受到高度赞赏。
【问题讨论】：
你说你想要一个 SQL 验证器，但你可能需要一个更好的开发过程。
让我猜猜 - 你有一个每个人都在使用的单一开发服务器。他们在那里进行更改，希望它不会破坏任何东西，从该数据库中提取 SQL 语句，然后将它们应用到其他服务器。
这就是大多数 Oracle 开发人员的工作方式。这是痛苦的，不会扩大。使用几十年前开发的一些简单的软件开发方法有更好的方法。
版本控制是唯一的事实来源。 大多数 Oracle 商店只使用版本控制作为美化的备份。这是一个快速测试 - 删除开发服务器上的每个模式。如果您无法在 5 分钟内从源代码存储库中恢复并运行，那么您并没有真正使用版本控制。
问自己一个近乎哲学的问题 - 您的产品的真实、理想版本在哪里？即使您正在构建数据库产品，答案也应该是“版本控制的文本文件”，而不是“开发数据库”。
无限数量的数据库和模式。这比听起来容易 - 每个 Oracle 开发人员和测试人员都在他们的桌面上运行 Oracle。然后他们可以根据需要创建任意数量的实例和模式。我见过很多 Java 程序员这样做，但遗憾的是大多数 Oracle 开发人员认为这是不可能的。
自动化测试。自动化单元测试让您充满信心。听起来您现在对代码的信心为 0。您不必担心 语法 错误 - 这是一个编程 101 问题。如果团队中的每个人都在不断地构建和测试代码，那么错误将大大减少。有时事情仍然会中断 - 您可以添加诸如持续集成之类的内容，或者只是让那些不断破坏构建的人感到羞耻。
这三样东西的组合是最终的 SQL 验证器。版本控制以确保您拥有正确的代码。本地实例，以便于安装和验证代码。并进行自动化测试以进行验证。
【讨论】：