将 SQL 从一个数据库迁移到另一个数据库，不应要求你从空白编辑器开始。
困难在于，PostgreSQL、SQL Server、MySQL、MariaDB、Oracle、Snowflake、Databricks 和 SQLite 共享一种通用语言，但在许多细节上的实现各不相同。
函数会发生变化。数据类型有所不同。日期运算遵循不同规则。标识符使用不同的引用样式。过程化 SQL 可能需要重新组织。
Sqlinfy 正是为这一专门问题而构建的。
明确的转换路径
每次转换都从两个明确的选择开始：
源方言
目标方言
这一点很重要，因为 SQL 迁移不是通用的文本重写。SQL Server 到 PostgreSQL 的转换，与 MySQL 到 Snowflake 的转换遵循不同的路径。
明确转换路径可以减少歧义，并为开发者提供可重复的起点。
便于人工审查的易读输出
转换后的 SQL 应易于检查。
开发者需要了解发生了哪些变化，将结果与源代码进行比较，并在代码审查期间讨论不确定的部分。易读的输出让这些工作比手动重新构建查询更高效。
诊断信息让不确定性保持可见
并非每项数据库功能都有完美的对应项。
特定厂商的函数、特殊数据类型、隐式转换或过程化语句可能需要特别关注。诊断信息有助于识别这些区域，以便开发者在测试或部署前进行审查。
诊断信息并不意味着失败，而是一个有用信号，表明转换需要人工判断。
单条和批量工作流
小型任务通常从将一条查询粘贴到转换器中开始。
较大的迁移可能涉及包含 SQL 文件的文件夹、重复的转换路径以及许多等待审查的脚本。批处理有助于将这些工作放入队列，同时保留转换后的输出供检查。
每个套餐使用相同的引擎
Sqlinfy 不会为价格更高的套餐保留不同的转换引擎。
付费套餐提升的是实际使用容量：
• 更大的脚本
• 每日更多转换次数
• 批处理
• 优先支持
免费套餐是使用你自己的 SQL 测试转换工作流的一种真正方式。
转换是第一步，而不是最终批准
任何自动化转换器都不应取代测试。
转换后，使用具有代表性的数据比较源端和目标端的结果。检查行数、计算总数、NULL 值、日期、排序、精度以及任何数据库特有的行为。
推荐的工作流是：
理解
转换
审查
测试
部署
Sqlinfy 有意保持专注。它的作用是减少重复的 SQL 重写工作，并为迁移的下一阶段向开发者提供结构化、可审查的结果。