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

_>>Примеры на гитхабе полностью компилируемые и исполняемые (собственно было бы странно иначе). Я проверял сам и может проверить любой наш читатель. Так что тут ты уже заврался сверх меры, причём на глазах у всех.
G>Ты предлагаешь тебе на слово поверить? Сделай тесты на этой библиотеке, докажи что не свистишь, заодно и проверим быстродействие.

Ну не хочешь верить, возьми уже сам и попробуй скомпилировать и запустить. В чём проблема то? ) Никаких зависимостей там нет (и библиотека сама только в виде заголовочный файлов, если не подключать настоящие СУБД, а ограничиться MockDB), достаточно тупо компилятора C++ и командной строки.

_>>Я вроде как вполне ясно написал уже раз десять. Запрос будет существенно отличаться от хранимки и будет оптимальным. При условие что его пишет не альтернативно одарённый человек. Хотя бы потому, что оптимальная запись является короче того страшного запроса в хранимке, с которым ты там боролся.
G>Ну так напиши этот оптимальный запрос.

В том же предыдущем сообщение он был, только чуть ниже (и виден в цитате чуть ниже в данном сообщение). У тебя какие-то проблемы со зрением? )

G>>>Я по-разному пробовал, результат не меняется.
_>>Совсем разучился уже со своим Linq. ))) string query="select ... where "+ship_date?"ship_date=@ship_date":"ship_date is null"; Заметно короче и проще твой страшной хранимки, не так ли? ) И при этом полностью оптимально с точки зрения создания планов...
G>Наконец-то, через 5 постов ты родил строку кода.
G>Надеюсь ты понял какую проблему надо решать.

Строка то всем очевидная и я её озвучил только потому, что ты признался что "Я по-разному пробовал, результат не меняется", т.е. что даже такая банальщина тебе уже не по силам. Ну так теперь, когда ты узнал как писать вменяемый код, ты понимаешь что все твои разговоры об оптимизации в той статье были бредовыми? ) Как раз из-за того что ты рассматривал только варианты хранимки vs linq.

G>Теперь задача посложнее:
G>

G>if(categoryFilter != null)
G>{
G>   products = products.Where(p => p.Category.Name.StartsWith(categoryFilter));
G>}
G>

G>Теперь от параметра не просто добавляется фильтр, а еще и делается джоин. Без параметров никаких джоинов нет.
G>Сама коллекция product может содержать быть отфильтрована и другими предикатами до фильтра по имени категории.
G>Как это сделать на склейке строк или твоей библиотеке?
G>Как родишь код, подумай что таких параметров на каждый запрос будет десяток.

Мне не очевидно из данного кода что там за join, зачем он и вообще о чём речь. Или показывай подробнее про задачу, таблицы и т.п. или просто покажи какой генерируется итоговый sql.

_>>Я тебе уже озвучил что мне требуется. ) Пример на C# (для сравнения) работающий с любой вменяемой СУБД (для Linq же это вроде не проблема, не так ли?) С SQL Server я никогда в жизни не встречался и начинать не планирую. )
G>Ты сейчас вертишься как уж на сковородке чтобы избежать прямого сравнения говноподелки с linq любыми способами.
G>Давай так:
G>1) ты вроде утверждал, что можно с помощью конфига подменить генерацию запросов в коде на C++, чтобы они работали для другой базы

Да, для этого мне надо будет подключить в код соответствующий провайдер этой СУБД (как и в linq кстати). Так вот соответствующего развёрнутого провайдера у меня на компьютере нет. Ну и чтобы ты понимал (если не в курсе), в мире C++ библиотеки распространяются в исходниках (хотя бы потому что компиляторы разные и несовместимые), а не в виде бинарника. Т.е. провайдер надо не просто скачать, а ещё и собрать. Причём для его сборки потребуются ещё и какие-то зависимости от производителя СУБД (SDK там какой-нибудь скачать или что-то в этом роде). И у меня нет ни малейшего желания разбираться как оно там делается для данной сомнительной СУБД, которая уж точно мне никогда в жизни не пригодится. )

G>То есть ты можешь взять базу northwind, перегать её в postgres, написать для нее тестовые запросы, выложить код на github.
G>А мы просто с гитхаба возьмем код, поменяем параметры чтобы тоже самое работало с SQL Server.
G>Так?
G>И ты работаешь с чем хочешь и сравнить потом можно. Так что приступай.

См. выше.