ГостиМимоходом слышал, о том что выбор identity field в качестве PK - кривое решение. Хочется узнать почему?
Возможно я не понимаю, что такое identity field, но если не ошибаюсь, его для этого и придумывали. Соответственно, такое утверждение эквивалентно утверждению "identity не должны использоваться".

На аргументацию этого утверждения и мне хотелось бы полюбоваться. Единственный вариант, который я вижу - недобитый фанатик естественных ключей.

gardenmanИ, пожалуйста нарисуйте мне запрос сгруппируйте все по филиалам.

gardenmanИли положим в каком-то филиале грохнулась база. Сделайте экстракт данных для этого филиала из консолидированной.
Ээ.. надо писать?

Хотя в первую очередь надо не экстракт делать, а админа увольнять, у которого в мирное время невосстановимо грохается база.

gardenmanИ, путь допустим диапазон по какой-либо причине перекрылся (мало ли какая ошибка) что делать в этом случае?
Писать прокламацию производителю СУБД. Примерно так - я, мол, делаю


а он, сволочь, полез в чужой диапазон.

gardenmanЯ не говорю что все это сделать невозможно. Пусть каждый живет с тем геморроем который ему нравится.
Вот уж точно. Я правильно понимаю, что для Вас group by division_id - аргумент за составной ключ?

gardenmanА зачем нужно два индекса, если можно обойтись одним?
Можно обойтись и вообще без индексов. Вопрос в том, нужно ли.

Вопрос "что есть оптимально", как мы все догадываемся, вряд ли имеет конкретный и одновременно универсальный ответ. Например, пара индексов PK:(id_field), INDEX:(division, field_a, field_b, field_c) запросто может оказаться предпочтительнее, нежели пара индексов PK:(division, field_a), INDEX:(division, ....)

4321нет, аргумент тут скорее редкая, но таки возможная ситуация, когда базы ставились как заведомо независимые (т.е. никто не написал заранее разных минимумов и максимумов на диапазоны), а потом таки оказалось, что данные надо слить. Кажется таки отапдейтить ид_дивижна проще, чем сдвинуть счетчик
Первое, что в этом случае придется делать - ВВОДИТЬ ид_дивижна, поскольку в "заведомо независимых" базах его не будет. Второе - переписывать все селекты, которые про ид_дивижна знать ничего не знают (в данном случае я предполагаю, что авторы СУБД не настолько законченные идиоты, чтобы пользоваться NATURAL JOIN или аналогичными неявными конструкциями). Ну и само собой, потребуется решить еще кучу неприятных вопросов - согласование справочников, сведение данных, изменения задним числом...

В общем, я бы сказал, это практически в любом случае настолько неприятная процедура, что лучше не давать ей шанса на жизнь. Наверное, можно найти случаи, когда вместо ид_дивижна можно заюзать какой-то подходящий справочник и решить задачу дешево, типа "был справочник с записями ОТДЕЛ1, ОТДЕЛ2, стал справочник с записями ФИЛИАЛ1_ОТДЕЛ1, ФИЛИАЛ1_ОТДЕЛ2", но это вряд ли часто возможно и это совершенно точно не очень-то хорошо.

gardenmanПреписывать селекты?... хм.. что-то я сомневаюсь что это нужно будет делать.
Давайте смотреть. Две таблицы, СОТРУДНИКИ и ЗАРПЛАТЫ. Сделали alter table, добавили в каждую поле "филиал". Выполняем запрос:


Внимание, вопрос: куда меня пошлет бухгалтер, когда я потребую у него все приписанные мне зарплаты?

gardenmanА если у филиалов вдруг пересекаются диапазоны - вот тогда это действительно круто...
Если - как предложил мой собеседник - задача стартует с "независимо установленных систем", в ней на 100% будут коллизии в id-шниках. Если диапазоны изначально удерживаются различными - собственно, имеем вполне нормальную ситуацию с identity, нет никаких причин делать составной ключ. Почему нет? Давайте ограничимся индексами. Итак, изначально есть индекс

PK:(table_id)

С введением понятия филиала добавляются потенциальные индексы:

AK:(table_id, division_id)
AK:(division_id, table_id)

Первый из них почти бессмысленен, хорош только тем, что запрос вида


выполнится несколько быстрее. Второй - вообще бессмысленен за исключением разве что некоторых order by-ев.

gardenmanА если в консолидированной - это ее проблемы
Тогда не понимаю, почему Вы сами не ответили на собственный вопрос "как в таком случае сделать группировку по филиалам". Ровно этими же словами.

Правда, если мне доведется заказывать софт на стороне, я предпочту исполнителя, не имеющего привычки отвечать "это ваши проблемы". Нехай он сидит со своими составными ключами, а я куплю работающую систему.

guest_20040621Что мешает этой нагрузке измениться?
Что, впрочем, не вызовет никаких проблем. Из общих соображений я предпочитаю конструкцию


- она более независима, а магическую константу 1000 обычно не составляет проблемы подобрать так, чтобы она была труднодостижима. Нагрузка может измениться на порядок-другой, а вот с филиалами это маловероятно :)

Тем не менее, и с указанной конструкцией особых проблем нет - нужно только повесить job, который будет выполнять


и сообщать админу о том, что скоро потребуется выделить новый диапазон.

guest_20040621Это иллюзия.
Другого я бы попросил развеять ее. Но учитывая, в какое количество бессмысленного трепа выливается такая просьба в Вашем случае, воздержусь.