Boa noite, Compreendo a tua ideia e por acaso até cheguei a ponderar essa possibilidade no entanto vou mesmo pelo cenário 2. Os scripts de criação da BD já lançam vários dados por default. A partir dai será uma questão de planear muito bem a manutenção.
Obrigado pelas opiniões. No dia 22 de Fevereiro de 2014 às 19:02, Miguel Vaz <[email protected]>escreveu: > É quase impossível dar uma opinião fundamentada sem conhecer um pouco mais > do cenário, mas pelo que disseste, porque não ambas as situações? Bem, mais > ou menos. Bases de dados para cada uma das empresas do grupo e uma para as > informações que sejam comuns/partilhadas por todas elas. Até podes ter > situações em que, apesar de existirem bases de dados separadas, as > informações podem ser sincronizadas para um repositório comum. Desculpa a > simplicidade da explicação mas sem conhecer mais dados, torna-se um pouco > dificil sugerir. > > Pesadelos podem acontecer nas duas situações, tudo depende da > implementação, estrutura e dinâmica de conteúdos. > > Ia escrever "espero ter ajudado", mas após reler o meu email acho que > ficamos a saber o mesmo. :-P > > > Miguel > > > > > > > > 2014-02-22 13:07 GMT+00:00 Hugo Ferreira <[email protected]>: > >> Sim, percebo o teu ponto de vista. >> >> >> No dia 22 de Fevereiro de 2014 às 12:45, João Saleiro < >> [email protected]> escreveu: >> >> >>> A manutenção é um pesadelo no cenário 1, e não no cenário 2. >>> BTW, o que normalmente me inclina para o cenário 2 é exactamente a >>> simplificação da manutenção. >>> >>> JS >>> >>> Em 22/02/2014 12:30, Hugo Ferreira escreveu: >>> >>>> Boa tarde, >>>> >>>> >>>> Este assunto que me traz aqui hoje não tem nada haver com RIAs mas mais >>>> com BDs. >>>> Numa situação de um projecto em que cada companhia tenha de ter acesso >>>> aos seus dados e por outro lado cada companhia possa agir como um grupo >>>> (multi-companhia), pela vossa experiência qual a implementação que defendem >>>> mais (btw, não que seja o ponto importante da questão, estamos a falar em >>>> SQL Server + PHP). >>>> >>>> Cenário 1 - 1 única BD: >>>> - Campo de grupo em quase todas as tabelas; >>>> - Campo de empresa em quase todas as tabelas; >>>> - Duplicação de dados entre as empresas de tabelas secundárias; >>>> - Manutenção numa única base de dados (é fácil adicionar um novo campo); >>>> - A BD pode vir a ocupar dezenas/centenas de GB. >>>> >>>> Cenário 2 - Multi-BD: >>>> - Cada grupo tem a sua própria BD; >>>> - Campo de empresa em quase todas as tabelas (empresas do grupo); >>>> - Não existe duplicação de dados; >>>> - A manutenção pode se tornar um pesadelo (algum trabalho com rotinas >>>> automáticas, poderá ajudar a colmatar este problema mas mesmo isso requer >>>> investimento e manutenção); >>>> - Cada grupo ocupa o espaço mínimo necessário por BD; >>>> - A instância do SQL Server poderá vir a ter "pendurado" >>>> dezenas/centenas de BDs e não sei como se irá comportar. >>>> >>>> No passado sempre defendi o modelo 1 no entanto agora estou mais >>>> tentado em usar o modelo 2. >>>> Qual é o vossa experiência neste cenário ? >>>> >>>> >>>> Cumps, >>>> Hugo. >>>> >>>> >>>> >>>> >>>> -- >>>> Recebeu esta mensagem porque está inscrito no grupo "Mailing List da >>>> Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" >>>> dos Grupos do Google. >>>> >>>> Para anular a subscrição deste grupo e parar de receber emails deste >>>> grupo, envie um email para [email protected]. >>>> Para publicar uma mensagem neste grupo, envie um e-mail para >>>> [email protected]. >>>> Visite este grupo em http://groups.google.com/group/riapt. >>>> Para mais opções, consulte https://groups.google.com/groups/opt_out. >>>> >>> >>> -- >>> Recebeu esta mensagem porque está inscrito no grupo "Mailing List da >>> Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" >>> dos Grupos do Google. >>> >>> Para anular a subscrição deste grupo e parar de receber emails deste >>> grupo, envie um email para [email protected]. >>> Para publicar uma mensagem neste grupo, envie um e-mail para >>> [email protected]. >>> Visite este grupo em http://groups.google.com/group/riapt. >>> Para mais opções, consulte https://groups.google.com/groups/opt_out. >>> >> >> -- >> Recebeu esta mensagem porque está inscrito no grupo "Mailing List da >> Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" dos >> Grupos do Google. >> >> Para anular a subscrição deste grupo e parar de receber emails deste >> grupo, envie um email para [email protected]. >> Para publicar uma mensagem neste grupo, envie um e-mail para >> [email protected]. >> Visite este grupo em http://groups.google.com/group/riapt. >> Para mais opções, consulte https://groups.google.com/groups/opt_out. >> > > -- > Recebeu esta mensagem porque está inscrito no grupo "Mailing List da > Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" dos > Grupos do Google. > > Para anular a subscrição deste grupo e parar de receber emails deste > grupo, envie um email para [email protected]. > Para publicar uma mensagem neste grupo, envie um e-mail para > [email protected]. > Visite este grupo em http://groups.google.com/group/riapt. > Para mais opções, consulte https://groups.google.com/groups/opt_out. > -- Recebeu esta mensagem porque está inscrito no grupo "Mailing List da Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" dos Grupos do Google. Para anular a subscrição deste grupo e parar de receber emails deste grupo, envie um email para [email protected]. Para publicar uma mensagem neste grupo, envie um e-mail para [email protected]. Visite este grupo em http://groups.google.com/group/riapt. Para mais opções, consulte https://groups.google.com/groups/opt_out.
