我有一個SQL Server 2008數據庫與一個組合鍵：ProjectID（GUID）和TaskID（int）。 ProjectID是項目表的外鍵。我想要TaskID自動遞增，但重新啓動每個ProjectID（即：每個項目ID應該有1,2,3，...作爲TaskID）。NHibernate，亞音速或L2S可以做實體自動增量嗎？
據我所知，這在SQL Server開箱即可使用，而且我需要一個存儲過程。在我深入研究之前，我想知道是否可以在我的ORM方面做到這一點？我在NHibernate 2.1.2和Subsonic 3.0之間未定，但即使Linq-To-SQL是可能的，也是一個選項（實體框架不是）。
我知道我可以手動編寫代碼，並且我知道在任何情況下都需要「SELECT max（TaskID）FROM任務WHERE ProjectID = @projectID」，但是如果我可以避免這樣做，我的ORM這樣做，那很好。
我沒有在他們各自的文檔中找到任何東西，但我不知道這個場景是否有適當的術語？
有一個原因很難 - 我討厭這種方式，但這種設計不是一個好主意。奧倫和我實際上有過這樣的討論（替代鍵和爲什麼你需要使用它們） - 給你的PK綁定意義幾乎總是會對你造成傷害。
讓您的索引器成爲您的索引器，讓您的FK成爲您的FK。讓PK過度到AUTO INCREMENT，讓它做到這一點。簡單的勝利。
我會建議一個觸發器（GASP！）或者可能是一個單獨的例程，您可以觸發插入，它爲新插入的記錄運行更新。
或者你可以使用NHib的期貨（或SubSonic的批處理或CodingHorror）一次執行所有內容。
但請爲孩子們 - 複合鍵是魔鬼。
你是對的（我決定將項目表中的主鍵從GUID更改爲ID，結果不是更改所有表，而是更容易刪除整個DB並從腳本重新創建它），但是我必須考慮這一點。如果主鍵是「只是一個沒有意義的隨機附加字段」，我沒有在其中看到很多要點，因爲唯一約束必須是ProjectID和TaskID的組合。但我還沒有大型的數據庫，所以我只是說我不完全明白:) – 2009-12-17 19:29:24
至於你的建議：我認爲這種或那種方式我必須這樣做，無論是作爲觸發器，一個SProc或在我的業務邏輯中。從本質上講，它只是一個事務，它鎖定了寫入表並執行select（）和insert。要檢查哪一個最合適。 – 2009-12-17 19:31:16
除了識別行之外，PK不應具有其他含義 - 所以它確實很好，因爲你沒有看到它的意義。數據庫的其餘部分取決於這一點 - 每個表都有一個唯一標識行內容的列。用有意義的數據構造這個數據是不好的，因爲數據的*含義*可能會改變 - 這意味着你的PK改變。 我曾與Kona發生過這種情況，我使用「用戶名」作爲唯一的ID。起初我認爲系統的用戶需要一個獨特的名字，這似乎是一個好主意。 – 2009-12-20 03:13:55
我不知道，但我的直覺說不。這將要在對象或業務邏輯中實現，ORM只是在那裏實現對象的持久性。我很好奇你爲什麼要爲每個項目重新啓動TaskID，如果它是爲了美觀，那麼我建議使用另一個字段來表示「TaskNumber」，並根據業務邏輯增加它，並將TaskID保留爲純自動遞增鍵。只是我的2p值。道歉沒有任何直接使用:) – Lazarus 2009-12-17 06:44:28
對不起，TaskID是真正的TaskNumber :)這是顯示給用戶的ID，因此它應該從1開始爲每個項目。 – 2009-12-17 06:48:52
儘管我並不完全同意Rob的回答，但我同意他的一般觀點：除非你絕對沒有選擇，否則不要選擇這種設計，在這種情況下，祝你好運。我不想觸摸這個設計的原因有很多，但這不是你問到的。 – 2009-12-17 12:47:18