我可以依赖 sql 视图中的字段顺序吗？

Posted 2023-02-26

【中文标题】我可以依赖 sql 视图中的字段顺序吗？

【英文标题】：can I rely on the order of fields in a sql view?

【发布时间】：2010-11-09 21:00:03

【问题描述】：

如果我创建一个视图并按照我想要“接收”它们的顺序选择我的字段，我可以完全确定我可以从我的应用程序中调用“Select * from myView”，而不是再次指定所有字段名在我的选择查询中？

我问这个是因为我将整个数据行传递给我的 DataModel，并通过将属性分配给附加到该数据行的 itemarray 中的不同索引来构造对象。如果这些字段出现故障，我的对象可能会发生什么情况。

我知道我不能依赖一个存在于视图中的订单（之前在这个视图上被烧毁了）。但是我不确定字段的顺序。

对不起，如果这是 sql noob 级别。我们都从某个地方开始。现在，我的应用程序代码中所有无关的字段名称都使可读性变得有些困难，所以如果我可以安全地返回并用 * 替换很多语法，那就太好了。

这些表很小，所以我不担心在单个字段上使用 * 的影响。我只是希望不要编写不必要的语法。

【问题讨论】：

我通常手动指定列名，除非我只是在 SQL 提示符下运行快速一次性查询。它让我知道（并且 SQL 引擎知道）我的期望——也就是说，它增加了“合同”的明确性，并允许更快地生成更有意义的错误。额外的信息也可以用来减少记录的大小，从而节省传输成本等。如果“可读性”是一个问题，也许你还没有适应一种舒适的可读方式来编写 SQL，或者因为你的方式受到了阻碍。环境希望您表达查询。

我想也许我还没有适应一种舒适的方式来编写我的 sql 查询。当您的查询调用 40 多个字段并跨越 2 行以上时，在非宽屏显示器上很难阅读。在我的部门。我们保持“精益”观点，或者至少尝试这样做。视图中仅包含必要的内容。如果您在视图中需要更多信息，那么可能还有另一个可以提供更广泛的数据（即：每日统计数据与每小时统计数据）。这通常使第 # 行可以接受，但有时会有荒谬的 # 字段。

【参考方案1】：

保证列顺序，行顺序（如您所述）不是。

【讨论】：

So ... NO 用于行顺序 :-)保证行顺序的唯一方法（通常）是使用 ORDER BY 子句位于查询的***。 （ORDER BY 在视图中不被接受，某些版本会拒绝它 IIRC。）

@pst：SQL Server 将拒绝视图中的ORDER BY，除非您还包含TOP。

值得注意的是，这会受到表更改和 sp_refreshview 等的影响？

@gbn：请参阅我对您的回答的评论。

【参考方案2】：

如果这两个都为真，则列顺序可能无法保证或可靠

视图定义内部有SELECT * 或SELECT tableA.* 对相关表进行任何更改

您需要运行 sp_refreshview：请参阅question/answer 了解潜在问题。

当然，如果视图中有简单的SELECT * FROM table，为什么不直接使用表格，省去一些维护的痛苦呢？

最后，不得不说，不推荐使用SELECT *... :-)

【讨论】：

我的解释不是视图被定义为select * from table，而是OP想在他的代码中使用select * from view。

@Joe Stefanelli：当然，但当人们做这样的事情时，这是我的pet dislikes 之一......啊。得到它。我希望我的答案更清晰。

视图实际上非常复杂（不是我写的），并且使用了一些计算字段和函数，我似乎永远无法正确获取字段名。我们谈论的是

【参考方案3】：

是的，从左到右的列顺序在 SQL 中得到保证。事实上，它是用来证明 SQL 不是真正关系型的三大缺陷之一（例如，参见 The Importance of Column Names by Hugh Darwen）、重复行和 NULL 值是另外两个。

【讨论】：

+1 表示 SQL 不是真正的关系型，但请参阅 gbn 对select * 的危险的回答。

【参考方案4】：

是的，我一直依赖 select * 按视图或表中指定的顺序返回字段。

例如Microsoft SQL - "* 指定应返回 FROM 子句中所有表和视图中的所有列。这些列由表或视图返回，如 FROM 子句中指定的那样，并按顺序返回它们存在于表或视图中。”

【讨论】：

但是，正如 gbn 所指出的，如果表的结构发生变化，那么select * 返回的字段将会不同。

是的，在 SQL 选择中使用星号既是一大福音，也是一大祸根。但问题作者明确表示他并不担心这一点。

不完全是 - OP 说“这些表很小，所以我不担心在单个字段上使用 * 的影响”，这意味着额外的处理/带宽成本不是问题。