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

То, что они спроектировали, из общих соображений плохо двумя вещами: во-первых, вероятностью дублирования работы (скажем, если изменится форма отчета, изменение придется вносить в кучу мест), во-вторых, проблематичностью получения сведенных воедино сведений (скажем, счетов-фактур всех контрагентов в разрезе по датам). Вторую часть, может быть, сумеет смикшировать 1C, не знаю ее возможностей.

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

Как правило, первое соображение намного весомее. Тем не менее, есть случаи, когда оправданно выбирают второй подход (скажем, в терминах MSSQL - заводят под каждого контрагента свою БД одинаковой структуры). Это уже надо смотреть по месту.

Об объеме базы действительно вряд ли стоит говорить, не думаю, что он в этих случаях будет кардинально отличаться. Что же до объема md-шника..... скажу так: если программа "долго грузится", и именно из-за него, это конечно минус подходу; этот минус надо выкатить разработчикам и спросить, какой более весомый плюс они покупают таким способом.

Евгений ПожеруковОбъем БД ~13 Гб. Данные хранят за три года, когда спрашиваю: "А как насчет отрезать и выкинуть прошлое?" - крестятся, курят ладан (страшно им даже подумать про это).
И правильно делают. В нормальных БД значимых данных не удаляют вообще никогда, исключительно левые бумажки класса "начали и не кончили".

Если объем БД сказывается на скорости операций, что довольно вероятно, придумывают ту или иную организацию архива, позволяющую сочетать достаточно быстрый доступ к актуальным данным с возможностью поднять старье.