carperВопрос - как организовать ведение первичных ключей, для простоты слияния и легкости выборки в центральном офисе по компаниям и в целом ?
1. Сделать ключи уникальными в пределах всех офисов. create sequence id_seq start with <office#> increment by 100000

2. Не использовать ключ как составной. Явно вводить в таблицы куда нужно поле "офис" как внешний ключ на список итп.

Помимо простоты слияния и лёгкости выборки это обеспечивает ещё один аспект: иногда нужно в одном офисе создавать записи, "по бизнесу" привязанные к другому офису. Скажем: директор филиала приехал в командировку, но что-то делает "у себя". Поэтому "физическое место создания записи" не должно играть роли в бизнес-логике; оно важно только для транспортных задач.

carperможно с учетом ID организации, последнее сильно лучше,
Ну-ну. Если Вы имеете в виду составной ключ..

carper т.к. делить диапазоны поровну между 5000 организациями INHO не лучшая идея.
Боитесь, number(33) не хватит, нужна вся мощь number(38)?

carper2. Вот по второму пункту и неясно - дело в том, что практически 80% таблиц, т.е. все, за исключением справочников, в центральном офисе будут нуждаться в отборе по организации, что при этом получается я уже написал в своем последнем посте - придется либо везде пихать ID_ORGANIZATION либо доставать эти данные из синтетического ключа.
Боюсь, Вы недооцениваете задачу "отбора по организации". Она - по бизнес-логике - сложная и будет постоянно усложняться. Может случиться так, что счёт создан в Питере, отдача по нему идёт с Ростовского склада, а нажавший кнопку человек именно сейчас в командировке в Пензе. И в зависимости от операции строка должна попадать в выборку по тому или иному офису. Поэтому "везде пихать ID_ORGANIZATION" просто необходимо, причём не просто "везде", а "везде именно такой, какой здесь по бизнесу". Иногда и не один. Синтетический ключ здесь просто неприменим, он заведомо станет проблемой в будущем, если не в настоящем.

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

carperМожет все же "воспользоваться случаем" и заложить в синтетический ключ какую-то осмысленную информацию? Лишний так сказать дубль к полю ID_ORGANIZATION?
Вас можно понять по-разному, поэтому отвечу аккуратно.

В него уже заложена информация о "физическом месте создания записи". Она нужна для обеспечения уникальности без составного ключа, а кроме того, пригодится для транспортировки и для ручного разбора проблем.

Использовать эту информацию в других бизнес-целях - чревато. Либо коллизиями (для разных задач нужны разные значения), либо "здесь играем, здесь не играем" (в варианте "здесь берём id_organization, здесь - из ключа) и неизбежными логическими ошибками и проблемами сопровождения (бизнес-логика изменилась и теперь таки надо внести поле id_organization и переписать все запросы к этой таблице).

Заложить в синтетический ключ ещё дополнительные информационные поля - можно в принципе, но не думаю, что нужно. 1НФ таки придумывали не зря. Отдельные поля удобнее. С ними не возникает проблемы с индексированием, с проверкой целостности, с ними удобно писать запросы.

carperПроблема с тем, что человек, "находясь в командировке" создаст свою запись, не стоИт, т.к. у филиалов отсутствует возможность создавать не свои записи, а для тех, кто вынужден создавать записи по разным организациям существует соотв. возможность выбора с какой он организацией работает + по логину/паролю при входе в систему ему назначается "его" филиал, что он потом явным образом может изменить.
У нас здесь чувствуется непонимание. Не знаю, кто кого. Мы, похоже, по-разному понимаем "филиалы" и "организации". Давайте так:

1. Запись, созданная на сервере X, должна иметь X в ключе - для обеспечения уникальности. Это "физика".

2. Работа сотрудника на разных серверах - объективная реальность. Которой может не быть сейчас, но которая возникнет в будущем. Она возникает как в силу командировок, так и в силу удалённого доступа сотрудников на другие сервера (актуально для отдела ИТ, техподдержки и прочих грамотных пользователей). При этом ещё бывает "работа под видом другого человека".

3. Во всех случаях человек работает со "своей" единственной или выбранной организацией. К которой относится логически, вне зависимости от физического расположения.

Вывод: нельзя делать никаких завязок между "физическим местом создания записи" и "филиалом, организацией и прочими местами, к которым запись относится логически".

carperПри чем здесь поле ID_ORGANIZATION? - если использовать даже ваш подход с диапазоном ключей, не ясно. Так или иначе мы знаем с какой организацией пользователь работает и генерируем ему ключ из "его диапазона", а не некий ключ "по-умолчанию" из тригера.
В результате Вы рискуете нарушить уникальность ключа между серверами, когда этот пользователь поедет между ними. В ключ либо должно входить "физическое место генерации", либо нужна некая сложная и ненадёжная система, например, "динамического выделения диапазонов другим серверам".

carperМожно пример, когда в одной таблице нужно несколько ID_ORGANIZATION.
Мм... "Клиент организации А, обслуживает организация Б". Например, у нас часто было, что головной офис заказчика заключает договор с нашим головным офисом, платит деньги, но реальная работа идёт в нашем филиале, обслуживающем соответствующий филиал заказчика.

carper- Почему синтетический ключ неприменим?
Потому что всовывать в него несколько ID будет совсем неудобно.

carperЗапутался, давайте попробуем разобраться, если не сложно
Согласен. Я сейчас попробую изложить своё видение не в форме ответов на вопросы, а как линейный текст. По статусу... я работал с такими системами в нескольких проектах, и так или иначе пробовал всё, что здесь называлось, поэтому позволю себе ссылаться на личный опыт.

Мы запутались в терминологии. Давайте попробуем так. У нас есть две основных сущности: это сервер (экземпляр базы данных, instance) и филиал/организация (некая штатная единица нашей сети). Филиал/организация - в моём представлении синонимы. Я бы предложил использовать "филиал", чтобы не путать с организациями-контрагентами.

Между этими двумя сущностями в принципе отношения многие-ко-многим. То есть обычно филиал сидит на своём сервере, но в принципе может быть несколько филиалов на одном сервере, и бывает так, что сотрудник одного филиала должен работать на сервере другого филиала (локально или удалённо).

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

Внутри одного сервера уникальность обеспечивается механизмами сервера. Для слияния нам нужно обеспечить уникальность ключей между серверами. Минимальный геморрой здесь достигается в случае, если функция генерации использует параметром "место генерации" и гарантирует разные результаты для разных мест - так работает guid, так работает приведённый сиквенс, есть и другие варианты. Ценой этого является "неиспользование части возможных значений", и это очень дёшево . Приведённый сиквенс является с моей точки зрения лучшим во всех случаях, когда количество источников поддаётся надёжной оценке сверху (если может расти лавинообразно, лучше таки guid).

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

В этот ключ технически можно положить ID филиала и любую другую дополнительную информацию - в дополнение и именно в дополнение к ID сервера. Делать так имхо не стоит, причины этого изложены в обосновании 1НФ: с такими данными труднее работать, они плохо индексируются итп. Единственный плюс такого подхода - неявная денормализация, но это палка о двух концах. Денормализация и так вещь, требующая аккуратности... явная лучше.

Таким образом, мы приходим к простой, чёткой и понятной схеме: физика закодирована в ID записи, а в таблицах - обычные поля для логики, ID филиала в частности. Собственно, в результате "транспорт" оказывается вообще не проблемой уровня архитектуры таблиц, он ниже - то есть, нам удалось правильно разложить задачу по полочкам.

В дочерних таблицах первичный ключ - ровно такой же, из одного поля. На родительские таблицы - по идее, ссылка по одному полю этого ключа. Хотя, в некоторых конкретных случаях, мы можем сделать "проверку денормализации", используя внешний ключ по двум полям - где сочтём необходимым.

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

BC97А почему бы не за кодировать эту информацию
наприсер 12*1000000000 + последовательность.next
12 - флиал
последовательность.next - собствеено последовательность
Приведённая мной схема это и делает, но с практической точки зрения более удобна. "Недозаложиться на количество филиалов" много труднее, чем "недозаложиться на количество записей в таблице". С ситуацией, когда именно в приведённой Вами схеме физически кончились ID для филиала - я уже сталкивался, и другим не посоветую :) Перезакладываться, конечно, можно, но тут ещё встаёт вопрос длины ID.. чем они длиннее, тем неудобнее руками ковыряться в базе.

carper
1. Так.
2. Так.
3. Так.

carperЕсли так, то остается вопрос - как все же лучше делать:
- создавать ID_ORGANIZATION только в родительской таблице ....
Но тогда уже напрашивается FK по двум полям (хотя бы для обеспечения целостности).
А вот тут уже имхо - по ситуации. Это обычная задача денормализации, и я не стал бы принимать "одно решение на все случаи жизни". По умолчанию делаем минимум, там, где напрягает - денормализуем.