Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Сортировка по uniqueidentifier
|
|||
|---|---|---|---|
|
#18+
Код: sql 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. rnguidhexсравнение1924C2CA1-D2E1-E811-B806-0050568515CC0xA12C4C92E1D211E8B8060050568515CC 26C424612-81E2-E811-B806-0050568515CC0x1246426CE28111E8B8060050568515CC<3C226932A-25E3-E811-B806-0050568515CC0x2A9326C2E32511E8B8060050568515CC>439F7D4F1-58E3-E811-B806-0050568515CC0xF1D4F739E35811E8B8060050568515CC>593A5975D-6FE3-E811-B806-0050568515CC0x5D97A593E36F11E8B8060050568515CC<6048B9E9E-6FE3-E811-B806-0050568515CC0x9E9E8B04E36F11E8B8060050568515CC>7978D2B02-71E3-E811-B806-0050568515CC0x022B8D97E37111E8B8060050568515CC<8F5E5DB35-71E3-E811-B806-0050568515CC0x35DBE5F5E37111E8B8060050568515CC>926E3B539-F0E3-E811-B806-0050568515CC0x39B5E326E3F011E8B8060050568515CC>104516A640-F0E3-E811-B806-0050568515CC0x40A61645E3F011E8B8060050568515CC> Приведён результат 2го запроса, так как результат 1го запроса есть столбцы guid, hex 2го запроса в той же последовательности. Оба запроса сортируют результат по возрастанию столбца guid. Но, как видно, сортировка есть строки значение которых меньше, чем у предыдущей строки. Если отсортировать по столбцу hex: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. , то получим правильный порядок строк по столбцу hex, но опять-таки - непонятный порядок по столбцу quid: rnguidhexсравнение1978D2B02-71E3-E811-B806-0050568515CC0x022B8D97E37111E8B8060050568515CC26C424612-81E2-E811-B806-0050568515CC0x1246426CE28111E8B8060050568515CC>3C226932A-25E3-E811-B806-0050568515CC0x2A9326C2E32511E8B8060050568515CC>4F5E5DB35-71E3-E811-B806-0050568515CC0x35DBE5F5E37111E8B8060050568515CC>526E3B539-F0E3-E811-B806-0050568515CC0x39B5E326E3F011E8B8060050568515CC>64516A640-F0E3-E811-B806-0050568515CC0x40A61645E3F011E8B8060050568515CC>793A5975D-6FE3-E811-B806-0050568515CC0x5D97A593E36F11E8B8060050568515CC>8048B9E9E-6FE3-E811-B806-0050568515CC0x9E9E8B04E36F11E8B8060050568515CC>9924C2CA1-D2E1-E811-B806-0050568515CC0xA12C4C92E1D211E8B8060050568515CC>1039F7D4F1-58E3-E811-B806-0050568515CC0xF1D4F739E35811E8B8060050568515CC> Если конвертировать guid в varchar отсортировать по этому значению: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. , то получим правильную сортировку сортировку по quid, но неправильную по hex: rnguidhexсравнение1048B9E9E-6FE3-E811-B806-0050568515CC0x9E9E8B04E36F11E8B8060050568515CC226E3B539-F0E3-E811-B806-0050568515CC0x39B5E326E3F011E8B8060050568515CC>339F7D4F1-58E3-E811-B806-0050568515CC0xF1D4F739E35811E8B8060050568515CC>44516A640-F0E3-E811-B806-0050568515CC0x40A61645E3F011E8B8060050568515CC>56C424612-81E2-E811-B806-0050568515CC0x1246426CE28111E8B8060050568515CC>6924C2CA1-D2E1-E811-B806-0050568515CC0xA12C4C92E1D211E8B8060050568515CC>793A5975D-6FE3-E811-B806-0050568515CC0x5D97A593E36F11E8B8060050568515CC>8978D2B02-71E3-E811-B806-0050568515CC0x022B8D97E37111E8B8060050568515CC>9C226932A-25E3-E811-B806-0050568515CC0x2A9326C2E32511E8B8060050568515CC>10F5E5DB35-71E3-E811-B806-0050568515CC0x35DBE5F5E37111E8B8060050568515CC> Это какая-то особенность типа uniqueidentifier: последовательность возрастания значений во внутреннем представлении uniqueidentifier не совпадает с последовательностью возрастания представления значений этого типа в символьном или бинарном виде? Как-то хотелось бы при сортировке по столбцу uniqueidentifier (по которому ещё и построен индекс) видеть глазами ожидаемый результат: строки идут по возрастанию. Не хотелось бы ещё делать конвертацию в другие типы и строить по ним ещё один индекс. Вот ещё один неприятный момент, когда "визуальное" представление о том, что больше-меньше, не совпадает с тем, что получается в итоге: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2019, 14:49 |
|
||
|
Сортировка по uniqueidentifier
|
|||
|---|---|---|---|
|
#18+
guid не предназначен для "сортировки" PrologЭто какая-то особенность типа uniqueidentifier: последовательность возрастания значений во внутреннем представлении uniqueidentifier не совпадает с последовательностью возрастания представления значений этого типа в символьном или бинарном виде? Ты ниповеришь! Даже для int все очень печально. В этом смысле. Да шо там int, varchar туда же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2019, 14:57 |
|
||
|
Сортировка по uniqueidentifier
|
|||
|---|---|---|---|
|
#18+
Невооруженным глазом видно, что в текстовом представлении в некоторых секциях байты стоят в обратном порядке. Возможно, связано с особенностью хранения структуры в памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2019, 15:00 |
|
||
|
Сортировка по uniqueidentifier
|
|||
|---|---|---|---|
|
#18+
Konst_One, Самое интересное, что такое свойство как раз обнаружилось на столбце с NEWSEQUENTIALID(). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2019, 15:26 |
|
||
|
Сортировка по uniqueidentifier
|
|||
|---|---|---|---|
|
#18+
вы уверены, из вашего кода этого не видно. было бы неплохо иметь дополнительное поле времени вставки записи в вашей таблице, чтобы его использоввать в сортировке ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2019, 15:36 |
|
||
|
Сортировка по uniqueidentifier
|
|||
|---|---|---|---|
|
#18+
т.е. что то guid сортировки нет, и монотонного возрастания тоже нет, то давайте в что нибудь сконвертируем и вдруг... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2019, 16:05 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39835992&tid=1687566]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
146ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 237ms |
| total: | 477ms |

| 0 / 0 |
