Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
uniqueidentifier как первичный ключ
|
|||
|---|---|---|---|
|
#18+
Привет, All Есть ли у кого опыт использования в качастве первичного ключа таблицы поле типа uniqueidentifier. У нас создается распределенная база, (~40 merge pull подписчиков), и я предвижу проблемы с пересекающимися PK, и поле типа uniqueidentifier default NEWID() меня бы избавило от этой проблемы. Хотелось бы услышать (увидеть) комментарии по поводу быстродействия JOIN-ов по таким ключам, и узнать что я найду, и что потеряю, используя subj. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2002, 07:31 |
|
||
|
uniqueidentifier как первичный ключ
|
|||
|---|---|---|---|
|
#18+
Плюсы: 1. Можно явно указать ID при вставке (отличие от int identity), что снимает проблемы с получением ID только что вставленной записи на корню 2. Нет пересечения по ID с другими записями (не было ни разу) 3. Нет возможности угадать следующий ID (актуально для int identity) имея на руках некий 4. Для репликации плюс... Минус: 1. Дольше запросы. Но на 1.000.000 записей join двух таблиц по UNIQUEIDENTIFIER проходит практически также, как и на int. Числа не приведу, но тест делал... 2. Больше места под хранение Вот такие дела. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2002, 08:28 |
|
||
|
uniqueidentifier как первичный ключ
|
|||
|---|---|---|---|
|
#18+
Спасибо. Похоже, в моем случае даже и минусов не остается - в базе куча таблиц, и из них всего парочка объемом >1.000.000 записей, следовательно и требования к месту под хранение не критичны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2002, 09:09 |
|
||
|
uniqueidentifier как первичный ключ
|
|||
|---|---|---|---|
|
#18+
Все так. Добавлю только, что - если будешь настраивать merge репликацию на таблицу, где primary key int'овое поле, то все равно будет создано дополнительное поле типа uniqueidentifier, так что в этом случае места для хранения потребуется больше. - тесты на int и uniqueidentifier в случае некластерного индекса дают практически одинаковый результат на join. Кластерный int'овый вроде должен быть быстрее. На uniqueidentifier кластерный индекс вешать не стоит исходя из самого этого понятия, иначе каждый insert будет фактически приводить к физическому перемещению кучи данных. - с merge репликацией сплошные плюсы и радости по сравнению с геморроем полей identity. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2002, 09:12 |
|
||
|
uniqueidentifier как первичный ключ
|
|||
|---|---|---|---|
|
#18+
2GreenSunrise: >На uniqueidentifier кластерный индекс вешать не стоит исходя из самого этого понятия, иначе каждый insert будет >фактически приводить к физическому перемещению кучи данных. Это спорно: если Вам необходимо ускорить INSERT'ы, то да, если SELECT'ы то нет. Классическая проблема OLTP vs DSS. Первичный ключ типа uniqueidentifier с кластерным индексом значильно ускоряет выборки по сравнению с некластерным на том же поле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2002, 13:49 |
|
||
|
|
start [/forum/topic.php?fid=46&msg=32027066&tid=1823213]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
58ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
| others: | 258ms |
| total: | 429ms |
| 0 / 0 |
