Помогите с запросом в MS SQL Server (е)создание запроса
#5
Отправлено 18.01.2007, 16:55:21
виноват. неверно думал, что top работает до сортировки.злодей.
да, top работает после сортировки.
http://www.sql.ru/fa...ic.aspx?fid=105
Айгуль, вы часто задаёте вопросы по MSSQL, и мне кажется, что полезнее из задавать на форуме SQL.RU, нежели на ЦТ, а?
#6
Отправлено 19.01.2007, 09:44:50
Айгуля. Читайте мат часть.
select top 1 *
from Referats
будет самая первая строчка.
Спасибо.
Такой простой запрос, аж стыдно стало. А то я тут пыталась курсор создать.
Айгуля запомните - курсоры это плохо. Не надо втыкать их налево и направо, когда можно немного подумать и сделать все проще и легче. Использование последовательного механизма доступа к данным вместо реляционного в реляционных базах данных это почти как покупать самолет, чтобы кататься на нем только по рулевым дорожкам. Курсоры применимы только тогда, когда невозможно выполнить отработку по другому, или это выполнение слишком сложно.
#8
Отправлено 25.01.2007, 18:27:47
то есть хавать память наших компов и лаптопов.
Щас в меня кинут кирпичом привязаным к баяну но я скажу:
- MSSQL поворот таблицы на 90* без курсора?
- динамические таблицы с растущими колонками без курсора?
а насчет вопросов - нам не жалко, задавайте хоть тыщу вопросов, и на SQL.RU тоже
#9
Отправлено 29.01.2007, 18:38:00
фигня это все! курсоры были есть будут есть,
то есть хавать память наших компов и лаптопов.
Щас в меня кинут кирпичом привязаным к баяну но я скажу:
- MSSQL поворот таблицы на 90* без курсора?
- динамические таблицы с растущими колонками без курсора?
а насчет вопросов - нам не жалко, задавайте хоть тыщу вопросов, и на SQL.RU тоже
Мусье, вы внимательно читали мой предыдущий пост? Я что говорил что повешайтесь, но курсор не используйте, разве так? Но это не повод городить курсоры везде, где только можно
На счет баян-кирпич, я считаю, что подумав, ваши задачи можно решить без использования курсоров. Хотя и не совсем изящно. Если есть желание - конкретизируйте задачу, я на досуге постараюсь найти решение.
#10
Отправлено 06.02.2007, 15:30:29
Интересно, почему это курсоры - это плохо. Я давно пишу запросы и раньше так и думал. Порой составлял супер запросы, от которых у самого голова кругом шла. Потом мне приходилось вносить исправления (добавлять новый функционал или изменять существующий) и я начал встревать. Во-первых: приходилось вспоминать и/или изучать супер запрос, и, во-вторых, придумывать как его изменить.Айгуля запомните - курсоры это плохо. Не надо втыкать их налево и направо, когда можно немного подумать и сделать все проще и легче. Использование последовательного механизма доступа к данным вместо реляционного в реляционных базах данных это почти как покупать самолет, чтобы кататься на нем только по рулевым дорожкам. Курсоры применимы только тогда, когда невозможно выполнить отработку по другому, или это выполнение слишком сложно.
А потом я стал использовать курсоры... и сразу стало легче дышаться. Они легко корректируемые, понятные. К тому же не надо долго думать, как сделать то или другое.
Так что курсоры - это рулез, особенно в большых и сложных запросах.
Сообщение отредактировал pompei2: 06.02.2007, 15:31:49
#11
Отправлено 07.02.2007, 12:28:55
Интересно, почему это курсоры - это плохо. Я давно пишу запросы и раньше так и думал. Порой составлял супер запросы, от которых у самого голова кругом шла. Потом мне приходилось вносить исправления (добавлять новый функционал или изменять существующий) и я начал встревать. Во-первых: приходилось вспоминать и/или изучать супер запрос, и, во-вторых, придумывать как его изменить.
А потом я стал использовать курсоры... и сразу стало легче дышаться. Они легко корректируемые, понятные. К тому же не надо долго думать, как сделать то или другое.
Так что курсоры - это рулез, особенно в большых и сложных запросах.
Потому-что использование последовательного достпа к данным, вместо использования реляционных механизмов - есть тормоза.
Если у вас не очень большие базы, а следовательно не очень большие таблицы, в том числе, задачи использующие курсоры выполняются редко и малым количеством пользователей, то для облегчения реализации, курсоры ещё более-менее применимы. В случаях достаточно больших и сложных систем, курсоры превращаются в бутылочное горлышко в плане производительности и загрузки сервера. Под достаточно большой системой я поимаю суммарный объем оператиных баз данных порядка 20-25 гектар и порядка 500 одновременных подключений.
Кста в качестве примера можете взять табличку, скажем тысяч в 50 записей и перелить её в другую табличку простым инсертом и через курсор. Сразу сказать кто победит?
По поводу мега-супер запроса - сам такие не люблю, и стараюсь не городить. Кстати, часто оказыватся, что разбив большой запрос на ряд более простых, не только упрощаешь понимание логики, но и существенно уменьшаешь суммарную стоимость отработки.
В общем учите мат часть. Изучайте анализ планов выполнения и да поможет вам BOL!
#12
Отправлено 07.02.2007, 12:54:38
Кста, весьма полезная книга, рекомендую как настольную для любого девелопера по SQL Server.
The best practice
Avoid cursors like the plague. If a set−level solution is not readily evident, don't be ashamed to ask for help,
whether it be from a colleague or through a posting in the Usenet newsgroups.
Use server−side cursors rather than client−side cursors wherever possible. The former does all its work on the
server and then sends the results back to the client. The latter caches all of the rows on the client and then
manipulates them there. This puts an unnecessary strain on network resources.
In the same vein, put all of your cursor code into a stored procedure and send only the results back to the
client. You should never be issuing FETCH statements across your network.
Use common sense. If you need all of the rows anyway, then use set−level SQL and do all of your fancy
manipulation on the client. Using a server−side cursor in this case is wasteful.
Wherever possible, limit the number of rows you will be manipulating via your cursor. The more work your
cursor has to do, the longer things will take.
Limit your locks to the minimum that you need to accomplish your task.
When all else fails, use a cursor. Just make sure that all else has indeed failed before you do.
#13
Отправлено 07.02.2007, 15:32:58
Сравнение Инсерта и курсора - некорректное.
Разные вещи: например курсор можно остановить на середине, потом продолжить. а инсерт Rollback-нется.
#14
Отправлено 07.02.2007, 16:58:46
Время потраченное на отладку и оптимизацию запроса (время программиста), стоит как правило на несколько порядков дешевле, чем потери бизнеса, связанные с недостаточной производительностью ПО. Не так ли? В данном случае я имею в виду промышленные базы данных, а не базу студентов в политехе.Хотелось бы отметить что в настоящее время "стоимость запроса" - это не все. Добавьте туда время потраченное на отладку запроса и его оптимизацию которое существенно увеличивается при больших базах и сложных многоэтапных запросах.
Собственно большая база как правило всегда дороже в обслуживании чем маленькая, это практически аксиома, так что...
Стоимость запроса для критичного для бизнеса процесса по производительности - это всё
Сравнение Инсерта и курсора - некорректное.
Разные вещи: например курсор можно остановить на середине, потом продолжить. а инсерт Rollback-нется.
Согласен, зато очень ярко показывает отличия. Кста останов курсора на середине, при недостаточно правильной реализации порой приводит к блокировке, которая ставит раком остальных пользователей, за что они как правило ставят раком программера. Так что порой выгодней откатится и сделать все снова, чем постоять, покурить, подумать и продолжить.
#15
Отправлено 07.02.2007, 18:33:31
вы сами ответили на вопрос - для процесса да, для бизнеса нет.
по поводу второго, я просто не запускаю курсор на 50000 записей.
а проблема с блокировками это кривые руки. лечится как и все остальное.
И все таки мне было бы интересно узнать хороший алоритм работы для поворота на 90:
давайте представим:
Существует таблица "T" c колонками a,b,c...z в которой 1я колонка это название будущего столбца (например aa,bb..zz) , Кол-во записей меняется и тогда таблица конструируется заново.
давайте сделаем из нее таблицу с колонками aa,bb...zz
#18
Отправлено 08.02.2007, 21:34:23
#20
Отправлено 09.02.2007, 09:52:31
Я не силен в MS SQL, точнее совсем профан, может он и позволяет написать такой запрос.
Например в Oracle можно извратиться и через ж написать иерархический запрос, который, впрочем будет медленнее, чем решение на основе функции, можно извратиться с помощью xml.
Но что-то мне не приходит в голову решение на основе ANSI SQL.
Количество пользователей, читающих эту тему: 1
пользователей: 0, неизвестных прохожих: 1, скрытых пользователей: 0