ID列在Postgresql中的位置重要吗？ [英] Is id column position in Postgresql important?

问题描述

我正在测试一个删除主键列ID的迁移（我想使用外键作为主键）。当我运行并还原迁移时，我看到表的状态是相同的，除了id列现在是最后一个。

I was testing a migration that deletes a primary key column id (I wanted to use a foreign key as primary key). When I ran and reverted the migration, I saw that the state of my table is the same, except that id column is now last one.

它将改变行为我的数据库有任何形式，我是否应该麻烦恢复迁移还原代码中的列顺序？

Will it change the behaviour of my database in any way and should I bother to restore the column order in the migration revert code?

推荐答案

从理论上讲，所有内容都应很好，但是在某些情况下您的代码可能会失败。

In theory everything should be fine, but there are always scenarios when your code could fail.

例如：

a） 盲插入 ：

 INSERT INTO tab_name
 VALUES (1, 'b', 'c');

盲插入是当INSERT查询没有指定要接收插入数据的列。

这为什么不好？

因为数据库架构可能会更改。列可以移动，重命名，
添加或删除。而当它们出现时，
可能发生至少三件事之一：

Because the database schema may change. Columns may be moved, renamed, added, or deleted. And when they are, one of at least three things can happen:

1. 查询失败。这是最好的情况。有人从目标表中删除了一个列，现在没有足够的列来插入
   ，或者有人更改了数据类型并且插入的
   类型不兼容，依此类推。但是至少您的数据没有损坏
   ，甚至可能由于
   错误消息而存在问题。

1. The query fails. This is the best-case scenario. Someone deleted a column from the target table, and now there aren’t enough columns for the insert to go into, or someone changed a data type and the inserted type isn’t compatible, or so on. But at least your data isn’t getting corrupted, and you may even know the problem exists because of an error message.

查询继续工作，没有任何问题。这是最坏的情况。您的数据没有损坏，但是怪物
仍然藏在床底下。

The query continues to work, and nothing is wrong. This is a middle-worst-case scenario. Your data isn’t corrupt, but the monster is still hiding under the bed.

b） 按原价订购

SELECT *
FROM tab
ORDER BY 1;

这篇关于ID列在Postgresql中的位置重要吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！