我有一个现有的数据库与我想建立使用EF4.0一个新的应用程序

I have an existing DB with which I would like to build a new app using EF4.0

一些表没有定义主键，这样，当我创建一个新的实体数据模型，我得到以下信息：该表/视图TABLE_NAME没有定义主键，也没有有效的主键可以推断该表/视图已被排除。要使用该实体，您需要查看您的架构，添加正确的钥匙，并取消它。

Some tables do not have primary keys defined, so that when I create a new Entity Data Model, I get the following message: "The table/view TABLE_NAME does not have a primary key defined and no valid primary key could be inferred. This table/view has been excluded. To use the entity, you will need to review your schema, add the correct keys, and uncomment it".

如果我想使用它们，修改数据，必须我一个PK一定要添加这些表，或者是有一种变通方法，使我不就得了？

If i want to use them and modify data, must I necessarily add a PK to those tables,or is there a workaround so that I don't have to?

推荐答案

的错误意味着正是它说。

即使你能解决这个问题，相信我，你不想。对可能被引入奇怪的bug的数量是惊人和可怕的，更不用提的是，你的表现可能会因此倒闭。

Even if you could work around this, trust me, you don't want to. The number of confusing bugs that could be introduced is staggering and scary, not to mention the fact that your performance will likely go down the tubes.

不解决此。修复你的数据模型。

Don't work around this. Fix your data model.

编辑：我见过的许多人都downvoting这个问题。这很好，我想，但请记住，OP问映射的表没有主键，而不是查看。答案仍然是相同的。工作围绕着英孚的需要对表的PK是可管理性，数据完整性和性能的角度来看是一个坏主意。

I've seen that a number of people are downvoting this question. That's fine, I suppose, but keep in mind that the OP asked about mapping a table without a primary key, not a view. The answer is still the same. Working around the EF's need to have a PK on tables is a bad idea from the standpoint of manageability, data integrity, and performance.

有些人评论说，他们没有固定的基础数据模型，因为它们映射到一个第三方应用程序的能力。这不是一个好主意，因为该模型可以从你更改了。可以说，在这种情况下，你会想要映射到一个视图，这又不是什么OP问。

Some have commented that they do not have the ability to fix the underlying data model because they're mapping to a third-party application. That is not a good idea, as the model can change out from under you. Arguably, in that case you would want to map to a view, which, again, is not what the OP asked.