powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Таки M$ MuzDie или MS SQL 7.0 vs 2000
3 сообщений из 3, страница 1 из 1
Таки M$ MuzDie или MS SQL 7.0 vs 2000
    #32026971
ReaperMan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Уважаемые господа SQL-гуру!
Я просто фигею с M$ SQL 7.0 чем дальше тем больше. Вот есть ли какое-нить здравое объяснение следующему факту:

Выполняем запрос (реального примера для reproduce behavior не могу предложить, к сожалению)
SELECT Tab1.ID as Tab1_ID, Tab2.ID as Tab2_ID, Tab3.ID as Tab3_ID, Tab4.Name
FROM Tab1
JOIN Tab4 on Tab4.ID = Tab1.Tab4_ID
JOIN Tab2 on Tab2.ID = Tab1.Tab2_ID
JOIN Tab3 on Tab3.ID = Tab1.Tab3_ID
WHERE Tab1.ID IN
(SELECT TOP 10 b.ID FROM Tab1 b GROUP BY b.ID HAVING Count(*) > 1 ORDER BY Count(*) DESC)

потом меняем в списке выбираемых полей Tab4.Name на другое поле из этой же таблицы - и получаем другой набор данных! Это моему уму вообще нерастяжимо. Может бросить все нафиг и уехать в Урюпинск?
То бишь перейти на 2000? Вопрос вообще-то в основном как раз в этом и заключается - действительно ли семерка настолько горбата и непредсказуема, что ее использование не очень (мягко говоря) целесообразно?
...
Рейтинг: 0 / 0
Таки M$ MuzDie или MS SQL 7.0 vs 2000
    #32026978
nic_ii
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Честно говоря в запрос не въехал 8(
зачем делать JOIN-ы по Tab2 и Tab3?
SELECT Tab1.ID as Tab1_ID, Tab1.Tab2_ID, Tab1.Tab3_ID, Tab4.Name по моему такой селект выберет то-же самое...

А глюков таких за 7 не замечал, хотя базу используем довольно активно (может у нас в Урюпинске базы не те? )
хотелось бы все-таки реального примера для reproduce behavior
...
Рейтинг: 0 / 0
Таки M$ MuzDie или MS SQL 7.0 vs 2000
    #32026981
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нда... Тяжелый случай... Такой запрос надо было придумать
Есть пара предположений, который вполне объясняют странности.
1.Если не задан явно порядок вывода запроса через ORDER BY,
то таковой порядок выбирается более чем произвольно. В
результате, при изменении набора выводимых полей в запросе
такой порядок может быть изменен без предупреждения. Есть
предположение, что на результирующий запрос накладывается
не указанное здесь дополнительной ограничение на количество
выводимых записей, типа TOP или ROWCOUNT
2.Изменение набора выводимых полей может вести к изменению
плана запроса, в итоге подзапрос может выдавать разную 10
записей. Например, в случае, если Tab1 имеет несколько групп
с одинаковым числом в разных ID, то никто не даст гарантии,
что десятка будет одна и та же. Простейший пример:
ID Count
1 2
......
10 2
11 2
В результате подзапрос может вернуть десятку 1..10, 2..11 и
т.п. и всегда это правильно. Мораль, в случае ORDER по одному
и тому же значению нет никакой гарантии, что выбирая TOP 10 в
разных ситуациях, будут получены одни те же записи, для этого
надо устанавливать порядок по уникальному ключу.
Надеюсь доходчиво ?

P.S. Может и правда в Урюпинск, а ?
...
Рейтинг: 0 / 0
3 сообщений из 3, страница 1 из 1
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Таки M$ MuzDie или MS SQL 7.0 vs 2000
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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