A resposta depende muito da resposta a outras perguntas:
[ol][li]Qual o prazo de desenvolvimento?[/li]
[li]Qual a sua real experiência?[/li]
[li]O banco vai trabalhar exclusivamente com a sua aplicação, ou aplicações de terceiros terão de interagir com o banco?[/li]
[li]Como será a manutenção dos dados? Backup? Alterações na estrutura do banco?[/li]
[li]As interações com o banco serão via SC ou você irá trabalhar com Store Procedures, Views, Triggers?[/li][/ol]
Isso é o básico que deve ser considerado, além de muitas outras coisas que os mais experientes podem mencionar.
Como você mesmo se definiu como alguém sem muita experiência, talvez a melhor abordagem seja vários bancos de dados, um para cada empresa, a manutenção disso quando o sistema estiver em funcionamento é bem mais complicada, por que serão várias interações em vários bancos, mas o risco de ocorrerem erros de lógica e programação são menores.
Pense no seguinte, manter integridade de dados em um banco só não é coisa de outro mundo, porém em um sistema ERP, por exemplo, imagina se por um erro de lógica em um dos módulos, o financeiro por exemplo, você começa a gerar contas a pagar ou a receber em uma empresa equivocadamente, seria catastrófico. Ou ainda se houver emissão de boletos e remessa com protesto, os títulos seriam enviados incorretamente, ou seriam protestados sem o conhecimento da empresa. Podem dizer, meu Deus isso é quase impossível de acontecer!! Mas quase é bem diferente de impossível.
Eu tenho um sistema de gerenciamento de processos de sinistros, fiquei neste mesmo dilema e cheguei a conclusão que ter um banco para cada empresa me daria um pouco mais de trabalho mas me traria maior segurança das informações.
Acho que escrevi D+!!! 
