1. Я не гуру, поэтому прошу прощение за то, что вклинился в разговор между молчаливыми гуру и задавшим вопрос. Рекомендую не адресовать вопросы к гуру , если желаете получить на вопросы ответ. Настоящие гуру на подобные вопросы не отвечают в меру своей скромности. А те, которые отвечают, на самом деле таковыми не являются (хотя могут страдать манией величия). На данном форуме все равны и лично я против дискриминации и разделения его членов на гуру / не гуру. Теперь по сути...
2. Вероятность небольшая, но можешь упереться в переполнение int (если собираешься использовать identity). И дело тут не столько в том, что записей в БД много (до диапазона int вроде бы далеко). А дело в том, что при использовании int неизбежно возникают дырки в нумерации. Соотношение живых номеров к дыркам может сильно меняться от условий работы, логики.
3. Раздробленность информации по разным таблицам - не так уж и плохо. Скорее даже наоборот. Некоторые специально разбивают таблицы на несколько однотипных, относящихся к разным учетным периодам. Только ради того, чтобы ускорить выборку. Ты же хочешь сделать наоборот. Видимо, для того, чтобы ее замедлить. Как ты думаешь, сколько времени будет выполняться самый простой select только по одной корневой таблице, содержащей 5 млн записей?
4. На самом деле никаких плюсов это не принесет. Какой смысл фильтровать по корневой таблице, если она в любом случае должна джоиниться с какими-то другими таблицами, систематизировать которые для реализации унификации запросов на любую тему все равно вряд ли удастся. Экономии места в таблицах тоже не добъешься. Учетная дата по каждой операции все равно где-то должна фиксироваться. В корневой таблице или в другой - значения не имеет. Место она все равно занимать будет. А вот дополнительные ключевые поля место займут (и увеличат время выборки).
5. Не понятно, зачем ДВА поля. Кого ты там закрываешь и открываешь ПО каждой операции? Если речь идет об учете хозяйственных операций в учете, то у них всегда одна учетная дата - дата совершения операции.
6. Твой подход не устраняет главной проблемы, ради которой используют подобные решения - устранение конфликтов репликации при обменен информацией между множеством баз данных. Дело в том, что построенный таким способом идентификатор является уникальным только в пределах базы данных (если речь идет об int+identity). Обеспечить уникальность на разных серверах можно только заданием разных диапазонов identity для идентификаторов разных серверов (еще больше сократив запас разрядной сетки int), либо использовав составной индекс, в который входит дополнительное поле - идентификатор сервера. IMHO, с помощью Uniqueidentifier все получается гораздо изящнее. Тем более, что эти поля автоматом могут использоваться как rowguid для MERGE-репликации.

Резюме. Я бы так делать не стал. Но на вкус и цвет...

Вообще-то эту тему совсем недавно обсуждали с SergSuper. Вроде бы все обмусолили... Если в одной большой таблице хранится всё, то это одно (как и предлагал SergSuper). А если в одной большой таблице хранятся только идентификаторы (ну и плюс учетные даты), а все остальные поля в других таблицах, то IMHO толку от этого никакого.
Некоторый смысл возникает, если кроме самого идентификатора хранить еще и имя (или идентификатор) таблицы, к которой он имеет отношение. Но этот смысл появляется только при использовании динамического SQL, который имеет свои минусы (кроме плюсов).