Здравствуйте, DuШes, Вы писали:
DШ>позволяющие убрать непосредственное общение со скриптами, но общий минус у всех один и тот же — это возможность получения такого плана выполнения, DШ>который и в страшном сне не приснится ну и соотвественно медленные запросы...те вещи, которые являются родными для sql определенного диалекта ну никак не перенести в конструкции c# linq (функции обработки данных, преобразования типов), к тому же, если речь идет о сложной логике обработки данных (скажем, некие предпросчеты, или запросы к распределенным системам, построенным на linked servers) то гораздо выгоднее и компактнее написать такую логику в процедурах и использовать их как методы linq to sql context-а... (уж не говорю о том, что сложно построить linq контекcт, построенный на нескольких базах данных)
Как я понял из сообщения топикстартера, его начальство надеялось получить прирост производительности путем тупого переноса sql-я, генерируемого LINQ2SQL-ем, в хранимые процедуры. О ручном тюнинге sql-я речи и не было.
[...]
L>Как я понял из сообщения топикстартера, его начальство надеялось получить прирост производительности путем тупого переноса sql-я, генерируемого LINQ2SQL-ем, в хранимые процедуры. О ручном тюнинге sql-я речи и не было.
да я собственно и не спорю...соглашусь с вашим постом, что прироста производительности не будет, речь даже не о том, что sql сервер умеет кешировать не только скомпилированные планы процедур, но также и вызовы простых запросов.
вообще, желание нормальное — увеличить производительность — но трудозатраты очень большие, даже не только потому, что тупо перенести запросы в процедуры не получится, придется переделывать вообще механизм доступа к данным и думать о тех orm классах, которые были сгенерированы на основе таблиц...
в той постановке задачи, которая присуствует сейчас, самая большая проблема следующая:
желание оставить классы сгенерированной схемы и работать с ними будет затруднительно, потому что не каждая хранимка (метод схемы) будет возвращать тот набор полей, которые потребуется для маппинга в сгенерированные классы, иначе, придется ручками описывать те классы, которые ранее нам генерировал компилятор для анонимных типов
вообще на мой взгляд или работать с linq по старому без процедур или не работать вообще, иначе сразу можно застрелиться
Здравствуйте, DuШes, Вы писали:
DШ>да я собственно и не спорю...соглашусь с вашим постом, что прироста производительности не будет, речь даже не о том, что sql сервер умеет кешировать не только скомпилированные планы процедур, но также и вызовы простых запросов.
Откуда взялись "скомпилированные планы процедур"? Такого понятия вроде нет. Понятие План применимо только к запросам.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, DuШes, Вы писали:
DШ>>да я собственно и не спорю...соглашусь с вашим постом, что прироста производительности не будет, речь даже не о том, что sql сервер умеет кешировать не только скомпилированные планы процедур, но также и вызовы простых запросов.
L>Откуда взялись "скомпилированные планы процедур"? Такого понятия вроде нет. Понятие План применимо только к запросам.
S>Оптимизировать никто не будет. Предлагается текущие запросы, сформированные LINQ просто скопировать на сервер и сделать из них хранимые процедуры. Про кэш я сказал. На это мне ответили, что запросов тысячи и что кэш здесь не поможет. Я не силен в этом, но как-то сомневаюсь. Зачем же он тогда нужен, если не поможет. Можете привести аргументы, статьи какие-нибудь. Буду очень признателен
Тогда это бред. Сейчас серверы кэшируют любые запросы и планы запросов.
S>Если коротко: S>1) СП стоит рассматривать не как средство подтюнить производительность, а как средство инкапсуляции БД/внешние интерфейсы. Другими словами — способ дать доступ к данным, не открывая всех внутренностей. S>2) +1 к "не использовать Linq2SQL в серьёзных системах". S>3) Linq2SQL уже не модно — EF очередное наше всё.
В общем мы пришли к выводу, что автор подставляет шефа
Шеф знает, что лучше хранимки, но не знает зачем. Или не хочет объяснять.
Я уже, к сожалению, столкнулся с вариантом, когда объяснение серьёзными терминами или абстракциями, знание которых отсутствует у исполнителей, наносит только вред.
Здравствуйте, DuШes, Вы писали:
DШ>Здравствуйте, Lloyd, Вы писали:
DШ>[...]
L>>Как я понял из сообщения топикстартера, его начальство надеялось получить прирост производительности путем тупого переноса sql-я, генерируемого LINQ2SQL-ем, в хранимые процедуры. О ручном тюнинге sql-я речи и не было.
DШ>да я собственно и не спорю...соглашусь с вашим постом, что прироста производительности не будет, речь даже не о том, что sql сервер умеет кешировать не только скомпилированные планы процедур, но также и вызовы простых запросов.
DШ>вообще, желание нормальное — увеличить производительность — но трудозатраты очень большие, даже не только потому, что тупо перенести запросы в процедуры не получится, придется переделывать вообще механизм доступа к данным и думать о тех orm классах, которые были сгенерированы на основе таблиц...
DШ>в той постановке задачи, которая присуствует сейчас, самая большая проблема следующая: DШ>желание оставить классы сгенерированной схемы и работать с ними будет затруднительно, потому что не каждая хранимка (метод схемы) будет возвращать тот набор полей, которые потребуется для маппинга в сгенерированные классы, иначе, придется ручками описывать те классы, которые ранее нам генерировал компилятор для анонимных типов
DШ>вообще на мой взгляд или работать с linq по старому без процедур или не работать вообще, иначе сразу можно застрелиться
А почему для всех свет клином сошелся на процедурах? Есть много других средств инкапсуляции в SQL, есть View, которыя для запросов подходят гораздо лучше процедур, есть instead of триггеры, которые позволяют работать с вьюхами, как с таблицами.
Я вообще не вижу смыла делать CRUD на процедурах.
И никакого геморроя потом в программе не появляет, можно использовать все тот же Linq\EF.
Здравствуйте, gandjustas, Вы писали:
G>А почему для всех свет клином сошелся на процедурах? Есть много других средств инкапсуляции в SQL, есть View, которыя для запросов подходят гораздо лучше процедур,
View сложнее оптимизировать. Запросы к View приводят к не всегда предсказуемым результатам в плане производительности и оптимизатору с ними тяжелее.
G>есть instead of триггеры, которые позволяют работать с вьюхами, как с таблицами.
Триггеры не очевидны. И опять же проблемы с оптимизацией — изменяешь одно маленькое поле в одной маленькой табличке, а она порождает каскадное обновление всей базы и это не возможно предсказать, если не знаешь всю структуру базы с потрохами и логикой. Процедуры в этом плане очевиднее и предсказуемее.
G>Я вообще не вижу смыла делать CRUD на процедурах.
CRUD — нет, а вот в логике по сложнее я скорее за процедуры, чем за View и триггеры.
Просто в БД abstraction penalty дороже обходится и гораздо меньше возможности дать понять разработчику что стоит за простым обращением.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>А почему для всех свет клином сошелся на процедурах? Есть много других средств инкапсуляции в SQL, есть View, которыя для запросов подходят гораздо лучше процедур, IB>View сложнее оптимизировать. Запросы к View приводят к не всегда предсказуемым результатам в плане производительности и оптимизатору с ними тяжелее.
Это я знаю. В этом конкретном случае видимно никто и не собирался залить в процедуры для оптимизации, обычно их применяют только для инкапсуляции, view в этом плане гороздо выгоднее.
G>>есть instead of триггеры, которые позволяют работать с вьюхами, как с таблицами. IB>Триггеры не очевидны. И опять же проблемы с оптимизацией — изменяешь одно маленькое поле в одной маленькой табличке, а она порождает каскадное обновление всей базы и это не возможно предсказать, если не знаешь всю структуру базы с потрохами и логикой. Процедуры в этом плане очевиднее и предсказуемее.
ИМХО нет разницы править 4 процедуры или вьюху и 3 триггера.
G>>Я вообще не вижу смыла делать CRUD на процедурах. IB>CRUD — нет, а вот в логике по сложнее я скорее за процедуры, чем за View и триггеры.
Linq\EF сейчас обеспечивает только CRUD. Любую логику, которая должна выполняться в СУБД придется делать в процедурах\функциях.
Спасибо всем ответившим!
Даже не знаю что делать
Просто тут ситуация ещё запутаннее, чем может показаться на первый взгляд.
Есть система, которая написана на хранимках и текстовых запросах к БД. Сейчас переписываем все на LINQ и появились тормоза в системе. Шеф, старой закалки, решил, что это все из-за LINQ (хотя реально в системе (production) он не используется) и сказал, что LINQ-зло, но отказываться нельзя, а так как можно стучаться к хранимкам из LINQ, давайте делать так.
Как я понял, у него просто каша в голове. Посоветовали ему взять спеца по БД и с ним проконсультироваться, где у нас Bottle-neck в БД.
Ещё раз спасибо за советы. Подумаем, что можно тут сделать.
Здравствуйте, Spender, Вы писали:
S>Проблема в следующем. Имеется база данных доступ к которой организован через запросы LINQ to SQL. Шеф сказал, что от LINQ он отказываться не хочет, но теперь вместо доступа к таблицам и полям БД надо будет использовать LINQ к Store Procedure. Аргументом к этому служит то, что SQL-серверу не надо будет компилировать запрос каждый раз и это увеличит производительность.
Если все это правда, то твой шеф — кретин. По совокупности следующих пунктов:
1. LINQ to SQL, завязаный только на хранимые процедуры — это "LINQ to SQL" без слова "LINQ". Что там собственно останется-то хорошего, если оттуда убрать запросы?
2. Запросы компилируются и скорости перенос тех же самых запросов в хранимки не добавит. Это известный факт.
3. Работать с хранимками намного менее удобно, чем с кодом, по многим причинам. Т.е. хранимки будут тормозить разработку.
4. И самое главное: совершенное самодурство и кретинизм делать что-то потому что "я думаю что так будет быстрее". Промерить не судьба? Может у вас там где-нибудь StringBuilder поставить нужно вместо string += и все летать начнет? И переписывать ничего не нужно будет? Может быть есть только один тормозной запрос и его стоит вынуть и оптимизировать, вместо того, чтобы делать это для всех подряд? Если делается расчет на будущее — может стоит сначала написать нагрузочные тесты?
Здравствуйте, Spender, Вы писали:
S>Спасибо всем ответившим! S>Даже не знаю что делать S>Просто тут ситуация ещё запутаннее, чем может показаться на первый взгляд. S>Есть система, которая написана на хранимках и текстовых запросах к БД. Сейчас переписываем все на LINQ и появились тормоза в системе. Шеф, старой закалки, решил, что это все из-за LINQ (хотя реально в системе (production) он не используется) и сказал, что LINQ-зло, но отказываться нельзя, а так как можно стучаться к хранимкам из LINQ, давайте делать так. S>Как я понял, у него просто каша в голове. Посоветовали ему взять спеца по БД и с ним проконсультироваться, где у нас Bottle-neck в БД.
Конечно любую оптимизацию надо начинать с поиска узкого места, но шеф ваш имхо вполне прав. Использую линк к сторам вы получите compile time проверки, что выгодно отличает этот подход от простого вызова при помощи ADO.NET
Здравствуйте, Jakobz, Вы писали:
J>Здравствуйте, Spender, Вы писали:
S>>Проблема в следующем. Имеется база данных доступ к которой организован через запросы LINQ to SQL. Шеф сказал, что от LINQ он отказываться не хочет, но теперь вместо доступа к таблицам и полям БД надо будет использовать LINQ к Store Procedure. Аргументом к этому служит то, что SQL-серверу не надо будет компилировать запрос каждый раз и это увеличит производительность.
J>Если все это правда, то твой шеф — кретин. По совокупности следующих пунктов:
Я бы на вашем месте не был так котегоричен.
J>1. LINQ to SQL, завязаный только на хранимые процедуры — это "LINQ to SQL" без слова "LINQ". Что там собственно останется-то хорошего, если оттуда убрать запросы?
останется compile time проверки вызова стор.
J>2. Запросы компилируются и скорости перенос тех же самых запросов в хранимки не добавит. Это известный факт.
Разница огромна, при использовании линка запросы SQL генерит линк, при использовании явных запросов или стор — вы сами.
J>3. Работать с хранимками намного менее удобно, чем с кодом, по многим причинам. Т.е. хранимки будут тормозить разработку.
Работать с хранимкапми на порядок удобнее, намного проще например отлаживать план выполнения.
J>4. И самое главное: совершенное самодурство и кретинизм делать что-то потому что "я думаю что так будет быстрее". Промерить не судьба? Может у вас там где-нибудь StringBuilder поставить нужно вместо string += и все летать начнет? И переписывать ничего не нужно будет? Может быть есть только один тормозной запрос и его стоит вынуть и оптимизировать, вместо того, чтобы делать это для всех подряд? Если делается расчет на будущее — может стоит сначала написать нагрузочные тесты?
найти узкое место — это действительно надо в первую очередь.
Здравствуйте, gandjustas, Вы писали:
G> В этом конкретном случае видимно никто и не собирался залить в процедуры для оптимизации, обычно их применяют только для инкапсуляции, view в этом плане гороздо выгоднее.
Проблема в том, что можно доинкапсулироваться до полной потери производительности.
G>ИМХО нет разницы править 4 процедуры или вьюху и 3 триггера.
Править нет. А вот когда нужно понять что происходит или что-то поменять с предсказуемым результатом — процедуры рулят.
Здравствуйте, Tom, Вы писали:
S>>Как я понял, у него просто каша в голове. Посоветовали ему взять спеца по БД и с ним проконсультироваться, где у нас Bottle-neck в БД. Tom>Конечно любую оптимизацию надо начинать с поиска узкого места, но шеф ваш имхо вполне прав. Использую линк к сторам вы получите compile time проверки, что выгодно отличает этот подход от простого вызова при помощи ADO.NET
Совсем не обязательно. Мы на одном проекте использовали типизированые обертки над хранимками (свой кастом тул), внутри которого вполне себе удачно использовался ADO.NET
Здравствуйте, Jakobz, Вы писали:
J>1. LINQ to SQL, завязаный только на хранимые процедуры — это "LINQ to SQL" без слова "LINQ". Что там собственно останется-то хорошего, если оттуда убрать запросы?
+ маппиниг резалтсета хранимой процедуры на объекты.
+ tracking изменений
Здравствуйте, Jakobz, Вы писали:
J>4. И самое главное: совершенное самодурство и кретинизм делать что-то потому что "я думаю что так будет быстрее". Промерить не судьба? Может у вас там где-нибудь StringBuilder поставить нужно вместо string += и все летать начнет? И переписывать ничего не нужно будет? Может быть есть только один тормозной запрос и его стоит вынуть и оптимизировать, вместо того, чтобы делать это для всех подряд? Если делается расчет на будущее — может стоит сначала написать нагрузочные тесты?
Может я телефончик его дам, Вы ему тоже это скажете. Наша команда замудохалась объяснять ему это. Нагрузочные тесты у нас выглядят так. Берутся все программисты и начинают тыкать по кнопочкам, в это время смотрится загрузка SQL сервера.
Я тут ещё одно уточнение хочу вставить.
Проблема именно в том, что SQL сервер перестает отвечать клиентам. Т.е. считается, что он очень сильно нагружается из-за того, что ему каждый раз приходится компилить запросы. Не знаю, очивидно ли это было из предыдуших моих постов или нет. Но так, на всякий случай.
Мы уже победили, просто это еще не так заметно...
