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

_>Ну т.е. "обход" заключается в записи запроса через голую sql строку (не важно каждый раз или один раз при создание view), как я собственно и говорил. )))

Да пофиг как. На типизацию это не влияет никак, в коде этих строк нет. Я и просто бывает голый SQL заряжаю в тех местах где LINQ не помогает. Например, для TRUNCATE TABLE, UPDATE STATISTICS, ALTER PARTITION FUNCTION и т.п. Причём используется это гораздо чаще, чем CTE.

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

_>Ну вот раз у тебя есть вагон примеров на linq, то конечно же легко найдёшь среди них хотя бы один где видно отличие между упомянутыми СУБД. И тогда я легко покажу тебе соответствующую разницу в случае той библиотечки.

Ты для начала покажи разницу хотя бы с примерами с пейджингом, которые тебе тут уже демонстрировали.

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

_>Если у нас сложится ситуация, в которой программист не способен проанализировать находящийся перед глазами sql запрос (не важно по причине слабости программист или же дикой сложности запроса), то запись этого же запроса с помощью Linq только ещё больше ухудшит данную ситуацию.

Сам догадался или кто ещё менее разбирающийся в линке подсказал?

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

I>>>>Достоинство linq как раз в том, что в нем нет взаимного соответствия с SQL. Именно из за этого он и интересен. Недостаток — вещи навроде CTE не поддерживаются.
_>>>Так в чём собственно достоинство то? ) А то формулировка "не как sql" вообще не катит (тем более при работе с sql СУБД).
I>>Структура запросов соответствуют структуре данных, а не

структуре SQL конкретной базы

.

_>Т.е. ты считаешь, что язык SQL не очень хорошо подходит для работы с реляционными СУБД? ) Я правильно понял твою мысль? )

Я выделил часть которую ты переврал или недопонял. Проблема в том, что структуру нужно менять, постоянно, под изменяющиеся требования и ограничения. sql здесь ничего не умеет.

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

I>>Вот и интересно, как sqlpp делает такой же фокус.

_>Ну вот раз у тебя есть вагон примеров на linq, то конечно же легко найдёшь среди них хотя бы один где видно отличие между упомянутыми СУБД. И тогда я легко покажу тебе соответствующую разницу в случае той библиотечки.

Тебе дали целый вагон таких примеров, но ты до сих пор этого не заметил

То самое видео, 16я минута
https://www.youtube.com/watch?v=m--oX73EGeQ

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

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

_>>>А вот такой ереси действительно нет и это очень хорошо. Допускать добавление такой тяжёлой вещи как join по желанию неких невнятных алгоритмов — это редкостный бред. Такие вещи должны явно декларироваться, чтобы программист мог легко оценить сложность запроса по одному взгляду на него.
L>>Вот это действительно феерично. Реальные запросы иногда включают десятки джоинов. Я бы с интересом посмотрел, как программист будет оценивать их сложность по одному взгляду. Про вред преждевременной оптимизации и говорить не стоит, видимо.

_>Если у нас сложится ситуация, в которой программист не способен проанализировать находящийся перед глазами sql запрос (не важно по причине слабости программист или же дикой сложности запроса), то запись этого же запроса с помощью Linq только ещё больше ухудшит данную ситуацию.
Сразу видно, что ты не работал с настоящими базами. Запрос на 10 страниц нормальное явление.
Склейка текстов запросов в подзапросы тоже нормальное явление. А вот использование линк как раз упрощает работу.
Это сродни использования методов, вместо кучи кода в одном месте. При этом еще и интеллисенсе итд.
Примеров Linq на 1С я приводил тебе кучу, а вот твой код ограничивался одной строкой.
Кстати Разработка → Entity Framework 7 + Redis
Обрати внимание на год

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

L>>Вот это действительно феерично. Реальные запросы иногда включают десятки джоинов. Я бы с интересом посмотрел, как программист будет оценивать их сложность по одному взгляду. Про вред преждевременной оптимизации и говорить не стоит, видимо.

_>Если у нас сложится ситуация, в которой программист не способен проанализировать находящийся перед глазами sql запрос (не важно по причине слабости программист или же дикой сложности запроса), то запись этого же запроса с помощью Linq только ещё больше ухудшит данную ситуацию.

Теоретически это возможно Даже не поспоришь

linq даёт более компактный код за счет того, что все лишнее убирается в функции.Примерно так

      return from user in users(source) where affected(user) orderby currentOrder(user) select projector(user);

users, affected, currentOrder, projector — это функции, которые возвращают не значения, а деревья выражений.
Количество джойнов и структура реального SQL запроса зависит от того, что будет в этих функцих.

Вот projector

Expression<Func<User, Account>> projector = (user)=>user.Account(AccountType.LastActive);

Вот этот proector внезапно дал +1 джойн к запросу выше.

Здравствуйте, alex_public, Вы писали:
_>При исполнение предкомпилированного запроса вообще не используется sql код. Ни для компиляции, ни для вычисления хеша и поиска в кеше. Соответственно при исполнение запроса он не готовится на клиенте (в смысле клиенте СУБД) и не передаётся на сервер (СУБД).
Ух ты! И как это работает? Что же передаётся на сервер?
Я, наверное, сорву какие-то покровы, но на сервер при исполнении prepared statement уезжает вполне себе SQL.
Выглядит он примерно так:

exec sp_execute 10003, N'Hello, world!', 222

Его парсит парсер — точно так же, как и любой другой запрос. И точно так же первым делом вычисляется хеш, и происходит поиск в кеше планов.

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

_>Если у нас сложится ситуация, в которой программист не способен проанализировать находящийся перед глазами sql запрос (не важно по причине слабости программист или же дикой сложности запроса), то запись этого же запроса с помощью Linq только ещё больше ухудшит данную ситуацию.

Моя практика говорит об обратном. Средний написатель запросов пишет запросы хуже, чем их генерит linq2db.

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

_>>Ну т.е. "обход" заключается в записи запроса через голую sql строку (не важно каждый раз или один раз при создание view), как я собственно и говорил. )))
IT>Да пофиг как. На типизацию это не влияет никак, в коде этих строк нет. Я и просто бывает голый SQL заряжаю в тех местах где LINQ не помогает. Например, для TRUNCATE TABLE, UPDATE STATISTICS, ALTER PARTITION FUNCTION и т.п. Причём используется это гораздо чаще, чем CTE.

Ну так а к работе linq2db в режиме sql строк у меня никаких претензий и нет. Разве что кроме лишнего слова в название. ))) Ну и это будет всего лишь одна из множества обычных ORM, без принципиальной "плюшки" в виде статического анализа sql. Но зато универсальная и быстрая.

Ну а работая через linq мы получаем ту самую модную плюшку, но в обмен на уменьшение возможностей (как мы видели не полный спектр sql покрывается) и появление тормозов (существенных накладных расходов для определённых запросов).

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

_>>Ну вот раз у тебя есть вагон примеров на linq, то конечно же легко найдёшь среди них хотя бы один где видно отличие между упомянутыми СУБД. И тогда я легко покажу тебе соответствующую разницу в случае той библиотечки.
IT>Ты для начала покажи разницу хотя бы с примерами с пейджингом, которые тебе тут уже демонстрировали.

Это где тут была показана разница в пейджинге между postresql и sqlite? )

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

I>>>Структура запросов соответствуют структуре данных, а не
I>

структуре SQL конкретной базы

_>>Т.е. ты считаешь, что язык SQL не очень хорошо подходит для работы с реляционными СУБД? ) Я правильно понял твою мысль? )

I>Я выделил часть которую ты переврал или недопонял. Проблема в том, что структуру нужно менять, постоянно, под изменяющиеся требования и ограничения. sql здесь ничего не умеет.


Что-что нужно менять постоянно? ) Поясни ка на каком-нибудь конкретном реальном примере...

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

_>>Ну вот раз у тебя есть вагон примеров на linq, то конечно же легко найдёшь среди них хотя бы один где видно отличие между упомянутыми СУБД. И тогда я легко покажу тебе соответствующую разницу в случае той библиотечки.
I>Тебе дали целый вагон таких примеров, но ты до сих пор этого не заметил
I>То самое видео, 16я минута
I>https://www.youtube.com/watch?v=m--oX73EGeQ

Посмотрел и 16-ую и 17-ую... Разницы между упомянутыми СУБД не вижу. Хорошо видна разница между всякой экзотикой, но у меня такие СУБД (а главное провайдеры к ним) не стоят, так что повторить данный пример и посмотреть генерируемый для них sql я не смогу. О чём я собственно тебе уже неоднократно упоминал.

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

_>>При исполнение предкомпилированного запроса вообще не используется sql код. Ни для компиляции, ни для вычисления хеша и поиска в кеше. Соответственно при исполнение запроса он не готовится на клиенте (в смысле клиенте СУБД) и не передаётся на сервер (СУБД).
S>Ух ты! И как это работает? Что же передаётся на сервер?
S>Я, наверное, сорву какие-то покровы, но на сервер при исполнении prepared statement уезжает вполне себе SQL.
S>Выглядит он примерно так:
S>

S>exec sp_execute 10003, N'Hello, world!', 222
S>

S>Его парсит парсер — точно так же, как и любой другой запрос. И точно так же первым делом вычисляется хеш, и происходит поиск в кеше планов.

1. Не стоит мерить все РСУБД по одному SQL Server. Я уже заметил что это почему-то характерная особенность любителей linq (тут некоторые даже путали стандарт sql из-за этого), но всё же надо помнить что популярных РСУБД много и работают они весьма по разному...
2. Я думаю всем очевидно, что в моей фразе говорилось об sql коде запроса (select... ), так что даже в случае SQL Server она является полностью верной. Если конечно не пытаться специально цепляться к формулировкам на пустом месте, за отсутствием каких-либо реальных контраргументов.

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Если у нас сложится ситуация, в которой программист не способен проанализировать находящийся перед глазами sql запрос (не важно по причине слабости программист или же дикой сложности запроса), то запись этого же запроса с помощью Linq только ещё больше ухудшит данную ситуацию.
НС>Моя практика говорит об обратном. Средний написатель запросов пишет запросы хуже, чем их генерит linq2db.

Вообще то разговор совсем о другом. Здесь речь не о качестве написания/генерации запросов (это кстати отдельная большая тема), а о сравнение читабельности одного и того же запроса в sql форме и в форме linq.

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

I>>>>Структура запросов соответствуют структуре данных, а не
I>>

структуре SQL конкретной базы

_>>>Т.е. ты считаешь, что язык SQL не очень хорошо подходит для работы с реляционными СУБД? ) Я правильно понял твою мысль? )

I>>Я выделил часть которую ты переврал или недопонял. Проблема в том, что структуру нужно менять, постоянно, под изменяющиеся требования и ограничения. sql здесь ничего не умеет.

_>Что-что нужно менять постоянно? )

Даже большой синий текст ты не видишь ? Бедненький, тянет же тебя юродствовать.

>Поясни ка на каком-нибудь конкретном реальном примере...

Новые требования почти всегда приводят к изменениям базы. Например пилишь ты учет сотрудников простецкий, контора в 50 человек, один проект, один заказчик. Тут собственно автоматизировать сравнительно немного. С ростом конторы придется вносить изменения в структуру базы. Например, надо добавить возможность трекать все результаты входных проверок, внутренних собеседований, отзывов заказчиков на каждого сотрудника. Новая фича — изменения базы, новые таблицы, связи.
После того, как добавишь эту часть, где то через год-два-три надо будет изменить структуру этой части базы — появятся новые хотелки, новые требования. Какие — а хрен его знает. Может учет эффективности, результативности и для этого надо будет увеличить детализацию.

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

I>>Тебе дали целый вагон таких примеров, но ты до сих пор этого не заметил
I>>То самое видео, 16я минута
I>>https://www.youtube.com/watch?v=m--oX73EGeQ

_>Посмотрел и 16-ую и 17-ую... Разницы между упомянутыми СУБД не вижу. Хорошо видна разница между всякой экзотикой, но у меня такие СУБД (а главное провайдеры к ним) не стоят, так что повторить данный пример и посмотреть генерируемый для них sql я не смогу. О чём я собственно тебе уже неоднократно упоминал.

Ты видишь, что структура запросов разная ? Покажи как твоя мулька делает такое же. Хотя бы объясни подробно. Потому как до сих пор ты говорил об sqlpp как о "генерация кода склейки в компайлтайм".

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

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

_>>>При исполнение предкомпилированного запроса вообще не используется sql код. Ни для компиляции, ни для вычисления хеша и поиска в кеше. Соответственно при исполнение запроса он не готовится на клиенте (в смысле клиенте СУБД) и не передаётся на сервер (СУБД).
S>>Ух ты! И как это работает? Что же передаётся на сервер?
S>>Я, наверное, сорву какие-то покровы, но на сервер при исполнении prepared statement уезжает вполне себе SQL.
S>>Выглядит он примерно так:
S>>

S>>exec sp_execute 10003, N'Hello, world!', 222
S>>

S>>Его парсит парсер — точно так же, как и любой другой запрос. И точно так же первым делом вычисляется хеш, и происходит поиск в кеше планов.

_>1. Не стоит мерить все РСУБД по одному SQL Server. Я уже заметил что это почему-то характерная особенность любителей linq (тут некоторые даже путали стандарт sql из-за этого), но всё же надо помнить что популярных РСУБД много и работают они весьма по разному...
Ну, расскажите мне, какая из "многих популярных СУБД" выполняет prepared statements без помощи SQL.
_>2. Я думаю всем очевидно, что в моей фразе говорилось об sql коде запроса (select... ), так что даже в случае SQL Server она является полностью верной. Если конечно не пытаться специально цепляться к формулировкам на пустом месте, за отсутствием каких-либо реальных контраргументов.
Я думаю, что всем очевидно ваше непонимание принципов работы РСУБД, и желание выиграть спор любой ценой, меняя задним числом смысл ваших утверждений. Напомню: вы утверждали, что серверу не надо парсить SQL запрос. Увы, парсинг всё ещё нужен. Если вы захотите рассказать, что парсинг полукилобайта текста вместо килобайта сильно спасёт производительность, то лучше не надо — ваши смешные представления про то, как оптимизируются программы, мне уже известны.

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

_>Вообще то разговор совсем о другом. Здесь речь не о качестве написания/генерации запросов (это кстати отдельная большая тема), а о сравнение читабельности одного и того же запроса в sql форме и в форме linq.

Моя практика показывает, что чудовища, которые все боятся трогать, потому что на понимание того что надо поменять уходит куча времени, будучи переписанными на linq превращаются во вполне удобоваримый код. Просто потому что все возможности по декомпозиции в SQL, даже включая страшненький СТЕ настолько убоги, что копипаста там — нашефсе.

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

_>Здравствуйте, Ночной Смотрящий, Вы писали:

_>>>Если у нас сложится ситуация, в которой программист не способен проанализировать находящийся перед глазами sql запрос (не важно по причине слабости программист или же дикой сложности запроса), то запись этого же запроса с помощью Linq только ещё больше ухудшит данную ситуацию.
НС>>Моя практика говорит об обратном. Средний написатель запросов пишет запросы хуже, чем их генерит linq2db.

_>Вообще то разговор совсем о другом. Здесь речь не о качестве написания/генерации запросов (это кстати отдельная большая тема), а о сравнение читабельности одного и того же запроса в sql форме и в форме linq.

Сколько запросов в день ты пишешь и каков размер среднего запроса?

Например в 1С без Конструктора запроса сложно понять портянки запросов. Linq как раз играет роль конструктора, где можно отдельно отделить подзапросы, а затем уже объединять их в соединения.
Всегда в VS можно посмотреть из чего состоит каждый подзапрос. Очень удобно.