ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Рушится вера в
25 сообщений из 35, страница 1 из 2
  1  все
Рушится вера в
    #32047182
qu-qu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qu-qu
Участник
Делаю тестовую процедурку...
Цель: заполнить значениями в произвольном порядке одну таблицу, и перегрузить из нее данные в другую, но уже с определенным порядком сортировки.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
create proc #test_proc
as
set nocount on
declare @curr_date datetime select @curr_date = getdate()
create table #t1 (f0 datetime, f1 int)
insert into #t1
select dateadd(dd,-  1 , @curr_date),  3 
insert into #t1
select dateadd(dd,-  2 , @curr_date),  2 
insert into #t1
select dateadd(dd,-  3 , @curr_date),  4 
insert into #t1
select dateadd(dd,-  4 , @curr_date),  4 
insert into #t1
select dateadd(dd,-  1 , @curr_date),  1 

select * from #t1
select * into #t2 from #t1
select * from #t2
truncate table #t2
insert into #t2 select * from #t1 order by f1,f0
select * from #t2
truncate table #t2
insert into #t2 select * from #t1 order by f0,f1
select * from #t2
go

select @@version

exec #test_proc


Получаю результат (ожидаемый):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
 ------------------------------------------------------------------------------------------------------------------------- 
 
Microsoft SQL Server   6 . 50  -  6 . 50 . 479  (Intel X86) 
	Jun  14   2000   16 : 12 : 29  
	Copyright (c)  1988 - 1997  Microsoft Corporation


f0                          f1          
 --------------------------- ----------- 
 
 2002 - 08 - 29   15 : 02 : 45 . 743       3 
 2002 - 08 - 28   15 : 02 : 45 . 743       2 
 2002 - 08 - 27   15 : 02 : 45 . 743       4 
 2002 - 08 - 26   15 : 02 : 45 . 743       4 
 2002 - 08 - 29   15 : 02 : 45 . 743       1 

f0                          f1          
 --------------------------- ----------- 
 
 2002 - 08 - 29   15 : 02 : 45 . 743       3 
 2002 - 08 - 28   15 : 02 : 45 . 743       2 
 2002 - 08 - 27   15 : 02 : 45 . 743       4 
 2002 - 08 - 26   15 : 02 : 45 . 743       4 
 2002 - 08 - 29   15 : 02 : 45 . 743       1 

f0                          f1          
 --------------------------- ----------- 
 
 2002 - 08 - 29   15 : 02 : 45 . 743       1 
 2002 - 08 - 28   15 : 02 : 45 . 743       2 
 2002 - 08 - 29   15 : 02 : 45 . 743       3 
 2002 - 08 - 26   15 : 02 : 45 . 743       4 
 2002 - 08 - 27   15 : 02 : 45 . 743       4 

f0                          f1          
 --------------------------- ----------- 
 
 2002 - 08 - 26   15 : 02 : 45 . 743       4 
 2002 - 08 - 27   15 : 02 : 45 . 743       4 
 2002 - 08 - 28   15 : 02 : 45 . 743       2 
 2002 - 08 - 29   15 : 02 : 45 . 743       1 
 2002 - 08 - 29   15 : 02 : 45 . 743       3


Вера начинает рушиться когда ТЕ ЖЕ САМЫЕ конструкции в реальной "боевой" процедуре, которая работает с реальными данными приложения - возвращают данные с абсолютно "абстрактным" порядком сортировки (не имеющим отношения ни к дате, ни к номеру).

Что бы это значило?
Может кто-нибудь уже сталкивался с такими "глюками" в конструкциях типа:
Код: plaintext
 select * into #table2 from #table1 order by ....
...
Рейтинг: 0 / 0
30.08.2002, 15:10:23
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047190
Фотография MarchCat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MarchCat
Участник
Скорее всего, стоит order by 2, 4
А в реальном селекте имена - name, spis_dat
Проверь соответствие.
...
Рейтинг: 0 / 0
30.08.2002, 15:24:06
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047191
Tulkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Tulkin
Участник
Я думаю, что SQL совсем не обязан в селекте сортировать данные,если ему этого не сказали. Ну было у него пол-таблицы в кэше. он мог сначалы их и выдать, а потов вторую половину - с диска.(утрированно)
...
Рейтинг: 0 / 0
30.08.2002, 15:27:54
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047196
Автор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автор
Гость
В таблице есть индексы ?
...
Рейтинг: 0 / 0
30.08.2002, 15:36:09
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047204
Фотография ziktuw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ziktuw
Участник
"Рушится вера в " ... в собственное представление, как должен работать MSSQL. И вобщем, правильно. Он работает не так, и не должен.
Единственный документированый способ получить отсортированый набор данных - это ORDER BY в селекте. Остальное - от лукавого.
...
Рейтинг: 0 / 0
30.08.2002, 15:48:07
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047251
qu-qu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qu-qu
Участник
2 MarchCat
... Скорее всего, стоит order by 2, 4
А в реальном селекте имена - name, spis_dat...

Откуда такая уверенность в том - что у меня стоит в "реальном селекте"?
Ты что - ясновидец?
Я же ясно написал - точно такая же конструкция (естественно - имена таблиц и полей - другие, но это именно не номера столбцов, а их имена).

2 Tulkin
... Я думаю, что SQL совсем не обязан в селекте сортировать данные,если ему этого не сказали...

Как ты считаешь - "insert into #t2 select * from #t1 order by f0, f1" - это "не сказали", или "сказали" сортировать?

... Ну было у него пол-таблицы в кэше. он мог сначалы их и выдать, а потов вторую половину - с диска.(утрированно)...

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

2 Member
... В таблице есть индексы ?...

Изначально - не было. Когда я наткнулся на этот "затык" - сделал парочку временных индексов (на поля сортировки в исходной таблице и в целевой). Эффект - нулевой, что с индексами, что без - поведение одинаково "безобразное".

2 Dankov
... Единственный документированый способ получить отсортированый набор данных - это ORDER BY в селекте...

См. выше (ответ 2 Tulkin ) - если я пишу ORDER BY в селекте, который стоит после инсерта - это что - повод его не выполнять? Или - выполнять избирательно?
(если ты внимательно вглядишься в текст и результаты приведенного выше примера - увидишь, что там директива ORDER BY исполняется очень даже правильно (и по первому полю, и по второму), какой же тогда смысл - не исполнять ее в других процедурах на других таблицах?)
...
Рейтинг: 0 / 0
30.08.2002, 18:11:43
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047252
GreenSunrise
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GreenSunrise
Участник
qu-qu, тот order by, который стоит в селекте select * from #t1, выполняется. Но в select * from #t2 ты же order by не ставишь. Да плевать на то, что в таблицу ты вставил ОТСОРТИРОВАННЫЕ записи. Выборку из нее ты делаешь БЕЗ СОРТИРОВКИ. Что тебе и пытаются объяснить.
...
Рейтинг: 0 / 0
30.08.2002, 18:27:58
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047265
SergCat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergCat
Гость
У меня была похожая ситуация. Только данные в таблицу вставлялись на основе сложной выборки с вложенными селектами.
И, теоретически, данные должны были вставлятся во временную таблицу в порядке, определенном order by. На самом же деле этого не происходило.
На этом форуме уже звучала следующая мысль, которая на практике работает в 2000-м sql:
1. Для определения точного следования записей во временной таблице надо использовать primary key
2. В переменной типа "таблица" записи следуют в порядке их добавления.
(на самом деле никто не несет ответственности, что это будет работать в Yukon и т.д.)
Советы:
1. Создать для #t2 primary key
2. Вместо #t2 использовать @t2.
...
Рейтинг: 0 / 0
30.08.2002, 20:55:11
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047271
Фотография MiCe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MiCe
Участник
доблю что кластерный индекс....
...
Рейтинг: 0 / 0
30.08.2002, 21:55:30
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047303
SergCat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergCat
Гость
Вероятно "доблю" означает "добавлю" :-)
Совершенно верно. Суть не в primary key, а в создании кластерного индекса.
...
Рейтинг: 0 / 0
31.08.2002, 16:49:32
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047306
Фотография MiCe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MiCe
Участник
угу... очяпятылси......
...
Рейтинг: 0 / 0
31.08.2002, 17:32:49
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047307
Tulkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Tulkin
Участник
а если еще точнее, то в физическом расположении данных, когда для оптимизатора запросов получение отсортированных данных и получение неотсортированных данных с максимальной производительностью будет означать одно и тоже.
...
Рейтинг: 0 / 0
31.08.2002, 17:34:41
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047309
Фотография MiCe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MiCe
Участник
а вот физичекое размещение ни кто не гарантирует....
логическое это да .... физически экстэнты могут быть фрагментированы....
...
Рейтинг: 0 / 0
31.08.2002, 17:39:06
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047312
Tulkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Tulkin
Участник
ну блин че к словам цепляться. понял ведь че я имел ввиду :-)
...
Рейтинг: 0 / 0
31.08.2002, 18:38:52
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047315
Фотография MiCe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MiCe
Участник
сори.... если что.....
просто уточнил - для правильного понимания.....
...
Рейтинг: 0 / 0
31.08.2002, 22:38:08
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047321
qu-qu(дома)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qu-qu(дома)
Гость
Для начала - цитата:
    " - Очень сожалею, но Ваш друг умер. У него 2 часа ночи произошло кровоизлияние в мозг.
     - Че... че ты гонишь?! Какое "кровоизлияние"?! В КАКОЙ МОЗГ??!! " (© "Агент национальной безопасности")

Вот во что у меня точно скоро вся вера порушится, так это в то, что в этом форуме "выступают" нормальные разумные люди...

Словей-то умных все понавыучивали: "оптимизатор", "экстенты", "производительность", "физическое размещение"...
А кто-нибудь из "советчиков" обратил внимание на результат запроса select @@version
 из моего примера? А мне приходится работать именно с такой версией, без всяких "экстентов", и с совершенно другим "оптимизатором", и "физическое размещение" в нем - тоже совсем другое.

Единственный человек высказался "по делу" ( SergCat , спасибо) т.к. сталкивался с подобной проблемой именно в деле, да и то - primary key с clustered index попутал... Ну это как раз ничего - все ошибаются, если это нормальные люди.

А вот остальные - что делали в этом топике? Доказывали непонятно кому и непонятно зачем - собственное превосходство в понимании синтаксиса T-SQL? И до чего же в итоге "договорились"?
Оказывается - поскольку "физическое размещение" записей никем и ничем не гарантируется (даже в "Юконе", о-о-о-о, Великий "Юкон", прости меня грешного, что вспомнил Твое Имя всуе...), то select без order by - будет возвращать записи в каком угодно порядке, от раза к разу все более причудливом (наверное специально, чтобы скучно не было - "получать 25 000 одинаковых наборов на 25 000 одинаковых запросов - что за фигня такая?").

Вам самим-то с себя - не смешно?
Или кто-нибудь хоть 1 из вас всех когда-нибудь хоть 1 раз в жизни слышал о том (не приведи "Юкон" - видел своими глазами), что запрос select без order by - возвращал записи в разном порядке от запуска к запуску?

Я ведь не спрашивал о том, почему мои записи выводятся из целевой таблицы не в том порядке? Я спрашивал - почему они попадают в целевую таблицу не в том порядке, хотя в команде insert ясно сказано в каком порядке они туда должны попадать.

А если кто-то еще сомневается в том, что select без order by к временной таблице из 100 строчек возвращает записи в порядке их "физического размещения" - готовьтесь просматривать тут логи выполнения DBCC TRACEON (только флаги подходящие найду в и-нете, т.к. являюсь нормальным человеком и не в состоянии все на свете знать и помнить наизусть).
...
Рейтинг: 0 / 0
01.09.2002, 00:08:26
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047332
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
>Или кто-нибудь хоть 1 из вас всех когда-нибудь хоть 1
>раз в жизни слышал о том (не приведи "Юкон" - видел
>своими глазами), что запрос select без order by -
>возвращал записи в разном порядке от запуска к запуску?

Видел. И неонократно.
Никто не гарантирует порядок выборки если не указано условие сортировки.

Пример навскидку:
SomeTable - таблица с кластерным индексом

select * from SomeTable
go
select * from SomeTable
go

Предположим, что сервер свежезапущенный, кэш данных пустой.

при первой выборке выбираются данные из таблицы в порядке кластерного индекса, ПРЕДПОЛОЖИТЕЛЬНО, с 1-й страницы. По ходу дела часть данных кэшируется.
При второй выборке последняя страница уже лежит в кэше, она и будет (СКОРЕЕ ВСЕГО) выдана первой, т.к. не указано условие сортировки.
SQL SERVER предпочитает не делать лишней работы.
При более сложных выборках результат может быть еще непредсказуемее, т.к. порядок выдачи результат будет зависит от того, сколько каких данных из каких таблиц скеэшировано, от порядка соединения, индексов и т.д.
А собственно, сортировать данные, когда этого не просят, никто и не обещал. уж больно накладная и никому не нужная(в данном случае) операция.
...
Рейтинг: 0 / 0
01.09.2002, 15:00:04
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047342
qu-qu(дома)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qu-qu(дома)
Гость
"Ну вы, блин, даете..." (© Генерал Иволгин)

Еще одному апологету Всепоглощающего Кэша и Всепроникающего Оптимизатора - неймется высказаться:

Пример навскидку:
SomeTable - таблица с кластерным индексом

select * from SomeTable
go
select * from SomeTable
go

Предположим, что сервер свежезапущенный, кэш данных пустой.

Вот беру я у себя дома сервер свежезапущенный , пишу ему в базу pubs:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
set nocount on
create table SomeTable (i int not null, c varchar( 8000 ) null)
create clustered index SomeIndex on SomeTable (i)
declare @counter int
set  @counter =  25000 
while @counter >  0 
begin 
	insert into SomeTable (i,c) select @counter, ''
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
		+ convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid()) + convert(varchar( 36 ), newid())
	set @counter = @counter -  1 
	if (select @counter %  1000 ) =  0  print @counter
end


Через 40 сек. - у меня таблица с 25 000 записей, где каждая запись ровно на пол-страницы данных, или можно считать по другому - на каждой странице данных по 2 записи из таблицы.

Перегружаюсь... (полностью с операционкой, чтобы быть уверенным, что кэш данных пустой ).
Спрашиваю у него:
Код: plaintext
1.
2.
3.
 select * from SomeTable
go
 select * from SomeTable
go


3 раза спрашиваю... каждый "спрос" - целых 3.5 мин. обрабатывается... ну ничего - я терпеливый... (чаек пью в перерывах, курю, телик смотрю). Результат - ожидаемый: все записи в обоих наборах данных - выводятся строго в порядке кластерного индекса.

Ладно, надоедает мне "спрашивать" просто так... открываю другое окошко в QA - и начинаю в другом окошке спрашивать другое, а именно:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
set nocount on
declare @counter int, @i int, @c varchar( 8000 )
set  @counter =  100000 
while @counter >  0 
begin 
	select @i = max(i), @c = min(c) from SomeTable where i between  11000  and  11010 
	set @counter = @counter -  1 
	if (select @counter %  5000 ) =  0  print @counter
end


Смотрю как цифирки бегут в окошке вывода (текстовый режим выбрал специально), радуюсь, что уж тут-то мой умненький сервачок закеширует эти несчастные 5 страниц данных, которые его заставляют 100 000 раз находить и 100 000 раз анализировать на минимум текстового поля и максимум числового...

А в другом окошке - предыдущие 2 селекта "сандалят" вовсю... данные гонят... Но что-то помедленнее они стали их выдавать "на гора" после того, как я параллельно 100 000 раз совсем про другое начал сервачок спрашивать...
Ну ничего, я терпеливый... Пока окончания нужных мне селектов не видно - я снова и снова запускаю 100 000-ный вопрос... (скажу честно - пока дождался 12 раз успел запустить, а записи из 2-х селектов как выводились в порядке кластерного индекса - так и выводятся).

Что же это получается? Сервер честно в одном процессе МИЛЛИОН(!!) раз опрашивал одни и те же 5 страниц данных, а в другом процессе - НИ РАЗУ не выдал эти 5 страниц раньше, чем 5 500 страниц из начала таблицы, про которые ему давно следовало бы "забыть" нахрен, т.к. после них он еще считывал 7 495 страниц из конца таблицы.

Что-то здесь не так, не то с "кешированием", не то с "оптимизацией", и что самое интересное - никаких ПРЕДПОЛОЖИТЕЛЬНО и СКОРЕЕ ВСЕГО не наблюдается...
Все предельно ясно и определенно.

Так что с примерчиками - поосторожнее в следующий раз... (их ведь, и проверить можно).
...
Рейтинг: 0 / 0
01.09.2002, 19:42:22
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047347
Alexandr Kizchenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexandr Kizchenko
Гость
Добрый день!
2qu-qu

Кажется вы забыли в чем суть SQL. Почитайте Грабера. Это же не Паскаль и не Си. С помощью SQL вы говорите КАКИЕ ДАННЫЕ ВАМ НУЖНЫ, а не ЧТО ДЕЛАТЬ СЕРВЕРУ. Поэтому: если в запросе не указан ORDER BY в SELECT , то сервер не гарантирует строгий порядок записей.
Советую пересмотреть алгоритм процедуры, например вместо
insert into #t2 select * from #t1 order by f1,f0
select * from #t2
написать
insert into #t2 select * from #t1
select * from #t2 order by f1,f0
...
Рейтинг: 0 / 0
02.09.2002, 05:08:41
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047348
Alexandr Kizchenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexandr Kizchenko
Гость
2 qu-qu
и еще в догонку
Конструкция
insert into #t2 select * from #t1 order by f0,f1
select * from #t2

не равна кострукции
select * into #table2 from #table1 order by ....
...
Рейтинг: 0 / 0
02.09.2002, 05:19:34
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047362
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
2 qu-qu
А Вы допускаете, что можете ошибаться?
...
Рейтинг: 0 / 0
02.09.2002, 10:04:06
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047366
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
2qu-qu

Кстати, о МИЛЛИОНЕ тестов.

Ф-я NEWID ( ) на одной машине возвращала случайные числа. Это использовалось для случайной сортировки и долго и хорошо работало. А потом перенесли приложение на другой сервер - и чила стали последовательные, как идентити...

Так что МИЛЛИОН тестов - не аргумент. Ссылайтесь, пожалуйста, на документацию. Если не работает - пишите в МС, Вам пришлют фикс.
...
Рейтинг: 0 / 0
02.09.2002, 10:49:59
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047381
Фотография ziktuw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ziktuw
Участник
qu-qu, вы исходите в своих рассуждениях из 2-х ошибочных предпосылок:
1) Вы считаете, что после запроса "insert ...select..order" данные расположаться именно в том порядке, в каком определено в этом запросе. На самом деле это не так. Выборка-кэш, подготавливаемая для вставки, действительно будет отсортирована, но при размещении записей из выборки, sql-сервер будет руководствоваться не порядком записей в этой выборке, а своими внутренними определенными механизмами. На разные страницах записи вполне могут сливаться несколькими потоками из этой выборки (нарушение сортировки раз), упорядочиваясь внутри страницы по кластерному индексу (нарушение сортировки два), фиксация списка страниц с учетом дерева кластерного индекса (нарушение сортировки три). Сами страницы не обязаны располагаться последовательно в файле. Таким образом, уже после вставки хранящиеся данные уже не отсортированы в вашем понимании.
2) Вы считаете, что при указании select без order, данные будут считаны в выборку в порядке физического хранения. Это тоже неверная предпосылка. Позвольте уж серверу в силу соображений performance считать страницы несколькими потоками в том порядке, в каком ему покажется удобнее, склеить выборку из этих считываний первым попавшимся образом и опустить процесс ее сортировки, ибо, как посчитает сервер, раз не задано order by, значит какого бы то ни было порядка и требуется.

qu-qu, по-моему вы придираетесь к sql-серверу необосновано. Вам дано средство сортировки - order by в выражении select, чего же еще не хватает? Вы же не требуете от автопроизводителей, чтобы машина могла ездить без колес. Если рассуждать вашей логикой, то и здесь можно докопаться.
...
Рейтинг: 0 / 0
02.09.2002, 12:01:37
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047401
qu-qu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qu-qu
Участник
2 Alexandr Kizchenko
на: ...Кажется вы забыли в чем суть SQL. Почитайте Грабера...

Вы, уважаемый, пришли в эту "полемику" немного поздновато... Не собирался я ни с кем обсуждать "суть SQL" или еще что-либо такое же глобальное... Я тоже могу "гордо" отослать вас почитать Виннера, Кнута или еще кого-то, где черным по белому написано, что "... нет смысла усложнять алгоритм там, где не требуется ничего кроме простых действий...". Вы мне все пишете о декларативной сути языка SQL (даже не T-SQL), оптимизации запросов, кешировании данных выборки (наверное думаете, что я - ничего про это вообще ни разу не слышал), а я вам толкую - про конкретный результат работы конкретного серверного приложения. Которое, если спрашивают - выдать весь набор записей без условий фильтрации и сортировки, выдает его обычным последовательным перебором, не "заморачиваясь" ни на что другое... (в этом-то как раз и заключается - его оптимальность).

2 SergSuper
на: А Вы допускаете, что можете ошибаться?

Очень даже - допускаю... Но все что мне до сих пор приходилось читать в этом топике - это голословные утверждения, основанные на точно такой же "слепой вере" в собственное понимание "сути SQL", почерпнутое даже не из опыта работы с ним (SQL-ем), а из книг...
Ну верят люди в то, что сервер может возвращать результаты одного и того же селекта - в различной последовательности... Что же я с ними могу поделать? Примеры мои - им не доказательство... Своих примеров - они не приводят (или приводят - "липовые", такие же умозрительные как и их вера).
Вот когда мне приведут здесь код на T-SQL, который действительно возвращает хотя бы 2 различных набора на 2 одинаковых простых селекта (без условий и сортировки) - тогда я признаю себя неправым...
А до этого - увольте.

2 alexeyvg
на: Ф-я NEWID ( ) на одной машине возвращала случайные числа.... перенесли приложение на другой сервер - и чила стали последовательные, как идентити...

Здесь вы просто приводите пример недоисправленного бага новой версии сервера (те кто регулярно читает этот форум про этот баг знают).
А в самом топике - не об этом речь, естественно...
...
Рейтинг: 0 / 0
02.09.2002, 12:52:44
| Ответить | Цитировать | Написать  
Рушится вера в
    #32047411
Tulkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Tulkin
Участник
2 qu-qu
Слышь,чувак! прикол в том, что и "экстенты", "оптимизатор", и "физическое размещение" были еще в Sybase SQL Server 4.X, после которого пути Sybase и MS разошлись. И мне приходится делать над собой усилие, чтобы не ответить тебе грубостью на грубость(уже вторую).И прежде,чем выносить вердикт, что в этом форуме все "не нормальные", и им в этом топике не место, подумай о своей "нормальности". А что смешно, так это то, что тебе неделю талдычат истину, а ты не догоняешь, или делаешь вид что не догоняешь.
...
Рейтинг: 0 / 0
02.09.2002, 13:11:49
| Ответить | Цитировать | Написать  
25 сообщений из 35, страница 1 из 2
  1  все
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Рушится вера в
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=46&startmsg=32047182&tid=1820674]:
 0ms
get settings:
 6ms
get forum list:
 9ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 39ms
get topic data:
 6ms
get forum data:
 2ms
get page messages:
 33ms
get tp. blocked users:
 1ms
others: 201ms
total:  301ms
созд. / загр.: 301ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]