SQL 中的 FROM 不应该放在 SELECT 前面吗？（2011）
SQL 是否应该把 `FROM` 放在 `SELECT` 前面，触及查询语言如何在可读性、执行语义与工具支持之间取得平衡。评论者指出，当前这种类似英语的 `SELECT ... FROM ...` 语法会妨碍自动补全等功能，并掩盖逻辑执行顺序；而 LINQ、Kusto、PRQL 以及 DuckDB 的扩展等替代方案表明，`FROM` 优先或流水线式写法可能更符合人体工学。另一些人则认为，SQL 的历史悠久、生态锁定，以及它最初就是为让非工程师也能理解而设计的，意味着激进的语法变更不太可能发生；更现实的路径可能是改进工具，或提供配套的 DSL。
FROM 与 SELECT 的顺序
- 许多人认为
FROM … SELECT …更符合人们的思考方式：先定义数据源，再过滤/分组，最后投影列。 - 支持者表示，这种写法更贴近查询的实际执行方式，也会让大型、复杂的 SQL 文件更容易管理，并更容易在 ذهن中建模。
- 也有人为
SELECT … FROM …辩护，认为它先从“命令”开始（select/insert/update/delete），符合语句的分类方式，也更便于在文件中扫描。 - 两边都有人引用“更像英语”的理由：简单查询读起来像“从 Y 中选择 X”，但更复杂、包含多步骤的语句，或许用
from放前面更合适。
工具、自动补全与 IDE 体验
- 一个反复出现的抱怨是：在
SELECT先写的情况下，IDE 必须等到FROM写出后，才能提供列名补全。 FROM优先的语法（LINQ、Kusto/KQL、PRQL、DuckDB 的可选 FROM-first 模式、NRQL、ABAP OpenSQL）被赞赏为更利于智能提示，以及分步骤、可组合式查询。- 有人认为更智能的 IDE 可以绕过现有 SQL 的限制，但也有人认为，语言层面的支持在易用性上仍然是很大的提升。
执行顺序与语法顺序
- 几条评论对比了 SQL 的词法顺序（
SELECT→FROM→WHERE→ …）与其“逻辑”处理顺序（FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY）。 - 这种不一致被视为教学和心智模型上的痛点，尤其对新手而言，他们会以为更早出现的子句能“看到”更晚出现的子句。
安全性与 UPDATE 语法
UPDATE … SET … WHERE …让很多人警惕，因为SET在WHERE之前；人们担心一不小心漏掉WHERE。- 常见缓解办法包括：先写
WHERE，先写成SELECT做原型再转换为UPDATE，以及使用显式事务（BEGIN/ROLLBACK，或会警告无WHERE更新的工具）。
设计目标、英语化与替代方案
- 有人把 SQL 描述为古老、受英语影响、为非技术用户设计；其怪异之处则因为网络效应而一直保留。
- 若干评论建议，SQL“够用”但在组合性上很笨拙，因此主张使用专门的查询语言，或编译到 SQL 的 DSL（PRQL、SaneQL、HoneySQL、类似 Datalog 的系统、QUEL 风格语法）。
- 也有人认为数据库应该面向人提供 SQL，面向机器提供另一个更结构化的 API。