Сообщение Re[85]: Тормознутость и кривость linq от 26.04.2016 5:20
Изменено 27.04.2016 3:45 netch80
Здравствуйте, alex_public, Вы писали:
G>>Слушай, ты как маленький. постраничная разбивка результатов никаких проблем никому не приносила с 2008 года. Это толко у тебя с этим были какие-то проблемы. Также как и со скоростью linq впрочем.
_>С "2008-го года" — как мило. ))) У других такое уже десятилетиями работало. ))) Причём сразу в нормальном варианте (до которого MS дошла только в 2012-ом и только благодаря закреплению этого в стандарте SQL2008).
Тут всё чуть сложнее. Функциональность limit и offset, с точки зрения реляционного исчисления, это исключительный бред, особенно offset. Это не моя точка зрения, но я несколько раз слышал таких теоретиков-пуристов.
Возьми типичный форум (RSDN тоже подходит). Не знаю, как оно делается в реальности, но запрос вида http:// rsdn.ru/Forum/MsgUList.aspx?uid=${uid}&start=1001 для показа следующих K сообщений — это типичный алгоритм Шлемиэля за счёт преобразование в что-то вида select поля from messages where uid=${uid} order by msgid desc limit $n_per_page offset $offset; каждый следующий запрос дороже, и только качественный индекс позволяет сохранять скорость работы приемлемой. Можно было бы сделать вместо этого получение номера самого раннего из показанных на странице сообщений, формировать по нему URL (типа ...uid=25668&before=4195716), и в запросе тогда вместо offset $K будет where ... and messages.msg_id < $start_msg_id. Но я очень мало где видел такую реализацию — только два случая — blogspot и facebook; сразу видно, кто озабочен проблемой нагрузки, а кому пофиг
Некоторые умудряются даже "оптимизировать" такие запросы через вложенный select с предварительной выборкой только id, а потом по списку id брать уже тела сообщений, join'ить и прочие тяжёлые запросы; можешь поискать такие рекомендации на StackOverflow
пример
пример 2
Второй аргумент, выдвигаемый такими теоретиками — это возможное дублирование или пропуск строк, если выборка с limit+offset делается по неуникальному индексу. Пусть есть объекты A,B,C с параметром X=12,8,8 соответственно. Выборка с "order by X desc limit 2" может дать A,B, а может A,C; limit 2 offset 2 — или C, или B; и что именно когда выберется — зависит от фазы Луны. Поэтому стандартный ответ этих теоретиков — "вы хотите неправильного, пользуйтесь курсорами". То, что есть масса случаев правильного разумного использования этой фичи, хотя бы при уникальном индексе, их не волнует.
В любом подобном комитете адская смесь из теоретиков, практиков и при этом сторонников разных подходов и апологетов вендоров, поэтому любое решение имеет колоссальные шансы превратиться в "верблюд — лошадь, разработанная комитетом". То, что limit+offset не были введены в SQL с самого начала, показывает огромное влияние теоретиков-пуристов. В таком случае, если жизнь продавила против их желания фичу, которой они не хотят, они должны были её максимально испортить — чтобы практикам "жизнь мёдом не казалась". Поэтому они и были введены в стандарт с предельно идиотским и многословным синтаксисом. Опять-таки, у меня точных данных нет — это нужна инсайдерская информация, в публичных документах комитета этого нет — но к этому выводу ведёт вся обычная административная логика.
Если кто-то имеет точные данные против такого вывода — милости просим в студию.
G>>Берем то же разбиение по страницам. До 2012 SQL Server тебе нужен был подзапрос с row_number, после 2012 подзапрос не нужен.
У Oracle тоже очень долго обеспечивать limit можно было только через rownum, причём были стандартные грабли, о которых всех предупреждали. Offset можно было делать только на стороне клиента.
G>>Слушай, ты как маленький. постраничная разбивка результатов никаких проблем никому не приносила с 2008 года. Это толко у тебя с этим были какие-то проблемы. Также как и со скоростью linq впрочем.
_>С "2008-го года" — как мило. ))) У других такое уже десятилетиями работало. ))) Причём сразу в нормальном варианте (до которого MS дошла только в 2012-ом и только благодаря закреплению этого в стандарте SQL2008).
Тут всё чуть сложнее. Функциональность limit и offset, с точки зрения реляционного исчисления, это исключительный бред, особенно offset. Это не моя точка зрения, но я несколько раз слышал таких теоретиков-пуристов.
Возьми типичный форум (RSDN тоже подходит). Не знаю, как оно делается в реальности, но запрос вида http:// rsdn.ru/Forum/MsgUList.aspx?uid=${uid}&start=1001 для показа следующих K сообщений — это типичный алгоритм Шлемиэля за счёт преобразование в что-то вида select поля from messages where uid=${uid} order by msgid desc limit $n_per_page offset $offset; каждый следующий запрос дороже, и только качественный индекс позволяет сохранять скорость работы приемлемой. Можно было бы сделать вместо этого получение номера самого раннего из показанных на странице сообщений, формировать по нему URL (типа ...uid=25668&before=4195716), и в запросе тогда вместо offset $K будет where ... and messages.msg_id < $start_msg_id. Но я очень мало где видел такую реализацию — только два случая — blogspot и facebook; сразу видно, кто озабочен проблемой нагрузки, а кому пофиг
Некоторые умудряются даже "оптимизировать" такие запросы через вложенный select с предварительной выборкой только id, а потом по списку id брать уже тела сообщений, join'ить и прочие тяжёлые запросы; можешь поискать такие рекомендации на StackOverflow пример
пример 2
Второй аргумент, выдвигаемый такими теоретиками — это возможное дублирование или пропуск строк, если выборка с limit+offset делается по неуникальному индексу. Пусть есть объекты A,B,C с параметром X=12,8,8 соответственно. Выборка с "order by X desc limit 2" может дать A,B, а может A,C; limit 2 offset 2 — или C, или B; и что именно когда выберется — зависит от фазы Луны. Поэтому стандартный ответ этих теоретиков — "вы хотите неправильного, пользуйтесь курсорами". То, что есть масса случаев правильного разумного использования этой фичи, хотя бы при уникальном индексе, их не волнует.
В любом подобном комитете адская смесь из теоретиков, практиков и при этом сторонников разных подходов и апологетов вендоров, поэтому любое решение имеет колоссальные шансы превратиться в "верблюд — лошадь, разработанная комитетом". То, что limit+offset не были введены в SQL с самого начала, показывает огромное влияние теоретиков-пуристов. В таком случае, если жизнь продавила против их желания фичу, которой они не хотят, они должны были её максимально испортить — чтобы практикам "жизнь мёдом не казалась". Поэтому они и были введены в стандарт с предельно идиотским и многословным синтаксисом. Опять-таки, у меня точных данных нет — это нужна инсайдерская информация, в публичных документах комитета этого нет — но к этому выводу ведёт вся обычная административная логика.
Если кто-то имеет точные данные против такого вывода — милости просим в студию.
G>>Берем то же разбиение по страницам. До 2012 SQL Server тебе нужен был подзапрос с row_number, после 2012 подзапрос не нужен.
У Oracle тоже очень долго обеспечивать limit можно было только через rownum, причём были стандартные грабли, о которых всех предупреждали. Offset можно было делать только на стороне клиента.
Re[85]: Тормознутость и кривость linq
Здравствуйте, alex_public, Вы писали:
G>>Слушай, ты как маленький. постраничная разбивка результатов никаких проблем никому не приносила с 2008 года. Это толко у тебя с этим были какие-то проблемы. Также как и со скоростью linq впрочем.
_>С "2008-го года" — как мило. ))) У других такое уже десятилетиями работало. ))) Причём сразу в нормальном варианте (до которого MS дошла только в 2012-ом и только благодаря закреплению этого в стандарте SQL2008).
Тут всё чуть сложнее. Функциональность limit и offset, с точки зрения реляционного исчисления, это исключительный бред, особенно offset. Это не моя точка зрения, но я несколько раз слышал таких теоретиков-пуристов.
Возьми типичный форум (RSDN тоже подходит). Запрос вида http:// rsdn.ru/Forum/MsgUList.aspx?uid=${uid}&start=1001 для показа следующих K сообщений — это типичный алгоритм Шлемиэля за счёт преобразование в что-то вида select поля from messages where uid=${uid} order by msgid desc limit $n_per_page offset $offset (не знаю, как именно сделано на RSDN, но в куче доступных форумных движков только так); каждый следующий запрос дороже, и только качественный индекс позволяет сохранять скорость работы приемлемой. Можно было бы сделать вместо этого получение номера самого раннего из показанных на странице сообщений, формировать по нему URL (типа ...uid=25668&before=4195716), и в запросе тогда вместо offset $K будет where ... and messages.msg_id < $start_msg_id. Но я очень мало где видел такую реализацию — только два случая — blogspot и facebook; сразу видно, кто озабочен проблемой нагрузки, а кому пофиг Некоторые умудряются даже "оптимизировать" такие запросы через вложенный select с предварительной выборкой только id, а потом по списку id брать уже тела сообщений, join'ить и прочие тяжёлые запросы; можешь поискать такие рекомендации на StackOverflow
пример
пример 2
Второй аргумент, выдвигаемый такими теоретиками — это возможное дублирование или пропуск строк, если выборка с limit+offset делается по неуникальному индексу. Пусть есть объекты A,B,C с параметром X=12,8,8 соответственно. Выборка с "order by X desc limit 2" может дать A,B, а может A,C; limit 2 offset 2 — или C, или B; и что именно когда выберется — зависит от фазы Луны. Поэтому стандартный ответ этих теоретиков — "вы хотите неправильного, пользуйтесь курсорами". То, что есть масса случаев правильного разумного использования этой фичи, хотя бы при уникальном индексе, их не волнует.
В любом подобном комитете адская смесь из теоретиков, практиков и при этом сторонников разных подходов и апологетов вендоров, поэтому любое решение имеет колоссальные шансы превратиться в "верблюд — лошадь, разработанная комитетом". То, что limit+offset не были введены в SQL с самого начала, показывает огромное влияние теоретиков-пуристов. В таком случае, если жизнь продавила против их желания фичу, которой они не хотят, они должны были её максимально испортить — чтобы практикам "жизнь мёдом не казалась". Поэтому они и были введены в стандарт с предельно идиотским и многословным синтаксисом. Опять-таки, у меня точных данных нет — это нужна инсайдерская информация, в публичных документах комитета этого нет — но к этому выводу ведёт вся обычная административная логика.
Если кто-то имеет точные данные против такого вывода — милости просим в студию.
G>>Берем то же разбиение по страницам. До 2012 SQL Server тебе нужен был подзапрос с row_number, после 2012 подзапрос не нужен.
У Oracle тоже очень долго обеспечивать limit можно было только через rownum, причём были стандартные грабли, о которых всех предупреждали. Offset можно было делать только на стороне клиента.
G>>Слушай, ты как маленький. постраничная разбивка результатов никаких проблем никому не приносила с 2008 года. Это толко у тебя с этим были какие-то проблемы. Также как и со скоростью linq впрочем.
_>С "2008-го года" — как мило. ))) У других такое уже десятилетиями работало. ))) Причём сразу в нормальном варианте (до которого MS дошла только в 2012-ом и только благодаря закреплению этого в стандарте SQL2008).
Тут всё чуть сложнее. Функциональность limit и offset, с точки зрения реляционного исчисления, это исключительный бред, особенно offset. Это не моя точка зрения, но я несколько раз слышал таких теоретиков-пуристов.
Возьми типичный форум (RSDN тоже подходит). Запрос вида http:// rsdn.ru/Forum/MsgUList.aspx?uid=${uid}&start=1001 для показа следующих K сообщений — это типичный алгоритм Шлемиэля за счёт преобразование в что-то вида select поля from messages where uid=${uid} order by msgid desc limit $n_per_page offset $offset (не знаю, как именно сделано на RSDN, но в куче доступных форумных движков только так); каждый следующий запрос дороже, и только качественный индекс позволяет сохранять скорость работы приемлемой. Можно было бы сделать вместо этого получение номера самого раннего из показанных на странице сообщений, формировать по нему URL (типа ...uid=25668&before=4195716), и в запросе тогда вместо offset $K будет where ... and messages.msg_id < $start_msg_id. Но я очень мало где видел такую реализацию — только два случая — blogspot и facebook; сразу видно, кто озабочен проблемой нагрузки, а кому пофиг
Некоторые умудряются даже "оптимизировать" такие запросы через вложенный select с предварительной выборкой только id, а потом по списку id брать уже тела сообщений, join'ить и прочие тяжёлые запросы; можешь поискать такие рекомендации на StackOverflow пример
пример 2
Второй аргумент, выдвигаемый такими теоретиками — это возможное дублирование или пропуск строк, если выборка с limit+offset делается по неуникальному индексу. Пусть есть объекты A,B,C с параметром X=12,8,8 соответственно. Выборка с "order by X desc limit 2" может дать A,B, а может A,C; limit 2 offset 2 — или C, или B; и что именно когда выберется — зависит от фазы Луны. Поэтому стандартный ответ этих теоретиков — "вы хотите неправильного, пользуйтесь курсорами". То, что есть масса случаев правильного разумного использования этой фичи, хотя бы при уникальном индексе, их не волнует.
В любом подобном комитете адская смесь из теоретиков, практиков и при этом сторонников разных подходов и апологетов вендоров, поэтому любое решение имеет колоссальные шансы превратиться в "верблюд — лошадь, разработанная комитетом". То, что limit+offset не были введены в SQL с самого начала, показывает огромное влияние теоретиков-пуристов. В таком случае, если жизнь продавила против их желания фичу, которой они не хотят, они должны были её максимально испортить — чтобы практикам "жизнь мёдом не казалась". Поэтому они и были введены в стандарт с предельно идиотским и многословным синтаксисом. Опять-таки, у меня точных данных нет — это нужна инсайдерская информация, в публичных документах комитета этого нет — но к этому выводу ведёт вся обычная административная логика.
Если кто-то имеет точные данные против такого вывода — милости просим в студию.
G>>Берем то же разбиение по страницам. До 2012 SQL Server тебе нужен был подзапрос с row_number, после 2012 подзапрос не нужен.
У Oracle тоже очень долго обеспечивать limit можно было только через rownum, причём были стандартные грабли, о которых всех предупреждали. Offset можно было делать только на стороне клиента.