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

VD>Проблема в том, что если хранимка не прямолинейна, то очень не просто добиться для нее хороших планов для разных входных параметров. Линк же будет генерировать разные запросы которые по определению будут давать более оптимальные планы.

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

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

S>Все что Вы написали, я понимаю. Это же был крик души на то, что я увидел в коде системы. Для получения одной записи вытаскиваются все из БД, а потом уже полученный результат преобразуется в List<T> и там ищется по параметрам.

В какой системе вы это увидели и какое отношение это имеет к linq2sql?

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

G>производительность системы — да, производительность программистов от этого сильно уменьшится.

Первое — не факт. Есть огромный шанс, что производительность системы тоже уменьшится.

Компиляция планов не единственный показатель влияющий на производительность сервера БД.
Учитывая, что планы в linq кэшируются по определению намного важнее смотреть на то насколько оптимальными будут эти планы. Лнин будет генерировать разные запросы для разных сочетаний условий. Это приведет к созданию более точных планов. А вот добиться того же с помощью хранимок не так просто.

Вы будете смеяться, но один из советов по оптимизации сложных хранимых процедур — это сброс кэша запросов при их выполнении. А другой — использование динамической генерации SQL-я. Эти подходы порождают оптимальные планы запросов. Если БД имеет огромный размер, лучший план запроса может оказаться лучшим выбором нежели экономия на компиляции планов выполнения.

Вот такие парадоксы бывают в наше время.

А вывод? Вывод простой. Преждевременная оптимизация (точнее оптимизация без понимания внутренних процессов) вредна. И если ты не знаешь, что будет узким местом, то лучше напиши в лоб и воспользуйся профайлером.

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

L>В какой системе вы это увидели и какое отношение это имеет к linq2sql?

Я увидел это в той системе участие в разработке которой я принимаю. Изначально вопрос был "Помогут ли хранимки повысить производительность". Но как могут помочь хранимки, если код написан через ... По этому я и назвал это "Криком души". В общем плохо все. Linq2sql тут не причем.

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

IB>Править нет. А вот когда нужно понять что происходит или что-то поменять с предсказуемым результатом — процедуры рулят.

Вань, а что же они у нас то не рулят на сервере?

IT тут недавно рассказывал, что он какой-то там кусок на сервере переписал с использованием линка и скорость выросла в несколько раз.

Какое-то расхождение теории и практики.

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

Tom>Не надо называть всех идиотами, критинами и самодурами. Это не добавляет сообщениям смысла.

Всех никто и не называл. Назвали одного самодура который дослужился до начальственных постов, а такой простой истины как — не переписывать код по одному только своему предположению — не усвоил.

То что озвучил здесь автор темы — это однозначно самодурство и полный не проффесионалим.

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

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

S>Может я телефончик его дам, Вы ему тоже это скажете. Наша команда замудохалась объяснять ему это. Нагрузочные тесты у нас выглядят так. Берутся все программисты и начинают тыкать по кнопочкам, в это время смотрится загрузка SQL сервера.

Зашибись!

Тебе о другом думать надо. Куда бы из этого отдела (или компании) срыть.
Как вариант, попробовать объяснить эти доводы начальству твоего начальства. Правда будет выглядеть как "стук".

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

S>Я тут ещё одно уточнение хочу вставить.
S>Проблема именно в том, что SQL сервер перестает отвечать клиентам. Т.е. считается, что он очень сильно нагружается из-за того, что ему каждый раз приходится компилить запросы.

Это бред!

А слабо открыть SQL Profiler и поглядеть в чем собственно дело?

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

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

Вы же не MS SQL 6.5 используете? Это в нем компилировались планы только для запросов из хранимок, а компиляция запроса содержащего 5 и более соединений могла продолжаться минутами. Сейчас же все в точности на оборот.

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

S>Если бы я все это умел У нас есть человек специальный для этого. Он полностью занимается БД на стороне SQL сервера. Может даже оптимизирует что-то там. Но вряд ли.

Ё моё! Ты думаешь, что тут все родились с SQL Profiler-ом в анусе и знанием SQL в мозге?
Прочти пару-тройку статей по выявлению проблем производительности в SQL Server. Потрахайся сам пару-тройку дней и все поймешь. С отладчиком ведь справляешься? Ну, так это не сильно сложнее.

S>Спасибо за совет. Попробую все это рассказать шефу.

Тебе Spender мудрую мысль сказал. Послушай его. Найди проблему сам и без выпендрежа и пыжения, аккуратно продемонстрируй ее решение начальнику. Тогда ты и проблему решишь, и уважение начальника заслужишь. Еще один бонус — получишь новые знания которые лишними никогда не бывают.

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


VD>А замена проверяемого во время компиляции, поддающегося рефакторингу и хранимого в системе контроля версий кода на код хранимый в БД, проверяемый только во время интерпретации и плохо поддающийся рефаторингу — это не усложнение?

Сам я сторонник Linq, но тут вы отстали от жизни.
В Visual Studio есть тип проекта для базы данных SQL Server.
Поддерживается контроль версий, проверка во время компиляции и в какой-то мере рефакторинг.

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

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

G>>производительность системы — да, производительность программистов от этого сильно уменьшится.

VD>Первое — не факт. Есть огромный шанс, что производительность системы тоже уменьшится.
От тупого переноса всего в ХП вряд ли. Запросы теже самые, параметры тоже.

VD>Компиляция планов не единственный показатель влияющий на производительность сервера БД.
VD>Учитывая, что планы в linq кэшируются по определению намного важнее смотреть на то насколько оптимальными будут эти планы. Лнин будет генерировать разные запросы для разных сочетаний условий. Это приведет к созданию более точных планов. А вот добиться того же с помощью хранимок не так просто.
Насчет Linq2SQL не уверен, а за EF замечал что он незначащие части запроса выкидывать умеет (хотя оптимизатор сиквеля также их выкинет).
AFAIK оптимизировать запросы на клиенте — гиблое дело, слишком мало информации и уж очень декларативен SQL.

VD>Вы будете смеяться, но один из советов по оптимизации сложных хранимых процедур — это сброс кэша запросов при их выполнении. А другой — использование динамической генерации SQL-я. Эти подходы порождают оптимальные планы запросов. Если БД имеет огромный размер, лучший план запроса может оказаться лучшим выбором нежели экономия на компиляции планов выполнения.
Это если условия фильтрации могут зависить от параметров. Но при тупом переносе запросов в ХП такого не возникнет.

VD>А вывод? Вывод простой. Преждевременная оптимизация (точнее оптимизация без понимания внутренних процессов) вредна. И если ты не знаешь, что будет узким местом, то лучше напиши в лоб и воспользуйся профайлером.
+1

У меня по поводу Linq to SQL \ EF обладают офигенным преимуществом. Они в коде программы позволяют строить проекции и накладывать дополнительные фильтры, что может увеличить производительность в разы.
ХП этому мешают. В принципе можно делать ХП для каждой выборки, но так мало кто поступает, обычно делают 4 crud процедуры и на этом успокаиваются.

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

VD>Ё моё! Ты думаешь, что тут все родились с SQL Profiler-ом в анусе и знанием SQL в мозге?
VD>Прочти пару-тройку статей по выявлению проблем производительности в SQL Server. Потрахайся сам пару-тройку дней и все поймешь. С отладчиком ведь справляешься? Ну, так это не сильно сложнее.

Конечно не родились. Но у меня своей работы до одного места. Я в эту компанию пришел месяц назад. Также по мимо меня взяли ещё и спеца по БД, с которым я сегодня поговорил и он тоже против тупого перехода на хранимки. Но к БД нас никто не пустит. Там своих людей хватает. Так что мы можем только идеи дать

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

VD>Тебе о другом думать надо. Куда бы из этого отдела (или компании) срыть.
VD>Как вариант, попробовать объяснить эти доводы начальству твоего начальства. Правда будет выглядеть как "стук".

Начальник у нас один, он же шеф, он же директор. Срыть я не могу, так как в Канаде без Канадского опыта тяжко. Я свою работу делаю. Хотел просто помочь. Спасибо за советы. Учту.

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

S>По сабжу. Ado.NET Team продолжает традиции МС в разработке фреймворков для доступа к данным: вместо того, чтобы довести хоть одну технологию до ума, они вечно бросаются из крайности в крайность — то у нас рулит disconnected approach и датасеты, то нифига, бизнесь не выживет без ормапперов с поддержкой наследования и статически верифицируемых запросов к СУБД.

И где здесь "из крайности в крайность"? Датасеты не имеют никакого отношения к ORM и ни датасеты ни ORM никак не связаны с "disconnected approach".

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

Tom>>О, а можно пару слов, про процедуру внесения изменений в схему?
L>Да я тут ничего особо умного не скажу, просто здравый смысл: изменения, вносимые одним разработчиком, не должны мешать работать другому.
L>Поэтому желательно чтобы у каждого разработчика была своя база и разработка велась на ней. При выкладывании в сорс-контрол должны одноврененно выкладываться скрипты для базы и изменения в сущностях.

Я так понял, что эта система "не дуракоустойчивая"? То есть есть возможность "забыть" "одновременно выложить" и поломать на какое-то время хранилище?

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

Tom>>Не надо называть всех идиотами, критинами и самодурами. Это не добавляет сообщениям смысла.

VD>Всех никто и не называл. Назвали одного самодура который дослужился до начальственных постов, а такой простой истины как — не переписывать код по одному только своему предположению — не усвоил.

VD>То что озвучил здесь автор темы — это однозначно самодурство и полный не проффесионалим.

Вообще-то неизвестно, может начальник на самом деле посиделв проайлере, что-то там себе надумал и просто не всё всем рассказал. Да и вообще судить о ком-то с треьих слов дело неблагодарное

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

L>Здравствуйте, DuШes, Вы писали:

L>Пожалуйста, если пишешь ответ, пиши его в ту ветку, к которой он относится. Невозможно же читать.

бросаю свои попытки вести с вами дискуссию, вы давно уже перешли на личности и умеете слушать только себя

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

L>>Да я тут ничего особо умного не скажу, просто здравый смысл: изменения, вносимые одним разработчиком, не должны мешать работать другому.
L>>Поэтому желательно чтобы у каждого разработчика была своя база и разработка велась на ней. При выкладывании в сорс-контрол должны одноврененно выкладываться скрипты для базы и изменения в сущностях.

_FR>Я так понял, что эта система "не дуракоустойчивая"? То есть есть возможность "забыть" "одновременно выложить" и поломать на какое-то время хранилище?

А у нас дураков и нет.

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

L>>Пожалуйста, если пишешь ответ, пиши его в ту ветку, к которой он относится. Невозможно же читать.

DШ>бросаю свои попытки вести с вами дискуссию, вы давно уже перешли на личности и умеете слушать только себя



Офигеть просто. Не отвечал ни на один вопрос, обвинял меня не пойми в чем, перемешивал ветки по своему усмотрению, а в итоге оказывается я перешел на личности и умею слушать только себя. Супер!

Удачи.

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

_FR>Я так понял, что эта система "не дуракоустойчивая"? То есть есть возможность "забыть" "одновременно выложить" и поломать на какое-то время хранилище?

Можешь предложить лучше?