Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое... По горячим следам...
#022<< #023
ТЕМА ДЛЯ ОБСУЖДЕНИЯ (для программистов)
Константин (cat2@onego.ru) прислал ответ на реплики форума.
Главной целью заметки "Об использовании временных таблиц в запросах" являлось привлечение широких программистских масс в обсуждение вопросов функционирования SQL-серверов.
Я бросил камень и смотрю на круги. [(с) Козьма Прутков]
Довольно снизу-вверх смотреть на то, что нам вещают Александр Гладченко и примкнувшие к нему товарищи! Эффективность работы SQL-сервера зависит от нас всех вместе - "нам не жить друг без друга". Постулат. Все DBA вышли из программистов. Вывод из постулата. DBA, читайте дальше! Мы не меньше Вас любим свои сервера и стараемся их, бедненьких, не перегружать.
Особая благодарность всем, кто прочитал заметку. А гражданам qu-qu и fompro, которые первые прорвали этот обет молчания - поощрение в приказе и фотография на фоне облаков. Хотя... Команда MS SQL от прочего Microsoft довольна отлична. Сравните интерфейс SQL 6.5 с Win95 - это делали разные люди!
Теперь, по возможности, серьезно... Подробности дискуссии об использовании временных таблиц на:
http://book.by.ru/cgi-bin/book.cgi?book=SQLServer-Forum&i=974420790
Далее Константин пишет:
Об использовании курсоров.
Чрезвычайно интересующая меня тема. Мне ни разу не понадобилось их использовать, всегда как-то выкручиваюсь. Однако мне чрезвычайно интересно, какие задачи можно более эффективно решить с их помощью. И есть ли реальные задачи, которые можно решить только с курсорами. Я придумал чисто теоретическую задачу, которую, вроде, без курсора не решить:
Таблица имеет два числовых поля. Требуется занести во второе поле среднее арифметическое первых полей из трех смежных записей: предыдущей, текущей, и следующей. Ума не приложу, где такое может понадобиться.
С наилучшими пожеланиями - Константин
Петрозаводск
Обсудить тему в форуме можно здесь:
http://book.by.ru/cgi-bin/book.cgi?book=SQLServer-Forum&i=974420790
Пока я готовил это выпуск, появилось ещё одно, на этот раз обращение Константина к посетителям форума рассылки. И опять, я готов подписаться под каждым словом Константина:
Уважаемые дамы и господа!
Если кто-то думает, что я эксперт по SQL, то он глубоко ошибается. Я, как и Вы все пробираюсь к истине методом проб и ошибок. Есть хорошая поговорка, что "Только дураки учатся на своих ошибках". Но задумайтесь. Выходит, если никто не совершил какой-либо ошибки, то никто на ней и не научится. Не стесняйтесь, признавайтесь в своих ошибках! Мне было бы чрезвычайно интересно, в чем и когда Вы ошиблись.
Для начала разговора. Мой log составляет 150Mb. Причем SQL сообщал, что свободного места осталось 2 Mb. Я, как последний идиот, решил, что если я удалю физический файл и создам log заново, то у меня все будет хорошо. Удалил. Слава тебе Господи, что перед эти я додумался сделать backup.
Присылайте, пожалуйста, свои ошибки!
Возвращаясь к поговорке, я считаю нужны добавит: "Но только мыслитель, делает свои ошибки и учится на них". Копирайт мой.
Из моей дурости следует вопрос для DBA.
Нормально ли, что при базе в 300 Mb, log составляет 120 Mb занято + 30 Mb свободно. Я, наверное, не въезжаю, но мне кажется, что после завершения всех транзакций лог должен очиститься. Или может быт SQL показывает мне последний, занятый в последней операции экстент, а все что перед ним свободно? Я ни черта не понимаю в log. Сделал я его чисто механически, по рекомендациям Рона Саукапа.
Обсудить обращение в форуме:
http://book.by.ru/cgi-bin/book.cgi?book=SQLServer-Forum&i=974507769
СОВЕТ
Эффективная фильтрация дубликатов
(По материалам статьи Neil Boyle на swynk.com "Speed up SELECT DISTINCT queries")
Нил пишет, что многие используют опцию DISTINCT в инструкции select для фильтрации дубликатов. Например, простой запрос для базы данных PUBS:
select DISTINCT
au_fname,
au_lname
from authors
В простой выборке из одной таблицы это - самый простой и быстрый способ получения результата.
Однако, для больших, комплексных запросов Вы можете применить более эффективный алгоритм. Например, следующий запрос возвращает авторов, которые уже издали книгу.
select DISTINCT
au_fname,
au_lname
from authors a join titleAuthor t
on t.au_id = a.au_id
Здесь нам нужно видеть только уникальные имена авторов, которые написали книги. Запрос будет работать, как требуется, но мы можем повысить его эффективность, если перепишем его так:
select au_fname,
au_lname
from authors a
where exists (
select *
from titleAuthor t
where t.au_id = a.au_id
)
Причина более быстрой отработки запроса в том, что предложение EXISTS возвратит имя сразу же, когда найдена первая книга, и никакие другие книги этого автора далее не будут сканироваться (мы уже получили имя автора, и это всё, что нам нужно). С другой стороны, запрос DISTINCT возвращает одну копию имени автора для, каждой его книги и продолжил бы работу, пока не обработал бы весь список и не отсёк дубликаты согласно предложению DISTINCT. Вы можете исследовать план выполнения каждого из представленных запросов, чтобы увидеть причину повышения эффективности последнего примера.
Повышение эффективности зависит от соотношения количества попаданий строк в LEFT и RIGHT (или INNER и OUTER) таблиц. Следующий запрос будет работать в любой SQL Server базе данных. Пробуйте вставить эти два запроса в Query Analyser и сравнить их планы выполнения, а именно, как соотносятся I/O этой пары запросов для различных базах данных. Второй запрос обычно будет более эффективным, хотя фактическая эффективность может меняться.
select DISTINCT o.name
from sysobjects o
join sysindexes i
on o.id = i.id
where o.type = 'U'
select o.name
from sysobjects o
where o.type = 'U'
and exists (
select 1
from sysindexes i
where o.id = i.id
)
Вы должны понять особенности объединения двух (или больше) таблиц, чтобы использовать это для эффективного выполнения. Следующие два запроса для базы данных Northwind предназначены для возврата ID заказчика, у которого установлена скидка больше чем 2 процента для любой позиции. На первый взгляд они будут вести себя так же, как в предыдущем примере (форматы запросов схожи), но полученные фактические результаты окажутся другими.
select DISTINCT customerID
from orders o
join [order details] od
on o.OrderID = od.OrderID
where discount > 0.02
select customerID from orders o
where exists (
select *
from [order details] od
where o.OrderID = od.OrderID
and discount > 0.02
)
Разница эффективности выполнения этих запросов в том, что OrderID, который определяет зависимость между двумя таблицами, не является именем заказчика. Второй запрос возвратит множество имён заказчика - одно для каждой позиции, полученной заказчиком. Пробуйте добавить столбец OrderID в список SELECT, чтобы увидеть это.
РАБОТА ДЛЯ DBA (Только пошлите английское резюме)
POSITION ID: SNTsd48 EMAIL: ddonahue@fuseglobal.com
WEB: http://www.fuseglobal.com
POSITION ID: sis.11156 EMAIL: sbaldock@sisinc.com
WEB: http://www.sisinc.com
POSITION ID: 330103 EMAIL:careers2@ragingmouse.com
WEB: http://www.ragingmouse.com
POSITION ID: eh002 EMAIL:eric.hecker@comsys.com
WEB: http://www.comsys.com
POSITION ID: SQLNT259 EMAIL: sat@iconma.com
WEB: http://www.dice.com/iconma
POSITION ID: RDC4771A EMAIL: vheimann@eclaro.com
WEB: http://networkdynamics.com
ИНФОРМАЦИЯ АВТОРА РАССЫЛКИ
Милые Дамы и уважаемые Господа!
Если Вас смущает, что последние выпуски приходят без полного набора тем, к которым Вы уже привыкли, могу Вас заверить, что это обусловлено не отсутствием материалов (с этим пока всё в порядке), а ограничениями на размер выпуска. Я для себя (ещё по весне) определил, что если написать больше 10-ти страниц в представлении MS Word, то рассылка может быть отвергнута по причине превышения минимального размера письма. Поэтому, если тема отсутствует в очередном выпуске, она обязательно (возможно) будет в следующем.
Появление же этого выпуска, обусловлено только лишь желанием поддержать затеянное в форуме рассылки обсуждение "наболевшей" для меня темы. Возможно, Константину удастся пробудить аудиторию рассылки к активному обсуждению своих и чужих проблем с MS SQL Server.
ДОСТУПНЫЕ РЕСУРСЫ РАССЫЛКИ:
СТРАНИЦА КАТАЛОГА
http://subscribe.ru/catalog/comp.soft.winsoft.sqlhelpyouself
Зеркало в Ростове-на-Дону и АРХИВ №1
http://pilgrim.rostov-na-donu.ru/sql/default.htm
Зеркало в Cанкт-Петербурге и АРХИВ №2
http://mssqlhelp.com.ru
АРХИВ на SUBSCRIBE.RU
http://subscribe.ru/archive/comp.soft.winsoft.sqlhelpyouself
СТАТИСТИКА
http://subscribe.ru/stat/comp.soft.winsoft.sqlhelpyouself
ФОРУМ
http://book.by.ru/cgi-bin/book.cgi?book=SQLServer-Forum
ТЕМА ДЛЯ ОБСУЖДЕНИЯ (для программистов)
Константин (cat2@onego.ru) прислал ответ на реплики форума.
Главной целью заметки "Об использовании временных таблиц в запросах" являлось привлечение широких программистских масс в обсуждение вопросов функционирования SQL-серверов.
Я бросил камень и смотрю на круги. [(с) Козьма Прутков]
Довольно снизу-вверх смотреть на то, что нам вещают Александр Гладченко и примкнувшие к нему товарищи! Эффективность работы SQL-сервера зависит от нас всех вместе - "нам не жить друг без друга". Постулат. Все DBA вышли из программистов. Вывод из постулата. DBA, читайте дальше! Мы не меньше Вас любим свои сервера и стараемся их, бедненьких, не перегружать.
Особая благодарность всем, кто прочитал заметку. А гражданам qu-qu и fompro, которые первые прорвали этот обет молчания - поощрение в приказе и фотография на фоне облаков. Хотя... Команда MS SQL от прочего Microsoft довольна отлична. Сравните интерфейс SQL 6.5 с Win95 - это делали разные люди!
Теперь, по возможности, серьезно... Подробности дискуссии об использовании временных таблиц на:
http://book.by.ru/cgi-bin/book.cgi?book=SQLServer-Forum&i=974420790
Далее Константин пишет:
Об использовании курсоров.
Чрезвычайно интересующая меня тема. Мне ни разу не понадобилось их использовать, всегда как-то выкручиваюсь. Однако мне чрезвычайно интересно, какие задачи можно более эффективно решить с их помощью. И есть ли реальные задачи, которые можно решить только с курсорами. Я придумал чисто теоретическую задачу, которую, вроде, без курсора не решить:
Таблица имеет два числовых поля. Требуется занести во второе поле среднее арифметическое первых полей из трех смежных записей: предыдущей, текущей, и следующей. Ума не приложу, где такое может понадобиться.
С наилучшими пожеланиями - Константин
Петрозаводск
Обсудить тему в форуме можно здесь:
http://book.by.ru/cgi-bin/book.cgi?book=SQLServer-Forum&i=974420790
Пока я готовил это выпуск, появилось ещё одно, на этот раз обращение Константина к посетителям форума рассылки. И опять, я готов подписаться под каждым словом Константина:
Уважаемые дамы и господа!
Если кто-то думает, что я эксперт по SQL, то он глубоко ошибается. Я, как и Вы все пробираюсь к истине методом проб и ошибок. Есть хорошая поговорка, что "Только дураки учатся на своих ошибках". Но задумайтесь. Выходит, если никто не совершил какой-либо ошибки, то никто на ней и не научится. Не стесняйтесь, признавайтесь в своих ошибках! Мне было бы чрезвычайно интересно, в чем и когда Вы ошиблись.
Для начала разговора. Мой log составляет 150Mb. Причем SQL сообщал, что свободного места осталось 2 Mb. Я, как последний идиот, решил, что если я удалю физический файл и создам log заново, то у меня все будет хорошо. Удалил. Слава тебе Господи, что перед эти я додумался сделать backup.
Присылайте, пожалуйста, свои ошибки!
Возвращаясь к поговорке, я считаю нужны добавит: "Но только мыслитель, делает свои ошибки и учится на них". Копирайт мой.
Из моей дурости следует вопрос для DBA.
Нормально ли, что при базе в 300 Mb, log составляет 120 Mb занято + 30 Mb свободно. Я, наверное, не въезжаю, но мне кажется, что после завершения всех транзакций лог должен очиститься. Или может быт SQL показывает мне последний, занятый в последней операции экстент, а все что перед ним свободно? Я ни черта не понимаю в log. Сделал я его чисто механически, по рекомендациям Рона Саукапа.
Обсудить обращение в форуме:
http://book.by.ru/cgi-bin/book.cgi?book=SQLServer-Forum&i=974507769
СОВЕТ
Эффективная фильтрация дубликатов
(По материалам статьи Neil Boyle на swynk.com "Speed up SELECT DISTINCT queries")
Нил пишет, что многие используют опцию DISTINCT в инструкции select для фильтрации дубликатов. Например, простой запрос для базы данных PUBS:
select DISTINCT
au_fname,
au_lname
from authors
В простой выборке из одной таблицы это - самый простой и быстрый способ получения результата.
Однако, для больших, комплексных запросов Вы можете применить более эффективный алгоритм. Например, следующий запрос возвращает авторов, которые уже издали книгу.
select DISTINCT
au_fname,
au_lname
from authors a join titleAuthor t
on t.au_id = a.au_id
Здесь нам нужно видеть только уникальные имена авторов, которые написали книги. Запрос будет работать, как требуется, но мы можем повысить его эффективность, если перепишем его так:
select au_fname,
au_lname
from authors a
where exists (
select *
from titleAuthor t
where t.au_id = a.au_id
)
Причина более быстрой отработки запроса в том, что предложение EXISTS возвратит имя сразу же, когда найдена первая книга, и никакие другие книги этого автора далее не будут сканироваться (мы уже получили имя автора, и это всё, что нам нужно). С другой стороны, запрос DISTINCT возвращает одну копию имени автора для, каждой его книги и продолжил бы работу, пока не обработал бы весь список и не отсёк дубликаты согласно предложению DISTINCT. Вы можете исследовать план выполнения каждого из представленных запросов, чтобы увидеть причину повышения эффективности последнего примера.
Повышение эффективности зависит от соотношения количества попаданий строк в LEFT и RIGHT (или INNER и OUTER) таблиц. Следующий запрос будет работать в любой SQL Server базе данных. Пробуйте вставить эти два запроса в Query Analyser и сравнить их планы выполнения, а именно, как соотносятся I/O этой пары запросов для различных базах данных. Второй запрос обычно будет более эффективным, хотя фактическая эффективность может меняться.
select DISTINCT o.name
from sysobjects o
join sysindexes i
on o.id = i.id
where o.type = 'U'
select o.name
from sysobjects o
where o.type = 'U'
and exists (
select 1
from sysindexes i
where o.id = i.id
)
Вы должны понять особенности объединения двух (или больше) таблиц, чтобы использовать это для эффективного выполнения. Следующие два запроса для базы данных Northwind предназначены для возврата ID заказчика, у которого установлена скидка больше чем 2 процента для любой позиции. На первый взгляд они будут вести себя так же, как в предыдущем примере (форматы запросов схожи), но полученные фактические результаты окажутся другими.
select DISTINCT customerID
from orders o
join [order details] od
on o.OrderID = od.OrderID
where discount > 0.02
select customerID from orders o
where exists (
select *
from [order details] od
where o.OrderID = od.OrderID
and discount > 0.02
)
Разница эффективности выполнения этих запросов в том, что OrderID, который определяет зависимость между двумя таблицами, не является именем заказчика. Второй запрос возвратит множество имён заказчика - одно для каждой позиции, полученной заказчиком. Пробуйте добавить столбец OrderID в список SELECT, чтобы увидеть это.
РАБОТА ДЛЯ DBA (Только пошлите английское резюме)
POSITION ID: SNTsd48 EMAIL: ddonahue@fuseglobal.com
WEB: http://www.fuseglobal.com
POSITION ID: sis.11156 EMAIL: sbaldock@sisinc.com
WEB: http://www.sisinc.com
POSITION ID: 330103 EMAIL:careers2@ragingmouse.com
WEB: http://www.ragingmouse.com
POSITION ID: eh002 EMAIL:eric.hecker@comsys.com
WEB: http://www.comsys.com
POSITION ID: SQLNT259 EMAIL: sat@iconma.com
WEB: http://www.dice.com/iconma
POSITION ID: RDC4771A EMAIL: vheimann@eclaro.com
WEB: http://networkdynamics.com
ИНФОРМАЦИЯ АВТОРА РАССЫЛКИ
Милые Дамы и уважаемые Господа!
Если Вас смущает, что последние выпуски приходят без полного набора тем, к которым Вы уже привыкли, могу Вас заверить, что это обусловлено не отсутствием материалов (с этим пока всё в порядке), а ограничениями на размер выпуска. Я для себя (ещё по весне) определил, что если написать больше 10-ти страниц в представлении MS Word, то рассылка может быть отвергнута по причине превышения минимального размера письма. Поэтому, если тема отсутствует в очередном выпуске, она обязательно (возможно) будет в следующем.
Появление же этого выпуска, обусловлено только лишь желанием поддержать затеянное в форуме рассылки обсуждение "наболевшей" для меня темы. Возможно, Константину удастся пробудить аудиторию рассылки к активному обсуждению своих и чужих проблем с MS SQL Server.
ДОСТУПНЫЕ РЕСУРСЫ РАССЫЛКИ:
СТРАНИЦА КАТАЛОГА
http://subscribe.ru/catalog/comp.soft.winsoft.sqlhelpyouself
Зеркало в Ростове-на-Дону и АРХИВ №1
http://pilgrim.rostov-na-donu.ru/sql/default.htm
Зеркало в Cанкт-Петербурге и АРХИВ №2
http://mssqlhelp.com.ru
АРХИВ на SUBSCRIBE.RU
http://subscribe.ru/archive/comp.soft.winsoft.sqlhelpyouself
СТАТИСТИКА
http://subscribe.ru/stat/comp.soft.winsoft.sqlhelpyouself
ФОРУМ
http://book.by.ru/cgi-bin/book.cgi?book=SQLServer-Forum
#022<< #023
Вопросы, предложения, коментарии, замечания, критику и т.п.
присылайте Александру на адрес:
MSSQLHelp@pisem.net
Хостинг рассылки:
Majordomo.ru - качественный хостинг от $9 в месяц: от 10 Мб,неограниченный трафик, от 10 РОР3, Cgi-bin, MySQL, PHP и секретный сервер, FTP & anonymous FTP, бесплатная регистрация домена,перекодировка кириллицы... http://www.majordomo.ru/hosting и самое главное - уникальное предложение : ДОМЕННОЕ ИМЯ в зоне .ru, .com, .net, .org БЕСПЛАТНО. Побробности http://www.majordomo.ru/hosting/specpr.html
Хостинг рассылки:
Majordomo.ru - качественный хостинг от $9 в месяц: от 10 Мб,неограниченный трафик, от 10 РОР3, Cgi-bin, MySQL, PHP и секретный сервер, FTP & anonymous FTP, бесплатная регистрация домена,перекодировка кириллицы... http://www.majordomo.ru/hosting и самое главное - уникальное предложение : ДОМЕННОЕ ИМЯ в зоне .ru, .com, .net, .org БЕСПЛАТНО. Побробности http://www.majordomo.ru/hosting/specpr.html
|
На рассылку подписано:
|
|
|
|
|||||||
|
http://subscribe.ru/
E-mail: ask@subscribe.ru |
| В избранное | ||
