Базу безусловно лучше делать одну.
Ссылочную целостность ту же как ты будешь реализовывать ?
Скажем, удаляется Клиент.
Нельзя удалять Клиента, по которому есть документы - отгрузки, оплаты.
Это уже две подсистемы завязаны с Клиентами.
А дальше у тебя могут появиться еще подсистемы - скажем, выполнение работ.
CRM функционал - еще одна отдельная подсистема.
Когда сущности в этих дополнительных подсистемах сидят в той же БД, легко наладить ссылочную целостность, а когда они будут в отдельных БД - будет бардак.

В частности, придется очень сложно отслеживать - что где удалять.
Скажем, удаляешь из одной БД Клиента - надо проверить, нет ли ссылок на него во ВСЕХ прочих БД, т.е. в Продажах, Кассе, Выполнении работ, CRM... И будут появляться новые.

Так что целиком согласен с предыдущими авторами - зоопарк получается.

Разделение подсистем должно происходить на уровне кода. Т.е. разные подсистемы работают со своими объектами (классами).
Например, в Продажах могут быть описаны классы Накладная, Счет-Фактура.
В Кассе - приходный и расходный кассовые ордера, м/б там же и банковские документы.
В Работах - Заказы и документы о ходе их выполнения.
В CRM - дополнительные данные о днях рождения клиентов, любимой собаке/жене/теще, способы связи, и функционал оповещения - типа послать СМС на стотовый - "Ваш заказ готов, забирайте."
А хранятся данные всех подсистем в одной БД.

ORM-системы типа DataObjects или EntityFramework такую задачу решают на раз, обновляя структуру БД при изменении структуры объектов какой-то из твоих подсистем, или при добавлении новой, и оставляя в неприкосновенности таблицы, используемые другими подсистемами. Вот, кстати, 1С такого не умеет - от того проистекает масса сложностей.