lsv__Подскажите, как обычно выглядит структура следующей БД.
Расчет зарплаты.
Выглядит так как написано ТЗ. А учитывая специфику начислений и удержаний то универсального решения нет и небудет. Поэтому вопрос задавайте тому кто будет этим заниматься.
lsv__Сервер, например MS SQL.
База - 200-500 Гб.
1 млн. сотрудников.
1000 пользователей.
40 филиалов
В базе также кадровая информация, адрес, инн, надбавки и т.д. (порядка еще 300 полей, описывающих сотрудника)
Расчет филиалы производят каждый месяц, в одно время, также есть массовые индексации зарплаты.
Ограничений по производительности железа особых нет. (т.е. сотни Гб оперативки, СХД, десятки процессоров организовать возможно)

Возможно ли удержать все эти данные в одной базе на уровне головной организации (может даже в одной таблице на весь 1 млн. сотрудников). Или же будут серьезные проблемы с производительностью и блокировками? (или еще с чем-либо)

Или стоит дробить на базы филиалов или еще как-либо?
Ну если проблем с железом нет (и соответственно с лицензиями) то можно все хранить и в одной БД (в случае чего потом отпочковать нужный филиал непроблема, хотя опять же - если в железо ничего неупирается то проще админить одну БД чем 40). И размер который вы привели это весьма детский. У меня к примеру была база на мелкомягком скуле 350 Гиг и никто не умер. Так что все решается.
Насчет одной таблицы это конечно бред еще тот ...
Дедлоки и пр. конечно же будут. Но это уже забота разработчиков как минимизировать эти явления. Заметьте что полностью избавиться практически нереально. Хотя зависит от нагрузки и пр.
lsv__Если есть пример, как данная задача решена в больших организациях, можно дать ссылку.
Ну на больших конторах никто незаморачивается городить самопал для зарплаты. Берут коробочные решения от 1С например и напильником пилят до нужной кондиции. Просто по деньгам это в десятки (а может и сотни) раз дешевле чем городить свой самопал. Если мне не верите то сами прикиньте по деньгам.

LSVПардон, а чем с инжен.точки зрения самопал отличается от "коробки" ? Тем более допиленной самопально.
И какой из вариантов будет более приемлемым и оптимальным ?
Ну если в коробке есть больше 80% функционала то очевидно более эффективно использовать коробку и допилить недостающие моменты. Это если конечно работать нужно а не ...
LSVзы: большое число "коробок" пригодны разве что для попило-откатов, но не для реальной работы.
Все в этом мире относительно. Кому-то шашечки, а кому-то ехать. Так что я нестану тут что-то утверждать. У каждого своя ситуация. Так что каждый ошибается по своему. Если автор сможет учесть хотя бы часть ошибок других людей то это уже хорошо. Но всех моментов учесть просто неполучится. Поэтому задача свести риски к минимуму.

lsv__,

1 млн. сотрудников это не проблема. И даже 10. Да, по специфике по закрытию месяца когда начисление делается - это будет пиковая нагрузка на систему. Да, в этот момент сервер(а) "просядут". Но учитывая что такое происходит 1 раз в месяц то вполне терпимо ограничить количество пользователей или ночью запускать расчет ЗП. При нормальном железе это займет максимум 1 час. Как по мне это не проблема.
Проблема в специфике. Т.е. максимальный риск это изменения в законодательстве . И чем более кардинальные изменения тем более интересная ситуация будет.
С технической стороны никаких проблем нет.

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

По вопросу структуры БД. Это зависит от конкретных задач. Поймите что аппетит приходит во время еды. Поэтому то что заказчик хочет на начальном этапе как правило в лучшем случае составляет 60% конечного результата. Например, по теме - вполне вероятно что заказчик захочет привязать заполнение табеля к контрольно-пропускной системе. Ну и т.п.
Я б например старался не городить монстра запихивая все и вся в одну таблицу, а наоборот разнес по нескольким (справочная информация, периодические значения, ... ). При правильной расстановке индексов будет мизерная потеря на вставках. А при больших выборках потерь на чтении практически небудет.