Имеем следующее:
Справочник пользователей;
Таблица с документами (в полях этой таблицы сейчас есть три ссылки на пользователей, например: создатель записи, бригадир, контролёр);
Каждому пользователю отображаются только доступные ему документы, отбираемые из всех на основе упомянутых выше трех полей.

Требуется:
Теперь все это хозяйство требуется распространить на сотню филиалов, но появляется дополнительное требование: должна быть возможность сделать документ, числящийся в конкретном филиале, доступным одному или нескольким пользователям, находящимся в этом же и/или в другом филиале.

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

Собственно, мои варианты:
1) Хранить все в одной БД с добавлением следующей таблицы (далее - "новая таблица"): Пользователь; Ссылка на документ. При этом добавлять автоматически в эту таблицу в том числе и записи, основанные на значениях полей "создатель, бригадир, контролер".
Плюсы такого варианта: новая таблица будет централизованным источником информации о доступных пользователю документах.
Минусы такого варианта: кол-во записей в этой новой таблице будет более чем в три раза превышать суммарное по всем филиалам количество документов, а доступ на добавление и чтение в нее будет постоянным. Поэтому она станет бутылочным горлышком.
2) Хранить все в одной БД с добавлением такой же, как в 1, таблицы: Пользователь; Ссылка на документ. Но не добавлять автоматически в эту таблицу записи, основанные на значениях полей "создатель, бригадир, контролер", а добавлять только доступ для "дополнительных" пользователей.
Плюсы такого варианта: не будет гигантского количества записей в новой таблице и постоянной записи в нее.
Минусы такого варианта: придется везде при выборке собирать информацию и из новой таблицы и фильтровать дополнительно сами документы по трем полям.
3) Хранить документы филиалов в разных БД. Как в этом варианте правильно сделать отображение у пользователя документов, которые кто-то для него открыл - тоже есть разные варианты... Например, наиболее быстродействующим считаю вариант создания у пользователя задач-клонов, которые в случае изменения будут обновляться с помощью отдельной системы репликации (в том числе и в пределах одной БД, но у разных пользователей).
Плюсы этого варианта: возможность работы БД каждого филиала на своем сервере этого филиала, а следовательно, распределение нагрузки, географическое распределение отказоустойчивости, ограничение доступа админов каждой БД только к данным своего филиала.
Минусы: дополнительное звено репликации документов между БД.

Хочу услышать мнения и другие варианты.
Заранее спасибо!

Максим НKISS - поэтому имхо первый.
KISS - что это? (Гугл в неадеквате :))

s_ustinovи почему возник вопрос? неужели у вас каждый филиал создает десятки документов в секунду?
Много или мало - понятия относительные... Если бы это была "главная ERP" и ее поставили на большой и шумный сервер, который бы еще десять лет не напрягаясь проглатывал кучи новых данных и тучи запросов, то на вопрос производительности можно было бы забить, как это делают многие кодеры, которым лишь бы накодить здесь и сейчас, а когда оно через два года тормозить начнет (причем не только из-за недостаточной железной мощи, но и например из-за блокировок в таблице), они скажут "ну оно же работало, а как мы могли знать!..."
В общем, вопрос правильного проектирования возникает не потому что "сейчас", а потому что надо думать на несколько лет вперед, а прогноз подозревает, что документов будет миллион...

Максим Н, спасибо )