Question: I currently have (tables changed):

**User**

```
UserID uniqueidentifier,
CompanyID uniqueidentifier, (for future reference)
.. more unrelated fields

(PK: UserID)

```

**UserRating**

```
UserID uniqueidentifier,
MovieID uniqueidentifier,
RatingTypeID uniqueidentifier,
Rating tinyint

(PK: UserID, MovieID, RatingTypeID)

```

**RatingType**

```
RatingTypeID uniqueIdentifier,
Title varchar(25)

(PK: RatingTypeID)

```

The RatingType table contains "Favorite", "Need to Watch", etc. So actual Rating value is how much they liked a Favorite, or how badly the want to watch a movie etc. 

Now I introduce a new table:

**Company**

```
 CompanyID uniqueidentifier,
 .. more unrelated fields

```

The idea is that if a user becomes part of a company, due to requirements that cannot change, all the Ratings need to be Company ratings and not User Ratings. I'm not a normalization guru, but for some reason creating another table (below) seems redundant, but maybe I'm thinking to much into it.

**CompanyRating**

```
CompanyID uniqueidentifier,
MovieID uniqueidentifier,
RatingTypeID uniqueidentifier,
Rating tinyint

(PK: CompanyID, MovieID, RatingTypeID)

```

This feels incorrect because it almost matches the rating table and if I need to do any averages it becomes more difficult to average across two tables. Is there a better design for my needs?

Answer: 
I'm probably off-base here with my response, because I'm not really going to address finding the offending code, other than saying... Knowing the executed SQL from the trace, leads to knowing the associated ORM entity, which leads to Find All References in Visual Studio. Hopefully the code is [DRY](http://en.wikipedia.org/wiki/Don%27t_repeat_yourself), but that's a separate topic.

I'll focus on SQL performance a little more though.

Assuming the trace has sufficient information to log the ORM activity (probably TSQL batch start/complete), I would sort trace output by CPU, read, write and duration looking for high values. When found, I would optimize as necessary. Indexes to reduce reads, less inserts/updates where possible (fewer indexes where possible, read from a different more indexed table than you insert/update), less processing/triggers. This would be an entire series of replies to enumerate, but look for the top offenders and try to address them first.

All of that assumes that the ORM is the culprit. It is possible the server is experiencing issues not related to the ORM.

I recommend reading over this [whitepaper](http://msdn.microsoft.com/en-us/library/dd672789%28v=sql.100%29.aspx) several times and after identifying the source of the issue(s), CPU, memory or IO, I would start walking through the bottleneck specific detection steps identified in the whitepaper.

To skip the whitepaper and jump right in, at the server level I would use the built-in activity monitor to examine recent expensive queries. I would look for excessive executions/duration. Address, rinse, repeat.

Good luck :-)
How about these techniques using ToTraceString?

<http://blog.cincura.net/227674-how-to-show-sql-command-created-by-entity-framework/>
http://www.dotnetcurry.com/ShowArticle.aspx?ID=647

Collect and correlate with your trace.