Здравствуйте, alex_public, Вы писали:

IT>>Понятно. Такие решения мы тоже проходили в своё время и определили их в малопригодные для реальной жизни.
_>Ну не прямо такие естественно (т.к. C# не поддерживает парадигму метапрограммирования), а видимо построение и исполнение SQL AST в рантайме. А почему посчитали малопригодным?

Наметапрограммировать и в C# можно чего угодно. Особенно в pre-compile time. Что касается малопригодности, то такие решения, чтобы более менее полноценно решать проблемы строгой типизации превращаются в пазлы с триллиардами методов. Обилие вызовов методов в том числе даже для поддержки африфметических операций делает код абсолютно нечитаемым. Достаточно посмотреть на твои примеры — SQL читается легко, а набор методов ужос-ужос. Если на linq народ переходит практически безболезненно, то такие решения чаще всего отторгаются разработчиками из-за малопонятности и более сложной поддержкой чем даже SQL.

_>>>А как float (да и любой другой тип в C++) по твоему может быть null? )))
IT>>Действительно. Т.е. либо потом косяки отлавливать, либо упоротый монструозный код писать.
_>Ээээ что? )

Ты в курсе как работает сравнение в SQL, если один из операндов NULL? Правильно, ты получишь false даже если оба операнда равны NULL. Т.е. чтобы корректно реализовать сравнение нужно его писать не как

Field1 = @p

А в зависимости от значение @p либо

Field1 = @p

либо

Field1 IS NULL

В результате народ не парится и пишет

Field1 IS NULL AND @p IS NULL OR Field1 = @p

Частенько план запроса в таких случаях убивается.