Сообщение Re[123]: Тормознутость и кривость linq от 09.06.2016 4:34
Изменено 09.06.2016 5:21 Serginio1
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Lexey, Вы писали:
_>>>А вот такой ереси действительно нет и это очень хорошо. Допускать добавление такой тяжёлой вещи как join по желанию неких невнятных алгоритмов — это редкостный бред. Такие вещи должны явно декларироваться, чтобы программист мог легко оценить сложность запроса по одному взгляду на него.
L>>Вот это действительно феерично. Реальные запросы иногда включают десятки джоинов. Я бы с интересом посмотрел, как программист будет оценивать их сложность по одному взгляду. Про вред преждевременной оптимизации и говорить не стоит, видимо.
_>Если у нас сложится ситуация, в которой программист не способен проанализировать находящийся перед глазами sql запрос (не важно по причине слабости программист или же дикой сложности запроса), то запись этого же запроса с помощью Linq только ещё больше ухудшит данную ситуацию.
Сразу видно, что ты не работал с настоящими базами. Запрос на 10 страниц нормальное явление.
Склейка текстов запросов в подзапросы тоже нормальное явление. А вот использование линк как раз упрощает работу.
Это сродни использования методов, вместо кучи кода в одном месте. При этом еще и интеллисенсе итд.
Примеров Linq на 1С я приводил тебе кучу.
_>Здравствуйте, Lexey, Вы писали:
_>>>А вот такой ереси действительно нет и это очень хорошо. Допускать добавление такой тяжёлой вещи как join по желанию неких невнятных алгоритмов — это редкостный бред. Такие вещи должны явно декларироваться, чтобы программист мог легко оценить сложность запроса по одному взгляду на него.
L>>Вот это действительно феерично. Реальные запросы иногда включают десятки джоинов. Я бы с интересом посмотрел, как программист будет оценивать их сложность по одному взгляду. Про вред преждевременной оптимизации и говорить не стоит, видимо.
_>Если у нас сложится ситуация, в которой программист не способен проанализировать находящийся перед глазами sql запрос (не важно по причине слабости программист или же дикой сложности запроса), то запись этого же запроса с помощью Linq только ещё больше ухудшит данную ситуацию.
Сразу видно, что ты не работал с настоящими базами. Запрос на 10 страниц нормальное явление.
Склейка текстов запросов в подзапросы тоже нормальное явление. А вот использование линк как раз упрощает работу.
Это сродни использования методов, вместо кучи кода в одном месте. При этом еще и интеллисенсе итд.
Примеров Linq на 1С я приводил тебе кучу.
Re[123]: Тормознутость и кривость linq
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Lexey, Вы писали:
_>>>А вот такой ереси действительно нет и это очень хорошо. Допускать добавление такой тяжёлой вещи как join по желанию неких невнятных алгоритмов — это редкостный бред. Такие вещи должны явно декларироваться, чтобы программист мог легко оценить сложность запроса по одному взгляду на него.
L>>Вот это действительно феерично. Реальные запросы иногда включают десятки джоинов. Я бы с интересом посмотрел, как программист будет оценивать их сложность по одному взгляду. Про вред преждевременной оптимизации и говорить не стоит, видимо.
_>Если у нас сложится ситуация, в которой программист не способен проанализировать находящийся перед глазами sql запрос (не важно по причине слабости программист или же дикой сложности запроса), то запись этого же запроса с помощью Linq только ещё больше ухудшит данную ситуацию.
Сразу видно, что ты не работал с настоящими базами. Запрос на 10 страниц нормальное явление.
Склейка текстов запросов в подзапросы тоже нормальное явление. А вот использование линк как раз упрощает работу.
Это сродни использования методов, вместо кучи кода в одном месте. При этом еще и интеллисенсе итд.
Примеров Linq на 1С я приводил тебе кучу, а вот твой код ограничивался одной строкой.
Кстати Разработка → Entity Framework 7 + Redis
Обрати внимание на год
_>Здравствуйте, Lexey, Вы писали:
_>>>А вот такой ереси действительно нет и это очень хорошо. Допускать добавление такой тяжёлой вещи как join по желанию неких невнятных алгоритмов — это редкостный бред. Такие вещи должны явно декларироваться, чтобы программист мог легко оценить сложность запроса по одному взгляду на него.
L>>Вот это действительно феерично. Реальные запросы иногда включают десятки джоинов. Я бы с интересом посмотрел, как программист будет оценивать их сложность по одному взгляду. Про вред преждевременной оптимизации и говорить не стоит, видимо.
_>Если у нас сложится ситуация, в которой программист не способен проанализировать находящийся перед глазами sql запрос (не важно по причине слабости программист или же дикой сложности запроса), то запись этого же запроса с помощью Linq только ещё больше ухудшит данную ситуацию.
Сразу видно, что ты не работал с настоящими базами. Запрос на 10 страниц нормальное явление.
Склейка текстов запросов в подзапросы тоже нормальное явление. А вот использование линк как раз упрощает работу.
Это сродни использования методов, вместо кучи кода в одном месте. При этом еще и интеллисенсе итд.
Примеров Linq на 1С я приводил тебе кучу, а вот твой код ограничивался одной строкой.
Кстати Разработка → Entity Framework 7 + Redis
Обрати внимание на год