Uma pergunta que eu gostaria que fosse respondida é:você precisa ver dados entre clientes para seus próprios relatórios ou uso? Nesse caso, você precisa ficar com o número um ou terá um pesadelo para obter bons relatórios.

Você vai fazer alguma customização por cliente? Isso indicaria que separar as coisas pode ser uma escolha melhor. Se você nunca vai personalizar, então não se separe.

Trabalhei com sistemas em todas essas opções e a primeira é de longe a melhor para manutenção de longo prazo. No entanto, todos são viáveis ​​se você for organizado e planejar bem. Se você optar pela opção separada, deverá ser capaz de enviar as alterações para todos os clientes e, portanto, deve fazer alterações no banco de dados por meio de scripts mantidos no controle de origem. Você pode até precisar manter um controle de origem por versão do banco de dados, para que os clientes possam optar por atualizar ou não. Na opção 1, claro, ninguém tem a opção de ficar na versão antiga. Se isso se adequar melhor às suas necessidades de negócios, essa é uma vantagem para a opção 1.

Eu concordo totalmente com Ollie Jones, se você usar a opção um, você deve ter um bom design de segurança de banco de dados para evitar que os clientes vejam os dados de outros clientes. Certa vez, movemos um cliente de um servidor onde ele era o único cliente para um banco de dados compartilhado e apenas um proc que não pediu o client_ID (não era necessário no sistema antigo e os desenvolvedores ficaram desleixados) acabou enviando e-mail para todos os representantes de vendas de todos os outros clientes com informações sobre o primeiro cliente. Isso custou muito dinheiro à empresa (tanto para corrigir o problema, quanto para enviar desculpas por e-mail e quase perdemos um cliente como resultado e tivemos que dar a eles algumas reduções de custo para mantê-los) e muitas desculpas rastejantes e o desenvolvedor por pouco perdeu o emprego. Que esta seja uma lição que você não aprende da maneira mais difícil.