Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Таки M$ MuzDie или MS SQL 7.0 vs 2000
|
|||
|---|---|---|---|
|
#18+
Уважаемые господа 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? Вопрос вообще-то в основном как раз в этом и заключается - действительно ли семерка настолько горбата и непредсказуема, что ее использование не очень (мягко говоря) целесообразно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2002, 12:08 |
|
||
|
Таки M$ MuzDie или MS SQL 7.0 vs 2000
|
|||
|---|---|---|---|
|
#18+
Честно говоря в запрос не въехал 8( зачем делать JOIN-ы по Tab2 и Tab3? SELECT Tab1.ID as Tab1_ID, Tab1.Tab2_ID, Tab1.Tab3_ID, Tab4.Name по моему такой селект выберет то-же самое... А глюков таких за 7 не замечал, хотя базу используем довольно активно (может у нас в Урюпинске базы не те? ) хотелось бы все-таки реального примера для reproduce behavior ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2002, 13:10 |
|
||
|
Таки M$ MuzDie или MS SQL 7.0 vs 2000
|
|||
|---|---|---|---|
|
#18+
Нда... Тяжелый случай... Такой запрос надо было придумать Есть пара предположений, который вполне объясняют странности. 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. Может и правда в Урюпинск, а ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2002, 13:38 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32026971&tid=1823234]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
61ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
2ms |
| others: | 221ms |
| total: | 391ms |

| 0 / 0 |
