Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Выбор первичного ключа  [new]
burgomistr
Member

Откуда:
Сообщений: 64
Есть несколько подразделений, на каждом своя база данных. Нужно реализовать обмен данными между ними. Но есть засада: связи иногда нет, а данные нужно передавать обязательно. В таком случае данные выгружаются на флешку и едут в подразделение на машине.

Собственно стоит вопрос, что выбрать в качестве первичного ключа для таблиц, которые нужно перебрасывать?

1. GUID? Микрософт пугает меня возможными проблемами с производительностью [url=]http://msdn.microsoft.com/ru-ru/library/bb726011.aspx[/url]

2. Разделить стартовые номера первых строк в таблице в зависимости от подразделения? Ну типа в IDENTITY [ (seed , increment) ]

seed установить для каждого подразделения таким образом, чтобы ключи гарантированно не пересекались. Пока склоняюсь к такому варианту, но там есть некоторые чисто организационные заморочки

3. Использовать составной ключ: номер подразделения + автоинкрементное поле?

Что посоветуете? Какие грабли могу словить?
5 окт 11, 12:50    [11387251]     Ответить | Цитировать Сообщить модератору
 Re: Выбор первичного ключа  [new]
BVB_berserk
Member

Откуда:
Сообщений: 35
burgomistr,

Я за третий вариант, как самый гибкий. GUID не люблю, с разделением стартовых номеров всё равно возможна ситуация их пересечения (пусть даже и в теории - когда номера одного подразделения "догонят" номера другого подразделения)
5 окт 11, 13:27    [11387658]     Ответить | Цитировать Сообщить модератору
 Re: Выбор первичного ключа  [new]
skorpk
Member

Откуда: Волгоград
Сообщений: 276
А чем первое не нравится? Да минусы - это размер ну и с фрагментацией справиться можно с помощью NEWSEQUENTIALID(). У вас данные часто вставляются? Но плюс - уникальность.
5 окт 11, 13:56    [11387987]     Ответить | Цитировать Сообщить модератору
 Re: Выбор первичного ключа  [new]
burgomistr
Member

Откуда:
Сообщений: 64
skorpk
У вас данные часто вставляются?



Порядка 15 тыс. записей в день.

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

P.S. Мне этот вариант не то чтобы не нравится, просто малость затрудняюсь с выбором. Вот и спрашиваю у более опытных.
5 окт 11, 14:39    [11388514]     Ответить | Цитировать Сообщить модератору
 Re: Выбор первичного ключа  [new]
skorpk
Member

Откуда: Волгоград
Сообщений: 276
Ну тогда третий вариант - наиболее простой и меньше места занимает на диске.
5 окт 11, 15:13    [11388904]     Ответить | Цитировать Сообщить модератору
 Re: Выбор первичного ключа  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
burgomistr
1. GUID? Микрософт пугает меня возможными проблемами с производительностью [url=]http://msdn.microsoft.com/ru-ru/library/bb726011.aspx[/url]

2. Разделить стартовые номера первых строк в таблице в зависимости от подразделения? Ну типа в IDENTITY [ (seed , increment) ]

seed установить для каждого подразделения таким образом, чтобы ключи гарантированно не пересекались. Пока склоняюсь к такому варианту, но там есть некоторые чисто организационные заморочки

3. Использовать составной ключ: номер подразделения + автоинкрементное поле?

Что посоветуете? Какие грабли могу словить?
А как в третьем варианте будете передавать данные между подразделениями?

Тогда уж не "номер подразделения + автоинкрементное поле", а просто некий формируемый код.

Ну и вариант 2 не такой уж и плохой.

По первому варианту нужно понимать, какая производительность вам нужна. Пусть падение будет даже в разы, но может быть для вашей системы это не страшно?
BVB_berserk
, с разделением стартовых номеров всё равно возможна ситуация их пересечения (пусть даже и в теории - когда номера одного подразделения "догонят" номера другого подразделения)
Вероятность ровно такая же, как и выход за пределы инкрементного ID
5 окт 11, 16:28    [11389672]     Ответить | Цитировать Сообщить модератору
 Re: Выбор первичного ключа  [new]
ZOOKABAKODER
Member

Откуда:
Сообщений: 178
Cталкивался с подобной проблеммой. Остановился на модифицированном втором вариванте.

В локальной БД, свой уникальный только для неё ID (не обязательно автоинкремент) и есть таблица настроек системы, создающей реплику, которая содержит ID самой БД. А в главной БД ключ составной из ID-базы и собсно уникальный ID из этой БД. Так же есть таблица всех локальных баз.
Проблемы были следующие: хозяин одной локальной БД, делал копию и нёс другому, в обход центрального офиса. Решал так: при загрузке проверял, чтоб два раза не грузанули один и тот же ID-базы; формировалка реплик (на локальной БД), проверяла параметры компа на котором её запустили и соответственно грохалась при обнаружении что её скопировали. Ну и административные методы воздействия применял.
5 окт 11, 18:47    [11390945]     Ответить | Цитировать Сообщить модератору
 Re: Выбор первичного ключа  [new]
burgomistr
Member

Откуда:
Сообщений: 64
Всем спасибо, остановлюсь на варианте 2
5 окт 11, 21:20    [11391440]     Ответить | Цитировать Сообщить модератору
 Re: Выбор первичного ключа  [new]
Непонял...
Guest
alexeyvg
А как в третьем варианте будете передавать данные между подразделениями?

...а в чем проблема?
set identity_insert ... on + insert + unique key (id + code)
5 окт 11, 21:40    [11391497]     Ответить | Цитировать Сообщить модератору
 Re: Выбор первичного ключа  [new]
AndreTM
Member

Откуда: Где-то в вологодских лесах...
Сообщений: 6900
А можно вопрос несколько в сторону, но по теме:
А почему Вы, разрабатывая модель, и зная о проблемах со связью, только сейчас спохватились? - Или эта БД разработана не вами?
С другой стороны, нельзя ли уточнить суть термина "связи иногда нет"? - То есть в "подразделениях" вообще при этом никакой связи? Или всё же возможно решение сделать альтернативный канал?
Тут идея вот в чём - вместо того, чтобы навешивать параллельный функционал, при этом рискуя нарушить целостность базы (да и топливо-то дорожает ) - не дешевле ли озаботиться созданием резервных каналов связи?
5 окт 11, 22:03    [11391558]     Ответить | Цитировать Сообщить модератору
 Re: Выбор первичного ключа  [new]
burgomistr
Member

Откуда:
Сообщений: 64
AndreTM
А можно вопрос несколько в сторону, но по теме:
А почему Вы, разрабатывая модель, и зная о проблемах со связью, только сейчас спохватились? - Или эта БД разработана не вами?
С другой стороны, нельзя ли уточнить суть термина "связи иногда нет"? - То есть в "подразделениях" вообще при этом никакой связи? Или всё же возможно решение сделать альтернативный канал?
Тут идея вот в чём - вместо того, чтобы навешивать параллельный функционал, при этом рискуя нарушить целостность базы (да и топливо-то дорожает ) - не дешевле ли озаботиться созданием резервных каналов связи?



Я ее не проектировал. Занимаюсь базой буквально неделю. Резервные каналы, по независящим от меня причинам, никто делать не будет. По крайней мере в обозримом будущем.
5 окт 11, 22:11    [11391583]     Ответить | Цитировать Сообщить модератору
 Re: Выбор первичного ключа  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31949
Непонял...
alexeyvg
А как в третьем варианте будете передавать данные между подразделениями?

...а в чем проблема?
set identity_insert ... on + insert + unique key (id + code)
Да особых нет, только identity будет не непрерывное, но это в прнципе не проблема...
То есть не будет красивого монотонного возрастания identity для каждого филиала по отдельности.
6 окт 11, 09:07    [11392476]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить