Oi pessoal,
To vendo essa conversa se estender, e quero dar minha opinião, pois tenho sistema multiempresa rodando. Quando vejo a discussão sobre as permissões no banco de dados, me pergunto por que o usuário terá a liberdade de operar em cima dele fora do sistema. Creio que somente o DBA devesse ter esse direito. Sendo assim, no sistema, ao iniciar, seta-se uma variável global com o código da empresa atual, e somente esses dados serão carregados/listados/alterados. E ninguém tem a senha de login no banco, exceto o DBA. Criar esquemas vai gerar um custo muito alto de manutenção desse banco, pra sincronizar metadados, mesmo que seja para CX2, como disseram. E separar em tabelas distintas também. Concordo plenamente com o Mozart. De: Adriano Espinoza de Oliveira [mailto:adrianoespin...@gmail.com] Enviada em: quinta-feira, 11 de dezembro de 2008 13:52 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] Banco Multiempresa Mozart, concordo com você!!! Mas, como você mesmo, pode servir para alguem... No caso do Saulo, está na cara que trata-se de um caixa 2, e bla bla bla... APARENTEMENTE!!!! digo APARENTEMENTE uma esquartejada de leve não vai trazer problemas.... Adriano 2008/12/11 Mozart Hasse <mozart.ha...@usa.net> Bases separadas?! Para brincar até dá, mas... e se o teu banco tiver mais 800 tabelas?? O que é que se faz com as 2000 chaves estrangeiras e os 4000 índices?! Cria em todas as bases de filiais ?! Lindo, e aí "é só" configurar alguns arquivinhos super triviais do SLONY para sincronizar as míseras 200 tabelas de uso comum a todas as filiais. Vamos pensar *médio*. E se você quiser tirar um relatório gerencial das 30 filiais do mesmo *estado* ? (Brasil inteiro não, que eu propus pensar *médio*!) Quantos UNIONs você vai ter de fazer se a consulta de uma empresa só você já precisa de umas 8? Quanto tempo você acha que o planejador vai gastar só descobrindo se ele dá conta de rodar um comando desse tamanho? Agora o divertido mesmo vai ser atualizar a estrutura desse negócio. Que tal rodar o mesmo script ALTER TABLE nas 30 filiais? Acha que um scriptzinho criado via cut-paste ou macros mirabolantes para usar na linha de comando quebram teu galho? Bom, o interessante vai ser explicar para o cliente que ele vai precisar de um DBA toda a vez que quiser cadastrar uma filial nova. Fico imaginando quanto tempo o cliente vai gastar com DBAs só monitorando o SLONY para garantir que ele atualizou as tabelas comuns em todas essas bases e que todas as tabelas estão com a mesma estrutura. O legal mesmo vai ser alguém precisar rodar (ou precisar de algo equivalente) um UPDATE em todas as filiais de uma vez, dentro de uma só transação... Sinto muito, essa idéia de esquartejar bases até pode servir para alguém, mas no meu caso, na-na-ni-na-não. Mozart Hasse > Sobre o assunto, eu *não* misturaria dados de empresas distintas em uma mesma > tabela sem utilizar um controle de permissões a nível de registros (como os > descritos acima) porque seria fácil, senão trivial, conseguir dados indevidos. > Como alguns colegas sugeriram, eu optaria por utilizar esquemas para separar > empresas e utilizaria a nomenclatura nomedomodulo_nomedoobjeto para designar > os objetos (tabelas, funções, visões, etc). > _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
