Work item https://entityframework.codeplex.com/workitem/1574 shows a case in which there is a huge performance penalty for having a CASE expression in a SQL predicate. In general CASE clauses used in predicates prevent SQL Server (and possibly other database engines) from leveraging indexes.
When a value has to be projected or returned there is probably no option than to use a CASE statements but in predicates other alternatives exist, e.g.:
```
... (@p__linq__0 AND [Join7].[OrganizationPeriodId] = p__linq__1) OR (NOT @@p__linq__0 AND Table.OrganizationPeridoId = 0)
```
Instead of:
```
... ([Join7].[OrganizationPeriodId] = (CASE WHEN (@p__linq__0 = 1) THEN @p__linq__1 ELSE 0 END))
```
We should verify if the first translation results in better performance.
When a value has to be projected or returned there is probably no option than to use a CASE statements but in predicates other alternatives exist, e.g.:
```
... (@p__linq__0 AND [Join7].[OrganizationPeriodId] = p__linq__1) OR (NOT @@p__linq__0 AND Table.OrganizationPeridoId = 0)
```
Instead of:
```
... ([Join7].[OrganizationPeriodId] = (CASE WHEN (@p__linq__0 = 1) THEN @p__linq__1 ELSE 0 END))
```
We should verify if the first translation results in better performance.