2010-11-15 20 views

回答

4

我不認爲有任何保證在插入和刪除行的排序 - 正如沒有訂單保證從任何表中選擇,沒有指定ORDER BY。


我決定看看我是否可以製作一個腳本,我們可以證明缺乏排序。在我的機器上(SQL 2008 Dev),我可以重複運行下面的腳本。它從插入和刪除中輸出2行。請注意,我們不接觸ID列,所以如果假設是正確的(它們以某種方式排序),那麼相同的ID應該以相同的順序出現。這裏不是這種情況。

首先,輸出:

ID   D1      V1 
----------- ----------------------- ---------------------------------------------------------------------------------------------------- 
32   2010-03-01 00:00:00.000 text 
60   2010-02-01 00:00:00.000 text 

(2 row(s) affected) 

ID   D1      V1 
----------- ----------------------- ---------------------------------------------------------------------------------------------------- 
60   2010-03-01 00:00:00.000 text 
32   2010-02-01 00:00:00.000 text 

(2 row(s) affected) 

而生成此腳本:

create table T1 (
    ID int not null, 
    D1 datetime not null, 
    V1 varchar(100) not null, 
    constraint PK_T1 PRIMARY KEY (D1,ID) 
) 
go 
create index IX_T1_D1 on T1(D1) 
go 
insert into T1(ID,D1,V1) 
select ID,DATEADD(day,ID-1,'20100101'),'text' 
from (select ROW_NUMBER() OVER (ORDER BY so1.id) from sysobjects so1,sysobjects so2,sysobjects) t(ID) 
go 
create trigger T_T1_U on T1 after update 
as 
begin 
    select * from inserted 
    select * from deleted 
end 
go 
sp_configure 'disallow results from triggers',0 
go 
RECONFIGURE 
go 
update T1 set D1 = DATEADD(month,CASE WHEN DATEPART(month,D1)=2 THEN 1 ELSE -1 END,D1) 
where D1 in ('20100201','20100301') 
go 
sp_configure 'disallow results from triggers',1 
go 
RECONFIGURE 
go 
drop table T1 
go 
+0

我很害怕,這就是我問的原因。這很糟糕,因爲如果主鍵已經改變,順序將不會幫助我。 – 2010-11-15 11:55:19

+0

你不應該有改變的主鍵。如果他們這樣做,他們不應該是PK。最好在這些條件下使用代理,並在前一個密鑰上放置一個唯一索引。 – HLGEM 2010-11-15 14:47:22

+1

@HLGEM - 我不會建議改變PK(雖然級聯更新確實有很大的幫助,如果你打算這麼做的話)。這更像是一個「我能否產生一個絕對破壞的例子」。 – 2010-11-15 14:52:45

-2

如果你有一個PRIMARY KEY在桌子上(你通常想要一個id字段是這個),那麼他們將始終以相同的順序返回。

+0

更進一步,存在對插入和刪除的表沒有密鑰,即使他們的基表具有關鍵,所以理論甚至不支持這些表格。 – 2010-11-15 12:00:17

+1

這是明顯錯誤的。擁有PK並不能保證任何時候的秩序。 – HLGEM 2010-11-15 14:49:11

相關問題