Database 调用所有数据库/ORM/数据访问层专家

我有一个小挑战给你。希望你能帮忙

问题是： 我需要一个能够“处理”主键/复合键更改的解决方案。通过 “handle”，我的意思是我应该仍然能够执行CRUD操作，代码更改很少或没有。从应用程序/数据库的角度来看，它需要尽量减少麻烦

我可以在阳光下使用几乎任何东西，除了以下两个限制： 1） 需要使用SQL Server吗 2） 不允许使用动态SQL查询

我最初的头脑风暴/可能的解决方案？ a） 它能在存储过程级别以某种方式解决吗

b） 通过适配器模式/反射/DB模式查询巧妙地使用DTO可以解决这个问题吗

c） 某种奇特的LINQ/反射技巧

d） NHibernate能解决这个问题吗

我有点时间压力（我必须在周末前想出一个解决方案），所以任何帮助都将不胜感激。所以，在这里。如果您认为您可能有一个解决方案，但不想麻烦使用任何脑细胞，这里有一个激励（希望它会起作用）…如果您的解决方案为我解决了问题，我最终使用它，您将获得您选择的任何Microsoft软件的完全许可商业（非盗版：P）版本，例如Windows 7、SQL Server、Office 2007、，等等。如果激励不起作用，我希望你无论如何都能帮助我？：-）这里有点绝望：-）

非常感谢。

看看CSLA（）业务对象

---

还可以看看CodeSmith的代码生成，它有CSLA模板和其他ORM模板。

假设您有一个带有生成主键的记录，这只是该记录的一个不可变标识符。最终用户永远不需要看到它，但它允许您可靠地标识记录，从而指定对它的更改

其他列或列的组合是用户认为的PrimaryKey，但实际上不是“primary”，它们只是（可能是唯一的）可更改的数据片段

所以GivenName/FamilyName——可能是索引的好字段，但显然是可以更改的

社会保险号码（或者一些据说是唯一的号码）——听起来像是一个很好的主键。嗯，但是假设某个错误的人进入了系统，你怎么修复它呢。如果它只是一个具有唯一索引的列，那么问题出在哪里

真正的主键是我们用来连接到其他表的东西

用户——用户的订单

---

由系统生成的主键链接，而不是像他的可变SSN一样的东西。

我想问为什么主键和外键经常变化——听起来像是一个不稳定的模型。如果你使用的是内置了大量业务逻辑的自然键，我会重新考虑。是的，听起来像是经常变化的自然键——在我看来，这让它们成为一个糟糕的键选择。如果他不能使用动态SQL，那一定是指存储过程，不是吗？谢谢，这是DBA向我推荐的，但不幸的是，客户重新使用了这种方法。因为？更重要的是，他为什么在乎？这是一个实现细节。谢谢。我会调查的。它会提供某种简单的抽象或映射，而不是物理数据库结构吗？