CREATE PROC Get_Obj (@Id int)
AS
BEGIN
SELECT * FROM Objects WHERE ID_Obj = @Id
END
Запросы или хранимые процедуры? Каково ваше мнение.
Слышал, что хранимые процедуры имеют преимущество перед простыми запросами (по скорсти и тк они находятся вместе с БД как единое целое), но лично для меня простые запросы кажутся болле удобными для использования. Хочу узнать мнение других.
Что по вашему мнению лучше, чем вы предпочитаете пользоваться? Почему?
Действительно ли хранимые процедуры выполняются быстрее? Намного?
Что по вашему мнению лучше, чем вы предпочитаете пользоваться? Почему?
Действительно ли хранимые процедуры выполняются быстрее? Намного?
посмотри как работает 1С в исполении вместе с SQL Server (без ХП) и возьми нормальную прогу подобного типа (с использованием ХП) вопрос сам собой отпадет.
ЗЫ: при выполнении запроса с клиента серверу все даннные тягаются по сети
ЗЫЗЫ: При вставке данных с клиента на сервер скорость ХП и простого клиентского запроса одинаковая
ЗЫ: при выполнении запроса с клиента серверу все даннные тягаются по сети
ЗЫЗЫ: При вставке данных с клиента на сервер скорость ХП и простого клиентского запроса одинаковая
Цитата: Ordos
Слышал, что хранимые процедуры имеют преимущество перед простыми запросами (по скорсти и тк они находятся вместе с БД как единое целое), но лично для меня простые запросы кажутся болле удобными для использования. Хочу узнать мнение других.
Что по вашему мнению лучше, чем вы предпочитаете пользоваться? Почему?
Действительно ли хранимые процедуры выполняются быстрее? Намного?
Что по вашему мнению лучше, чем вы предпочитаете пользоваться? Почему?
Действительно ли хранимые процедуры выполняются быстрее? Намного?
В скорости выполнения особого выигрыша не будет. Здесь скорее вопрос архитектуры системы. Гораздо удобнее писать и поддерживать систему, когда вся логика сконцентрирована на сервере в виде хранимых процедур, а не "размазана" в виде запросов по клиентским приложениям. Кроме того здесь еще определенного рода вопросы обеспечения целостности данных и разграничения доступа к БД.
Цитата: Ora-cool
В скорости выполнения особого выигрыша не будет.
Ну извините:
1. SQL Сервак обычно на порядок мощнее клиентких машин
2. Когда клиент отправляет запрос на сервак, сначала на серваке выполняется запрос SELECT * FROM ... (без всяких WHERE) потом надо эту всю массу данных по сети перекинуть (обычно 100 Мбит), а потом уже маломощной тачкой клиета выбрать из всего этого то, что нужно (возможно я какой то шаг упустил)
3. Десяток клиентов таким макаром при больших объемах информации так "загадят" сетку и сервак что мало не покажется
ЗЫ: про 1Сэ уже упоминал
Цитата: oxotnik333
Ну извините:
1. SQL Сервак обычно на порядок мощнее клиентких машин
2. Когда клиент отправляет запрос на сервак, сначала на серваке выполняется запрос SELECT * FROM ... (без всяких WHERE) потом надо эту всю массу данных по сети перекинуть (обычно 100 Мбит), а потом уже маломощной тачкой клиета выбрать из всего этого то, что нужно (возможно я какой то шаг упустил)
3. Десяток клиентов таким макаром при больших объемах информации так "загадят" сетку и сервак что мало не покажется
ЗЫ: про 1Сэ уже упоминал
1. SQL Сервак обычно на порядок мощнее клиентких машин
2. Когда клиент отправляет запрос на сервак, сначала на серваке выполняется запрос SELECT * FROM ... (без всяких WHERE) потом надо эту всю массу данных по сети перекинуть (обычно 100 Мбит), а потом уже маломощной тачкой клиета выбрать из всего этого то, что нужно (возможно я какой то шаг упустил)
3. Десяток клиентов таким макаром при больших объемах информации так "загадят" сетку и сервак что мало не покажется
ЗЫ: про 1Сэ уже упоминал
Ну если клиенту нужен набор данных, то тут хоть через запрос, хоть через ХП - передаваться все равно будет этот набор данных. А если нужен select count(*) from..., то хоть так, хоть эдак будет передана 1 строка. Я не беру вариант, когда на клиента передается туча строк, а потом клиент своими средствами начинает искать среди них 1 строку. Это уже совсем изврат конечно.
даже select count(*) from..., будет на сервере быстрей по причине №1 и №2
Обычно работа с БД сводится к тому что бы из кучи "хлама" выбрать несколько нужных записей.
Ну если клиенту нужен набор данных, то тут хоть через запрос, хоть через ХП - передаваться все равно будет этот набор данных
Обычно работа с БД сводится к тому что бы из кучи "хлама" выбрать несколько нужных записей.
Цитата:
Ну если клиенту нужен набор данных, то тут хоть через запрос, хоть через ХП - передаваться все равно будет этот набор данных
в том то и дело что набот данных будет формировать своими мощами сервер (п.1.) и передавать не все подряд по сети, а только то что его попросили (п.2.)
Цитата: oxotnik333
даже select count(*) from..., будет на сервере быстрей по причине №1 и №2
Стоп. А вы ничего не путаете? Даже если запрос select count вызывается из клиентского приложения, то ответом будет 1 строка, а именно найденный count.
Цитата: Ora-cool
Стоп. А вы ничего не путаете? Даже если запрос select count вызывается из клиентского приложения, то ответом будет 1 строка, а именно найденный count.
ничего не путаю:
для того чтобы посчитать количество записей в таблице, клиенту надо эту таблицу получить т.е. все равно сервер примет запрос "SELECT * FROM TableName", передаст всю таблицу клиенту, а тот уже займется подсчетом
Цитата: oxotnik333
ничего не путаю:
для того чтобы посчитать количество записей в таблице, клиенту надо эту таблицу получить т.е. все равно сервер примет запрос "SELECT * FROM TableName", передаст всю таблицу клиенту, а тот уже займется подсчетом
для того чтобы посчитать количество записей в таблице, клиенту надо эту таблицу получить т.е. все равно сервер примет запрос "SELECT * FROM TableName", передаст всю таблицу клиенту, а тот уже займется подсчетом
Уууу как все запущено)
Времена файл-серверов уже давно прошло. Это тогда чтобы найти какую-либо запись, приходилось вытягивать на клиента все данные. Теперь же, если клиент просит в запросе 1 запись, то сервер ему 1 запись и вернет.
Цитата: Ora-cool
Уууу как все запущено)
Времена файл-серверов уже давно прошло. Это тогда чтобы найти какую-либо запись, приходилось вытягивать на клиента все данные. Теперь же, если клиент просит в запросе 1 запись, то сервер ему 1 запись и вернет.
Времена файл-серверов уже давно прошло. Это тогда чтобы найти какую-либо запись, приходилось вытягивать на клиента все данные. Теперь же, если клиент просит в запросе 1 запись, то сервер ему 1 запись и вернет.
если не использовать возможности SQL сервера (ХП например) то он и превращается в файл-сервер
ЗЫ: возможно по поводу select count я не прав, детально этот вопрос не изучал
Цитата: oxotnik333
если не использовать возможности SQL сервера (ХП например) то он и превращается в файл-сервер
ЗЫ: возможно по поводу select count я не прав, детально этот вопрос не изучал
ЗЫ: возможно по поводу select count я не прав, детально этот вопрос не изучал
Да, вы неправы. Возможности SQL-сервера используются всегда, при выполнении любого SQL-запроса (с клиента, с сервера - не важно). Иначе, по вашей логике получается, что клиентская программа по сути дублирует в себе движок SQL сервера. Допустим я написал запрос, в котром есть группировка, аналитика, иерархические конструкции и проч. По вашем словам получается, что сервер просто отдал набор строк клиенту, а тот сам будет группировать, строить аналитику и проч. Согласитесь, неправдоподобно.
Цитата: Ora-cool
Да, вы неправы. Возможности SQL-сервера используются всегда, при выполнении любого SQL-запроса (с клиента, с сервера - не важно). Иначе, по вашей логике получается, что клиентская программа по сути дублирует в себе движок SQL сервера. Допустим я написал запрос, в котром есть группировка, аналитика, иерархические конструкции и проч. По вашем словам получается, что сервер просто отдал набор строк клиенту, а тот сам будет группировать, строить аналитику и проч. Согласитесь, неправдоподобно.
Я делаю такие предположения, исходя из своего опыта (не большого), а именно:
Есть таблица в которой храняться видео-файлы от 20 до 200 мб. из нее мне надо получить 1 запись, так вот если я делаю запрос на клиенте, то он выполняется на порядок дольше нежели на сервере (запрос типа SELECT * FROM Objects WHERE ID_Obj = @Id)
Цитата: oxotnik333
Я делаю такие предположения, исходя из своего опыта (не большого), а именно:
Есть таблица в которой храняться видео-файлы от 20 до 200 мб. из нее мне надо получить 1 запись, так вот если я делаю запрос на клиенте, то он выполняется на порядок дольше нежели на сервере (запрос типа SELECT * FROM Objects WHERE ID_Obj = @Id)
Есть таблица в которой храняться видео-файлы от 20 до 200 мб. из нее мне надо получить 1 запись, так вот если я делаю запрос на клиенте, то он выполняется на порядок дольше нежели на сервере (запрос типа SELECT * FROM Objects WHERE ID_Obj = @Id)
Ну дык, извините, мы говорим о разных вещах. В данном случае с сервера на клиент будет передан искомый файл (1 файл), отсюда и задержка. Но при этом же не передаются ВСЕ файлы в таблице. Тоже самое было бы, если бы вы с клиента вызвали ХП, которая передавала бы тот же самый файл. По производительности ощутимой разнице бы не было.
Цитата: Ora-cool
Ну дык, извините, мы говорим о разных вещах. В данном случае с сервера на клиент будет передан искомый файл (1 файл), отсюда и задержка. Но при этом же не передаются ВСЕ файлы в таблице. Тоже самое было бы, если бы вы с клиента вызвали ХП, которая передавала бы тот же самый файл. По производительности ощутимой разнице бы не было.
было ощущение что передаются все файлы, пока не переписал этот запрос в ХП
Код:
Цитата: oxotnik333
было ощущение что передаются все файлы, пока не переписал этот запрос в ХП
Код:
CREATE PROC Get_Obj (@Id int)
AS
BEGIN
SELECT * FROM Objects WHERE ID_Obj = @Id
END
AS
BEGIN
SELECT * FROM Objects WHERE ID_Obj = @Id
END
И что при вызове с клиента ХП она выполняется гораздо быстрее чем тот же отдельный запрос?
Не верю (c) :)
Цитата: oxotnik333
ничего не путаю:
для того чтобы посчитать количество записей в таблице, клиенту надо эту таблицу получить т.е. все равно сервер примет запрос "SELECT * FROM TableName", передаст всю таблицу клиенту, а тот уже займется подсчетом
для того чтобы посчитать количество записей в таблице, клиенту надо эту таблицу получить т.е. все равно сервер примет запрос "SELECT * FROM TableName", передаст всю таблицу клиенту, а тот уже займется подсчетом
o_O ужос и кошмар. так не бывает никогда. сделайте простой эксперимент: запустите tcpdump на сервере и выполните запрос с клиента.
запрос:
Цитата:
squirl@sqdesktop:~$ echo "select count(*) from mysql.user;" | mysql -h db-dev.net.local -u root
count(*)
6
count(*)
6
результат:
http://paste.org.ru/?dhpotv
где передача всей таблицы??
Цитата:
было ощущение что передаются все файлы, пока не переписал этот запрос в ХП
ощущение это прекрасно, но вы бы лучше более глубокий анализ провели ;)
Цитата:
ощущение это прекрасно, но вы бы лучше более глубокий анализ провели
как в том анегдоте: "Извините, был напуган" ... тормозами системы, поэтому не разбираясь кинул в ХП и забыл, сделав для себя неверный вывод.
Спасибо что просветили.
Ну и вдогонку, если говорить о скорости, то выигрыш может быть в том, что в случае запроса на сервер по сети идет текст этого запроса, а при вызове ХП только имя процедуры и параметры. Но разница будет ощутима лишь при многостраничных запросах и крайне медленном канале связи.
С другой стороны, если транзакция состоит из множества запросов, пересылаемых с клиента на сервер, то, конечно, предпочтительнее использовать ХП, которая реализует всю функциональность транзакции, т.к. тогда потребуется всего 1 обращение к серверу.
Ну а по поводу архитектуры, я уже сказал в 1-м своем посте.
С другой стороны, если транзакция состоит из множества запросов, пересылаемых с клиента на сервер, то, конечно, предпочтительнее использовать ХП, которая реализует всю функциональность транзакции, т.к. тогда потребуется всего 1 обращение к серверу.
Ну а по поводу архитектуры, я уже сказал в 1-м своем посте.
Кстати, если уж полно раскрывать тему - при некоторых структурах данных ХП может отрабатывать медленнее чем запрос (если не использовать дополнительных опций при создании процедуры).
Использование в рабочей программе прямых запросов к таблицам или вьюшкам - однозначное зло :)
Использование в рабочей программе прямых запросов к таблицам или вьюшкам - однозначное зло :)
Почему я использую процедуры.
1. В самой программе код вызова процедуры по имени быстрее выполняется, нежели формирование текста запроса в объекте, реализующем доступ к SQL.
2. При создании программы куда проще написать одну строку вызова имени функции, нежели десяток строк для текста запроса.
3. Если вдруг запрос работает не так, как хочется, куда проще чуть-чуть изменить текст внутри БД, чем перекопилировать программный код.
1. В самой программе код вызова процедуры по имени быстрее выполняется, нежели формирование текста запроса в объекте, реализующем доступ к SQL.
2. При создании программы куда проще написать одну строку вызова имени функции, нежели десяток строк для текста запроса.
3. Если вдруг запрос работает не так, как хочется, куда проще чуть-чуть изменить текст внутри БД, чем перекопилировать программный код.
Цитата: oxotnik333
Ну извините:
1. SQL Сервак обычно на порядок мощнее клиентких машин
2. Когда клиент отправляет запрос на сервак, сначала на серваке выполняется запрос SELECT * FROM ... (без всяких WHERE) потом надо эту всю массу данных по сети перекинуть (обычно 100 Мбит), а потом уже маломощной тачкой клиета выбрать из всего этого то, что нужно (возможно я какой то шаг упустил)
3. Десяток клиентов таким макаром при больших объемах информации так "загадят" сетку и сервак что мало не покажется
ЗЫ: про 1Сэ уже упоминал
1. SQL Сервак обычно на порядок мощнее клиентких машин
2. Когда клиент отправляет запрос на сервак, сначала на серваке выполняется запрос SELECT * FROM ... (без всяких WHERE) потом надо эту всю массу данных по сети перекинуть (обычно 100 Мбит), а потом уже маломощной тачкой клиета выбрать из всего этого то, что нужно (возможно я какой то шаг упустил)
3. Десяток клиентов таким макаром при больших объемах информации так "загадят" сетку и сервак что мало не покажется
ЗЫ: про 1Сэ уже упоминал
Мда.. извините, но вам надо учить матчасть...
Если вы возьмете запрос SELECT * FROM TABLE и "переведете его ЯМД, то, как не странно - получите простой цикл... а WHERE - есть не что иное как проверка условия в цикле, этим оно и отличается от HAVING - условие над полученным множеством...
С точки зрения клиента,"полностью" данные передаются только в случае либо безусловного запроса, что характерно для безусловных наборов данных (в случае Delphi/Builder и т.д. это TTable). В остальных случаях передаются только выбранные (отфильтрованные) данные.
Если вы фильтруете данные на стороне клиента, тогда да – он получит весь набор и потом только отфильтрует. Не путайте эти два подхода.
Прелесть ХР в том, что они не только компилируются но/скорее в том, что в них можно реализовать достаточно сложную логику, которую не возможно реализовать в Просмотрах.
И ХП и Просмотры актуальны - только в каждом конкретном случае надо определять что выбрать... другими словами - "всё должно быть к месту".
Цитата: noi
Мда.. извините, но вам надо учить матчасть...
Если вы возьмете запрос SELECT * FROM TABLE и "переведете его ЯМД, то, как не странно - получите простой цикл... а WHERE - есть не что иное как проверка условия в цикле, этим оно и отличается от HAVING - условие над полученным множеством...
С точки зрения клиента,"полностью" данные передаются только в случае либо безусловного запроса, что характерно для безусловных наборов данных (в случае Delphi/Builder и т.д. это TTable). В остальных случаях передаются только выбранные (отфильтрованные) данные.
Если вы фильтруете данные на стороне клиента, тогда да – он получит весь набор и потом только отфильтрует. Не путайте эти два подхода.
Прелесть ХР в том, что они не только компилируются но/скорее в том, что в них можно реализовать достаточно сложную логику, которую не возможно реализовать в Просмотрах.
И ХП и Просмотры актуальны - только в каждом конкретном случае надо определять что выбрать... другими словами - "всё должно быть к месту".
Если вы возьмете запрос SELECT * FROM TABLE и "переведете его ЯМД, то, как не странно - получите простой цикл... а WHERE - есть не что иное как проверка условия в цикле, этим оно и отличается от HAVING - условие над полученным множеством...
С точки зрения клиента,"полностью" данные передаются только в случае либо безусловного запроса, что характерно для безусловных наборов данных (в случае Delphi/Builder и т.д. это TTable). В остальных случаях передаются только выбранные (отфильтрованные) данные.
Если вы фильтруете данные на стороне клиента, тогда да – он получит весь набор и потом только отфильтрует. Не путайте эти два подхода.
Прелесть ХР в том, что они не только компилируются но/скорее в том, что в них можно реализовать достаточно сложную логику, которую не возможно реализовать в Просмотрах.
И ХП и Просмотры актуальны - только в каждом конкретном случае надо определять что выбрать... другими словами - "всё должно быть к месту".
Я уже покаялся в своей некомпетентности... не надо плз опускать еще ниже.
Я для себя выводы сделал
Цитата: oxotnik333
Я уже покаялся в своей некомпетентности... не надо плз опускать еще ниже.
Я для себя выводы сделал
Я для себя выводы сделал
Извиняйте.. это я виноват - прочел 1-ю страницу и ответил... надо было все прочесть.. :( Совершено ничего личного в мыслях.. Чисто профессиональное обсуждение - но все равно, еще раз звиняйте. :)