通用 AI 工具在处理 SQL 时很有用。它们可以解释查询、提出优化建议、起草示例，或帮助开发人员理解不熟悉的函数。
数据库迁移还有一项额外要求：可重复性。
团队可能需要将数百个查询从同一种源方言转换为同一种目标方言。这个过程需要一致的规则、清晰可见的警告，以及能够进入审查和测试流程的输出。
这与进行开放式对话是不同的工作。
通用 AI 辅助适用的场景
当你需要完成以下任务时，AI 助手可以提供帮助：
• 理解不熟悉的 SQL
• 构思可能的重写方式
• 了解某个数据库函数的等效写法
• 生成测试用例
• 解释错误消息
• 编写查询文档
这些属于探索性任务。多个可能的答案都可能有用。
结构化转换变得重要的场景
迁移工作流需要明确定义源和目标。
例如：
源：SQL Server
目标：PostgreSQL
每次转换都应采用相同的方言规则。输出应始终可供审查，并且应将不确定的映射显示出来，而不是隐藏起来。
在以下工作中，这一点十分重要：
• 对许多脚本重复执行转换
• 批处理文件
• 团队代码审查
• 可审计性
• 一致的格式
• 诊断信息
• 回归测试
问题不在于某个工具是否在所有情况下都更好，而在于哪个工具适合当前步骤。
提示词不是迁移规范
提示词可以描述开发人员的需求，但措辞上的细微变化可能会影响答案。重要上下文也可能被意外遗漏。
结构化转换器会明确源方言、目标方言和转换工作流。这可以减少歧义，并为团队提供一个可重复的起点。
可重复性并不保证正确性
一致的输出仍然需要验证。
数据库引擎在 NULL 行为、隐式类型转换、日期运算、精度、排序规则、过程逻辑和错误处理等方面存在差异。有些构造没有完全对应的等效写法。
最稳妥的工作流是将工具与人工判断结合起来：
使用结构化转换完成可重复的第一轮转换。
审查诊断信息和数据库特定行为。
使用文档或 AI 助手调查不熟悉的情况。
使用具有代表性的数据测试结果。
为工作的每个部分选择合适的工具
Sqlinfy 专注于源到目标的 SQL 转换。它并不打算取代开发人员使用的所有编码或研究工具。
它的职责范围更明确：
• 在受支持的 SQL 方言之间进行转换
• 明确转换路径
• 生成可供审查的输出
• 显示诊断信息
• 支持单个文件和批处理工作流
这正是它专注于此的意义所在。
在实际迁移中，可靠的进展来自可重复的转换、仔细的审查和测试的结合。开放式辅助可以帮助回答过程中的问题，但不应取代明确的迁移工作流。
