Bem lembrado, é uma opção interessante : não dá pra aplicar em todos
os casos, mas é um recurso a mais, verdade.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, [EMAIL PROTECTED] escreveu
Caso a aplicação acesse os objetos de apenas um SCHEMA basta
configurarmos na aplicação ou num trigger de logon para alterar o
SCHEMA que o usuário está trabalhando com o seguinte comando:
Alter session set current_schema=PRODUCAO
A partir do momento que a aplicação/trigger executa o comando acima
qualquer comando SQL, por exemplo, estará referenciando os objetos do
esquema PRODUCAO
Agora se a aplicação consulta objetos de vários esquemas esta opção
não resolve...
Mauro Moreira Silva
Universidade de Cuiabá - MT
Coordenador de Tecnologia
DBA Oracle
(65) 615-1166 / 9223-5913
www.unic.br
-Mensagem original-
De: oracle_br@yahoogrupos.com.br
[mailto:[EMAIL PROTECTED] Em nome de jlchiappa
Enviada em: sexta-feira, 11 de novembro de 2005 17:09
Para: oracle_br@yahoogrupos.com.br
Assunto: Spam:[oracle_br] Re: Boas práticas: SINONIMOS PÚBLICOS
Sim, sem dúvida é uma questão de escolha, como quase tudo na vida : o
pequeno overhead em performance existe, MAS também existe a
inflexibilidade de vc estar hard-codeando o schema, se tiver que mudar
vai dar trabalho... É aquele negócio, se o aplicativo PRECISA ser o
mais performático da empresa, é CRÍTICO, e VAI escalar pra centenas de
usuários simultâneos o overhead pode vir a ser INACEITÁVEL, se não
estiver nessa escala sim, pode-se engolir a quedinha de performance em
nome de mais flexibilidade. Quem faz a escolha, porém, tem que fazer
consciente do que vao obter. E é claro, há uma escala : se der, eu
hard-codeio, é a opção preferida, mas SE não der (porque precisa de
mais flexibilidade, porque vai haver vários ambientes no banco, etc)
que se use sinônimos PRIVADOS, sinônimos públicos é a ÚLTIMA DAS
opções
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, falmeida [EMAIL PROTECTED] escreveu
Com todo respeito,
Eu descordo um pouco do chiappa. Imagine que você trabalhe em uma
consultoria que deseja implantar um sistema SISPAG (FOLHA DE
PAGAMENTO) que é apoiado num schema chamado SISPAG em um novo cliente.
Só que para sua surpresa já existe um schema chamado SISPAG que se
refere ao contas a pagar do novo cliente.
Pergunto eu a vocês, qual é o custo de se alterar o SCHEMA.TABELA em
todas as procedures, funcions, triggers, packages views? Fora pensar
no próprio aplicativo que tem algum SELECT ou mesmo nas chamadas as
PACKAGES etc.
Imagine o custo de se manter dois conjuntos de fontes, bancos etc.
Falo isto pois já passamos por isto. Então, prefiro utilizar
sinonimos, pois fico independente do nome do SCHEMA. Qualquer problema
basta reapontar e documentar os sinônimos e o todo.
Sinônimo público faço referência somente para as tabelas comuns a
todos os SISTEMAS. Exemplo FEDERAÇÂO, MUNICIPIO, PAIS etc.
Abraços,
Fabão.
Em 11/11/05, MARCO ANTONIO[EMAIL PROTECTED] escreveu:
Oi Pessoal,
Volto a perguntar...
Existe algum problema em se usar SINONIMOS PUBLICOS,
indiscriminadamente em varios esquemas que compoem um sistema?
Penso em usar sinonimos para mascarar a real localizacao dos
objetos e evitar a necessidade de prefixacao de tabelas, visoes,
procedures, etc?
Mas receio sobre quais seriam as consequencias (impacto) desta
pratica no trabalho dos desenvolvedores, dbas e ads.
Se alquem puder relatar alguma experiencia vivida sobre este
assunto, ou ainda,se souberem de algum documento a respeito, me
indiquem, por favor.
Um abraco a todos!
Marco
eof
-
Yahoo! Acesso Grátis: Internet rápida e grátis.
Instale o discador agora!
[As partes desta mensagem que não continham texto foram removidas]
--
Atenção! As mensagens deste grupo são de acesso público e de
inteira responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
--_
Area de download do grupo -
http://www.4shared.com/dir/101727/a4dcc423
Links do Yahoo! Grupos
--
Fábio Martinho de Almeida
Niterói-RJ-Brasil
Visite o fotolog: http://fotolog.net/canon_a300
--
Atenção! As mensagens deste grupo são de acesso público e de inteira
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
