Перейти к содержимому

Фотография

Помогите с запросом в MS SQL Server (е)создание запроса


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 28

#1
Demidova Aigul

Demidova Aigul
  • Свой человек
  • 502 сообщений
Помогите, пожалуйста. :smoke: Мне нужно с помощью запроса вытащить из таблицы (например, таблица "Referats") именно первую строку.
  • 0

#2
ZAB

ZAB
  • Гость
  • 38 сообщений
Айгуля. Читайте мат часть.

select top 1 *
from Referats

будет самая первая строчка. :smoke:
  • 0

#3
yedyge

yedyge
  • Свой человек
  • 879 сообщений
злодей.
  • 0

#4
Demidova Aigul

Demidova Aigul
  • Свой человек
  • 502 сообщений

Айгуля. Читайте мат часть.

select top 1 *
from Referats

будет самая первая строчка.


Спасибо. :laugh:
Такой простой запрос, аж стыдно стало. :smoke: А то я тут пыталась курсор создать. :laugh:
  • 0

#5
yedyge

yedyge
  • Свой человек
  • 879 сообщений

злодей.

виноват. неверно думал, что top работает до сортировки.
да, top работает после сортировки.

http://www.sql.ru/fa...ic.aspx?fid=105

Айгуль, вы часто задаёте вопросы по MSSQL, и мне кажется, что полезнее из задавать на форуме SQL.RU, нежели на ЦТ, а?
  • 0

#6
DuneWarrior

DuneWarrior
  • Свой человек
  • 907 сообщений

Айгуля. Читайте мат часть.

select top 1 *
from Referats

будет самая первая строчка.


Спасибо. :D
Такой простой запрос, аж стыдно стало. :rolleyes: А то я тут пыталась курсор создать. :D


Айгуля запомните - курсоры это плохо. Не надо втыкать их налево и направо, когда можно немного подумать и сделать все проще и легче. Использование последовательного механизма доступа к данным вместо реляционного в реляционных базах данных это почти как покупать самолет, чтобы кататься на нем только по рулевым дорожкам. Курсоры применимы только тогда, когда невозможно выполнить отработку по другому, или это выполнение слишком сложно.
  • 0

#7
Demidova Aigul

Demidova Aigul
  • Свой человек
  • 502 сообщений
Всем спасибо за советы. :mad:
  • 0

#8
Napoleon

Napoleon
  • Свой человек
  • 669 сообщений
фигня это все! курсоры были есть будут есть,
то есть хавать память наших компов и лаптопов.

Щас в меня кинут кирпичом привязаным к баяну но я скажу:
- MSSQL поворот таблицы на 90* без курсора?
- динамические таблицы с растущими колонками без курсора?

а насчет вопросов - нам не жалко, задавайте хоть тыщу вопросов, и на SQL.RU тоже
  • 0

#9
DuneWarrior

DuneWarrior
  • Свой человек
  • 907 сообщений

фигня это все! курсоры были есть будут есть,
то есть хавать память наших компов и лаптопов.

Щас в меня кинут кирпичом привязаным к баяну но я скажу:
- MSSQL поворот таблицы на 90* без курсора?
- динамические таблицы с растущими колонками без курсора?

а насчет вопросов - нам не жалко, задавайте хоть тыщу вопросов, и на SQL.RU тоже


Мусье, вы внимательно читали мой предыдущий пост? Я что говорил что повешайтесь, но курсор не используйте, разве так? Но это не повод городить курсоры везде, где только можно :rolleyes:
На счет баян-кирпич, я считаю, что подумав, ваши задачи можно решить без использования курсоров. Хотя и не совсем изящно. Если есть желание - конкретизируйте задачу, я на досуге постараюсь найти решение.
  • 0

#10
pompei2

pompei2
  • Завсегдатай
  • 179 сообщений

Айгуля запомните - курсоры это плохо. Не надо втыкать их налево и направо, когда можно немного подумать и сделать все проще и легче. Использование последовательного механизма доступа к данным вместо реляционного в реляционных базах данных это почти как покупать самолет, чтобы кататься на нем только по рулевым дорожкам. Курсоры применимы только тогда, когда невозможно выполнить отработку по другому, или это выполнение слишком сложно.

Интересно, почему это курсоры - это плохо. Я давно пишу запросы и раньше так и думал. Порой составлял супер запросы, от которых у самого голова кругом шла. Потом мне приходилось вносить исправления (добавлять новый функционал или изменять существующий) и я начал встревать. Во-первых: приходилось вспоминать и/или изучать супер запрос, и, во-вторых, придумывать как его изменить.

А потом я стал использовать курсоры... и сразу стало легче дышаться. Они легко корректируемые, понятные. К тому же не надо долго думать, как сделать то или другое.

Так что курсоры - это рулез, особенно в большых и сложных запросах.

Сообщение отредактировал pompei2: 06.02.2007, 15:31:49

  • 0

#11
DuneWarrior

DuneWarrior
  • Свой человек
  • 907 сообщений

Интересно, почему это курсоры - это плохо. Я давно пишу запросы и раньше так и думал. Порой составлял супер запросы, от которых у самого голова кругом шла. Потом мне приходилось вносить исправления (добавлять новый функционал или изменять существующий) и я начал встревать. Во-первых: приходилось вспоминать и/или изучать супер запрос, и, во-вторых, придумывать как его изменить.

А потом я стал использовать курсоры... и сразу стало легче дышаться. Они легко корректируемые, понятные. К тому же не надо долго думать, как сделать то или другое.

Так что курсоры - это рулез, особенно в большых и сложных запросах.


Потому-что использование последовательного достпа к данным, вместо использования реляционных механизмов - есть тормоза.
Если у вас не очень большие базы, а следовательно не очень большие таблицы, в том числе, задачи использующие курсоры выполняются редко и малым количеством пользователей, то для облегчения реализации, курсоры ещё более-менее применимы. В случаях достаточно больших и сложных систем, курсоры превращаются в бутылочное горлышко в плане производительности и загрузки сервера. Под достаточно большой системой я поимаю суммарный объем оператиных баз данных порядка 20-25 гектар и порядка 500 одновременных подключений.

Кста в качестве примера можете взять табличку, скажем тысяч в 50 записей и перелить её в другую табличку простым инсертом и через курсор. Сразу сказать кто победит? :rolleyes:

По поводу мега-супер запроса - сам такие не люблю, и стараюсь не городить. Кстати, часто оказыватся, что разбив большой запрос на ряд более простых, не только упрощаешь понимание логики, но и существенно уменьшаешь суммарную стоимость отработки.
В общем учите мат часть. Изучайте анализ планов выполнения и да поможет вам BOL! :)
  • 0

#12
DuneWarrior

DuneWarrior
  • Свой человек
  • 907 сообщений
Вот выдержка из книги Advanced Transact−SQL for SQL Server 2000 Copyright © 2000 by Itzik Ben−Gan and Tom Moreau

Кста, весьма полезная книга, рекомендую как настольную для любого девелопера по 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.
  • 0

#13
Napoleon

Napoleon
  • Свой человек
  • 669 сообщений
Хотелось бы отметить что в настоящее время "стоимость запроса" - это не все. Добавьте туда время потраченное на отладку запроса и его оптимизацию которое существенно увеличивается при больших базах и сложных многоэтапных запросах.

Сравнение Инсерта и курсора - некорректное.
Разные вещи: например курсор можно остановить на середине, потом продолжить. а инсерт Rollback-нется.
  • 0

#14
DuneWarrior

DuneWarrior
  • Свой человек
  • 907 сообщений

Хотелось бы отметить что в настоящее время "стоимость запроса" - это не все. Добавьте туда время потраченное на отладку запроса и его оптимизацию которое существенно увеличивается при больших базах и сложных многоэтапных запросах.

Время потраченное на отладку и оптимизацию запроса (время программиста), стоит как правило на несколько порядков дешевле, чем потери бизнеса, связанные с недостаточной производительностью ПО. Не так ли? В данном случае я имею в виду промышленные базы данных, а не базу студентов в политехе. :cool:
Собственно большая база как правило всегда дороже в обслуживании чем маленькая, это практически аксиома, так что...
Стоимость запроса для критичного для бизнеса процесса по производительности - это всё :-)

Сравнение Инсерта и курсора - некорректное.
Разные вещи: например курсор можно остановить на середине, потом продолжить. а инсерт Rollback-нется.


Согласен, зато очень ярко показывает отличия. Кста останов курсора на середине, при недостаточно правильной реализации порой приводит к блокировке, которая ставит раком остальных пользователей, за что они как правило ставят раком программера. Так что порой выгодней откатится и сделать все снова, чем постоять, покурить, подумать и продолжить. :-)
  • 0

#15
Napoleon

Napoleon
  • Свой человек
  • 669 сообщений

вы сами ответили на вопрос - для процесса да, для бизнеса нет.

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

И все таки мне было бы интересно узнать хороший алоритм работы для поворота на 90:
давайте представим:
Существует таблица "T" c колонками a,b,c...z в которой 1я колонка это название будущего столбца (например aa,bb..zz) , Кол-во записей меняется и тогда таблица конструируется заново.

давайте сделаем из нее таблицу с колонками aa,bb...zz
  • 0

#16
Pooh

Pooh
  • В доску свой
  • 1 898 сообщений

И все таки мне было бы интересно узнать хороший алоритм работы для поворота на 90

А в каких реальных ситуациях это нужно? Ради интереса, приведите пожалуйста пример.
  • 0

#17
Need A Light

Need A Light
  • В доску свой
  • 1 760 сообщений
Pooh, например, один из вырожденных случаев поворота - получить значения некоторого поля таблицы в одну строку(т.е из столбца получить строку).
  • 0

#18
Pooh

Pooh
  • В доску свой
  • 1 898 сообщений
Need A Light, ваш пример с одним полем это просто денормализация таблицы, решается с помощью "self join" довольно просто. Встречается довольно часто. Но это не поворот на 90 нескольких полей или всей таблицы. Я всё никак не могу придумать реальную бизнес ситуацию с такими условиями.
  • 0

#19
Need A Light

Need A Light
  • В доску свой
  • 1 760 сообщений

Need A Light, ваш пример с одним полем это просто денормализация таблицы, решается с помощью "self join" довольно просто. Встречается довольно часто.

Приведете общий пример?
  • 0

#20
Need A Light

Need A Light
  • В доску свой
  • 1 760 сообщений
Понятное дело, для неизвестного количества записей.
Я не силен в MS SQL, точнее совсем профан, может он и позволяет написать такой запрос.
Например в Oracle можно извратиться и через ж написать иерархический запрос, который, впрочем будет медленнее, чем решение на основе функции, можно извратиться с помощью xml.
Но что-то мне не приходит в голову решение на основе ANSI SQL.
  • 0


Количество пользователей, читающих эту тему: 1

пользователей: 0, неизвестных прохожих: 1, скрытых пользователей: 0

Размещение рекламы на сайте     Предложения о сотрудничестве     Служба поддержки пользователей

© 2011-2022 vse.kz. При любом использовании материалов Форума ссылка на vse.kz обязательна.