.net NHibernate、亚音速或L2S是否可以按实体自动递增？

我有一个SQL Server 2008数据库，它有一个复合键：ProjectID（GUID）和TaskID（int）。ProjectID是项目表的外键。我想让TaskID自动递增，但为每个ProjectID重新启动（即：每个ProjectID都应该有1,2,3，…作为TaskID）

据我所知，这在SQL Server开箱即用中是不可能的，我需要一个存储过程。在我开始之前，我想知道我是否可以在我的ORM方面做这件事？我还不确定NHibernate2.1.2和亚音速3.0之间的关系，但如果可能的话，甚至LINQtoSQL也是一个选项（实体框架不是）

我知道我可以手动编写代码，而且我知道几乎可以肯定，在任何情况下都需要“从projectd=@projectd的任务中选择max（TaskID）”，但如果我可以避免这样做，而是让我的ORM这样做，那就太好了

---

我在他们各自的文档中没有发现任何东西，但我真的不知道是否有一个合适的术语来描述这个场景

这很难，这是有原因的——我不喜欢这样说，但这种设计不是个好主意。Oren和我实际上进行了讨论（代理键以及为什么需要使用它们）——将意义与PK捆绑在一起几乎总是会伤害到你

让你的索引器成为你的索引器，让你的FK成为你的FK。让PK自动递增，让它完成它的工作。简单的胜利

我建议使用一个触发器（GASP！），或者在插入时使用一个单独的例程，您可以启动该例程，为新插入的记录运行更新

或者您可以使用NHib的futures stuff（或SubSonic的batch或Codinghoror）让它一次执行所有操作

---

但是，请注意，对于孩子们来说，复合键是魔鬼。

我不知道，但我的直觉告诉我不会。这要么在对象中实现，要么在业务逻辑中实现，ORM就是为了实现对象的持久性。我很好奇为什么您希望每个项目都重新启动TaskID，如果是为了美观，那么我建议使用另一个字段来表示“TaskNumber”，并根据您的业务逻辑将其递增，并将TaskID保留为纯自动递增键。只是我的2便士。抱歉没有任何直接用途：）抱歉，TaskID实际上是TaskNumber:）它是显示给用户的ID，因此每个项目都应该从1开始。虽然我不完全同意Rob的回答，但我同意他的一般看法，除非你完全没有选择，否则不要遵循此设计，在这种情况下祝你好运。我不想碰这个设计有很多原因，但这不是你所问的。你在一个方面是对的（我决定将项目表的主键从GUID更改为ID。结果表明，与其更改所有表，不如更容易删除整个数据库并从脚本中重新创建它），但我必须考虑一下。如果主键是“只是一个没有意义的随机额外字段”，我看不出它有什么意义，因为唯一的约束必须是ProjectID和TaskID的组合。但我还没有建立大型数据库，所以我只是说我还没有完全理解：）至于你的建议：我认为我必须这样做，无论是作为一个触发器，一个大过程，还是在我的业务逻辑中。本质上，它“只是”一个事务，用于锁定表以进行写入，并执行select max（）和insert。我要检查哪一个是最合适的。PK除了识别行之外不应该有其他意义-所以你没有看到它的意义实际上是好的。数据库的其余部分取决于这一点——每个表都有一列唯一标识行的内容。用有意义的数据构建它是不好的，因为数据的意义可能会改变——这意味着你的PK会改变。我曾在Kona中使用“用户名”作为唯一id。最初我认为系统用户需要一个唯一的名称，这似乎是一个好主意。然而，当我想允许用户保持匿名时，出现了一个问题，将其改为Guid。我不能这样做-用户名，因为我的PK被作为字符串锁定，而且一旦有非用户登录，我需要更改PK-愚蠢！我必须去更新所有相关的表格，以适应！这就是为什么PK需要对DB有意义，而不是对你。