views:

18

answers:

1

I'm using Entity Framework 4.0 to access data in a table with a unique column constraint. If the constraint is violated, an exception occurs when I call SaveChanges(), as expected. My question is whether I should allow the exception to be thrown in the first place. I could alternatively do a select to avoid inserting the duplicate data (I assume a transaction would be necessary).

What's the generally accepted best practice in this scenario?

+1  A: 

Avoiding an exception is usually a good idea - throwing an exception is a rather elaborate and time and resource intensive operation. So if you can easily check whether a unique key value already exists, then I would probably do that. Assuming you have a unique index or unique constraint on that column at the database level, then (at least for SQL Server) already have an index on that column, so checking for a specific value would be fairly simple and would not have a huge performance impact.

The other question is: how often do you think this would happen? Once a day? Once every couple of weeks? Several times a minute? If it happens only fairly infrequently - once in a blue moon - I wouldn't bother trying to check first - in that case, just let the exception happen and handle it.

So I guess it's really a matter of how expensive is it to check first, and how often does it happen? If you can check it very easily --> do so, by all means! But if it's a rather elaborate operation to check, and it happens only very rarely, then just handle the exception.

marc_s
Thanks for the common sense answer; this is pretty much what I was thinking. Since constraint violations are rare in this case, I'll leave it as is.
Andy West