-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ao meu ver, a principal implicação é a administração. Você cria com seu usuário Paulo uma table chamada tabela. Depois, com seu user Paulo2 você cria uma table chamada table2. Aí, com o mesmo usuário Paulo2, você cria um sinônimo público chamado tabela, apontando para Paulo2.table2. Aí você sai de férias em dezembro (porque é clt e antigo na empresa) e quando volta em janeiro têm um novo projeto gigantesco. A próxima vez que você olhar esses objetos, lá por julho do ano que vêm, você vai ter que ficar caçando os objetos porque não se lembra mais que tabela é um sinônimo público apontando para um objeto cujo nome não tem relação aparente com o nome do sinônimo. Alguns sinônimos públicos, tudo bem... Mas como você já falou em "equipe de desenvolvimento"... Eu iria devagar com isso e passaria a pensar mais em sinônimos privados apenas. De qualquer forma, é sua a decisão. Qualquer coisa, estamos por aí.
Ribeiro, Reginaldo Administrador de Bancos de Dados Oracle Certified Associate 10g - ---------------------------------------------------- DBCom Brazil Consultoria em Tecnologia da Informação skype: rflribeiro mobile: 551192344290 fone: 551135225172 e-mail: [EMAIL PROTECTED] site: http://www.dbcom.com.br Chave Pública: http://keyserver.noreply.org/pks/lookup?search=rflribeiro%40dbcom.com.br&fingerprint=on&op=index Paulo wrote: > > Fantástico, era exatamente este meu problema: > > Para acessar a tabela de outro usuário eu preciso colocar o OWNER > antes do nome da tabela como: OWNER.nometabela como assinalado. > > Mas posso também criar um "Sinonimo" como Reginaldo me indicou > através do e-mail, solução fantástica que facilita para os > desenvolvedores quando criarei usuários com permissões diferentes. > Muito obrigado mesmo pela ajuda! > > Agora só por uma questão conceitual: Devo adotar então que esta é a > forma única ou a melhor forma para realizar a divisão de acesso de > uma tabela dentre alguns usuários? É possível uma tabela possuir > mais de um OWNER(tenho absoluta certeza que não, mas para checar)? > O uso de sinônimos do tipo public é um recurso utilizado(penso em > questões de segurança)? Enfim preciso de um argumento interessante > para convencer a minha chefe que esta é a solução mais > interessante. > > Um abração! > > --- Em oracle_br@yahoogrupos.com.br > <mailto:oracle_br%40yahoogrupos.com.br>, Reginaldo Ribeiro > <[EMAIL PROTECTED]> escreveu >> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> Paulo, alguns amigos já tiveram oportunidade de orientá-lo. Eu, >> inclusive, lhe enviei um exemplo imenso em pvt contendo, >> inclusive, instruções para lidar com sinônimos de objetos e links >> de referência. Seria interessante informar se sua dúvida está >> sanada. Obrigado. >> >> >> Ribeiro, Reginaldo Administrador de Bancos de Dados Oracle >> Certified Associate 10g - >> ---------------------------------------------------- DBCom Brazil >> Consultoria em Tecnologia da Informação skype: rflribeiro mobile: >> 551192344290 fone: 551135225172 e-mail: [EMAIL PROTECTED] site: >> http://www.dbcom.com.br <http://www.dbcom.com.br> Chave Pública: >> > http://keyserver.noreply.org/pks/lookup?search=rflribeiro%40dbcom.com.br&fingerprint=on&op=index > > <http://keyserver.noreply.org/pks/lookup?search=rflribeiro%40dbcom.com.br&fingerprint=on&op=index> > >> >> >> >> Rafael Almeida Milanez wrote: >>> >>> Vamos la para simulação >>> >>> [EMAIL PROTECTED]>show user USER é "PAULO" >>> >>> [EMAIL PROTECTED]>create table T_TSE 2 ( cod number); >>> >>> Tabela criada. >>> >>> [EMAIL PROTECTED]>grant create session to paulo2 ; >>> >>> [EMAIL PROTECTED]>grant select on paulo.T_TSE to paulo2; >>> >>> Concessão bem-sucedida. >>> >>> >>> Agora conecto com Paulo2 >>> >>> [EMAIL PROTECTED]>show <mailto:[EMAIL PROTECTED]>show> user USER é "PAULO2" >>> >>> Ai esta a diferença, voce tem que colocar o OWNER.tabela >>> >>> [EMAIL PROTECTED]>select <mailto:[EMAIL PROTECTED]>select> * from T_TSE; >>> select * >>> from T_TSE * ERRO na linha 1: ORA-00942: table or view does not >>> exist >>> >>> >>> [EMAIL PROTECTED]>select <mailto:[EMAIL PROTECTED]>select> * from >>> paulo.T_TSE; >>> >>> não há linhas selecionadas >>> >>> ________________________________ >>> >>> De: oracle_br@yahoogrupos.com.br > <mailto:oracle_br%40yahoogrupos.com.br> >>> <mailto:oracle_br%40yahoogrupos.com.br> >>> [mailto:oracle_br@yahoogrupos.com.br > <mailto:oracle_br%40yahoogrupos.com.br> >>> <mailto:oracle_br%40yahoogrupos.com.br>] Em nome de Paulo >>> Enviada em: segunda-feira, 27 de outubro de 2008 10:24 Para: >>> oracle_br@yahoogrupos.com.br > <mailto:oracle_br%40yahoogrupos.com.br> >>> <mailto:oracle_br%40yahoogrupos.com.br> Assunto: Re: RES: >>> [oracle_br] Novo Usuário para Tablespace Existente >>> >>> O usuário que executou os comandos foi o OWNER que criou as >>> tabelas. Ele pertence à rule DBA: >>> >>> SQL> select * from owner.T_TSE; select * from owner.T_TSE * >>> ERROR at line 1: ORA-00942: table or view does not exist >>> >>> SQL> select * from T_TSE; >>> >>> ORDER_ID NAME ---------- ---------- 1 Joao 5 Paulo >>> >>> Quando eu faço: >>> >>> SQL> select OWNER from DBA_SEGMENTS where TABLESPACE_NAME = >>> 'TSE'; >>> >>> OWNER ------------------------------ PAULO >>> >>> O que eu quero é que o usuário PAULO2 tenha acesso a tabela >>> T_TSE. >>> >>> SQL> GRANT SELECT ON T_TSE TO PAULO2; >>> >>> Grant succeeded. >>> >>> SQL> COMMIT; >>> >>> SQL> CONNECT PAULO2/PAULO2; Connected. >>> >>> Commit complete. >>> >>> SQL> SELECT * FROM T_TSE; SELECT * FROM T_TSE * ERROR at line >>> 1: ORA-00942: table or view does not exist >>> >>> SQL> >>> >>> --- Em oracle_br@yahoogrupos.com.br > <mailto:oracle_br%40yahoogrupos.com.br> >>> <mailto:oracle_br%40yahoogrupos.com.br> >>> <mailto:oracle_br%40yahoogrupos.com.br> , "Rafael Almeida >>> Milanez" <rmilanez@> escreveu >>>> >>>> Voce necessita colocar o OWNER (dono da tabela) antes para > visualizar >>>> >>>> >>>> select * from owner.T_TSE >>>> >>>> ________________________________ >>>> >>>> De: oracle_br@yahoogrupos.com.br > <mailto:oracle_br%40yahoogrupos.com.br> >>> <mailto:oracle_br%40yahoogrupos.com.br> >>> <mailto:oracle_br%40yahoogrupos.com.br> >>> [mailto:oracle_br@yahoogrupos.com.br > <mailto:oracle_br%40yahoogrupos.com.br> >>> <mailto:oracle_br%40yahoogrupos.com.br> >>> <mailto:oracle_br%40yahoogrupos.com.br> ] Em nome de Paulo >>> Andrade >>>> Enviada em: segunda-feira, 27 de outubro de 2008 09:34 Para: >>>> oracle_br@yahoogrupos.com.br > <mailto:oracle_br%40yahoogrupos.com.br> >>> <mailto:oracle_br%40yahoogrupos.com.br> >>> <mailto:oracle_br%40yahoogrupos.com.br> >>>> Assunto: [oracle_br] Novo Usuário para Tablespace Existente >>>> >>>> >>>> >>>> Pessoal tem uma dúvida que não consigo encontrar resposta: >>>> >>>> Possuo uma Base "SID = BASE3" com alguns tablespaces. Tenho >>>> por exemplo um TABLESPACE de nome "TSE" e criei uma > tabela de >>> teste e inseri algum dado. Tenho também um usuário que está com >>> a permissão de DBA e CONNECT definido na tablespace "TSE". >>>> >>>> Tudo certo até então. Agora não consigo fazer o seguinte: >>>> Criar um >>> novo usuário que consiga acessar a tabela que está na >>> TABLESPACE > "TSE". >>>> >>>> Criei o usuário novo com o comando: >>>> >>>> CREATE USER "NEWUSR" IDENTIFIED BY "NEWUSR" DEFAULT >>>> TABLESPACE > "TSE" >>> TEMPORARY TABLESPACE "TEMP_TSE" PROFILE DEFAULT ACCOUNT UNLOCK; >>> >>>> >>>> e defini as permissões: >>>> >>>> GRANT "CONNECT" TO "NEWUSR" >>>> >>>> e >>>> >>>> GRANT SELECT ON T_TSE TO "NEWUSR"; >>>> >>>> Apesar de ser retornado que efetivou o GRANT, não consigo > realizar o >>> "SELECT" na tabela "T_TSE" com o "NEWUSR". >>>> >>>> O que devo fazer? >>>> >>>> Paulo Andrade > > <!-- #ygrp-mkp{ border: 1px solid #d8d8d8; font-family: Arial; > margin: 14px 0px; padding: 0px 14px; } #ygrp-mkp hr{ border: 1px > solid #d8d8d8; } #ygrp-mkp #hd{ color: #628c2a; font-size: 85%; > font-weight: bold; line-height: 122%; margin: 10px 0px; } #ygrp-mkp > #ads{ margin-bottom: 10px; } #ygrp-mkp .ad{ padding: 0 0; } > #ygrp-mkp .ad a{ color: #0000ff; text-decoration: none; } --> <!-- > #ygrp-sponsor #ygrp-lc{ font-family: Arial; } #ygrp-sponsor > #ygrp-lc #hd{ margin: 10px 0px; font-weight: bold; font-size: 78%; > line-height: 122%; } #ygrp-sponsor #ygrp-lc .ad{ margin-bottom: > 10px; padding: 0 0; } --> <!-- #ygrp-mlmsg {font-size:13px; > font-family: > arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;} > #ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg > select, input, textarea {font:99% > arial,helvetica,clean,sans-serif;} #ygrp-mlmsg pre, code {font:115% > monospace;*font-size:100%;} #ygrp-mlmsg * {line-height:1.22em;} > #ygrp-text{ font-family: Georgia; } #ygrp-text p{ margin: 0 0 1em > 0; } #ygrp-tpmsgs{ font-family: Arial; clear: both; } #ygrp-vitnav{ > padding-top: 10px; font-family: Verdana; font-size: 77%; margin: 0; > } #ygrp-vitnav a{ padding: 0 1px; } #ygrp-actbar{ clear: both; > margin: 25px 0; white-space:nowrap; color: #666; text-align: right; > } #ygrp-actbar .left{ float: left; white-space:nowrap; } > .bld{font-weight:bold;} #ygrp-grft{ font-family: Verdana; > font-size: 77%; padding: 15px 0; } #ygrp-ft{ font-family: verdana; > font-size: 77%; border-top: 1px solid #666; padding: 5px 0; } > #ygrp-mlmsg #logo{ padding-bottom: 10px; } #ygrp-reco { > margin-bottom: 20px; padding: 0px; } #ygrp-reco #reco-head { > font-weight: bold; color: #ff7900; } #reco-grpname{ font-weight: > bold; margin-top: 10px; } #reco-category{ font-size: 77%; } > #reco-desc{ font-size: 77%; } #ygrp-vital{ background-color: > #e0ecee; margin-bottom: 20px; padding: 2px 0 8px 8px; } #ygrp-vital > #vithd{ font-size: 77%; font-family: Verdana; font-weight: bold; > color: #333; text-transform: uppercase; } #ygrp-vital ul{ padding: > 0; margin: 2px 0; } #ygrp-vital ul li{ list-style-type: none; > clear: both; border: 1px solid #e0ecee; } #ygrp-vital ul li .ct{ > font-weight: bold; color: #ff7900; float: right; width: 2em; > text-align:right; padding-right: .5em; } #ygrp-vital ul li .cat{ > font-weight: bold; } #ygrp-vital a{ text-decoration: none; } > #ygrp-vital a:hover{ text-decoration: underline; } #ygrp-sponsor > #hd{ color: #999; font-size: 77%; } #ygrp-sponsor #ov{ padding: 6px > 13px; background-color: #e0ecee; margin-bottom: 20px; } > #ygrp-sponsor #ov ul{ padding: 0 0 0 8px; margin: 0; } > #ygrp-sponsor #ov li{ list-style-type: square; padding: 6px 0; > font-size: 77%; } #ygrp-sponsor #ov li a{ text-decoration: none; > font-size: 130%; } #ygrp-sponsor #nc{ background-color: #eee; > margin-bottom: 20px; padding: 0 8px; } #ygrp-sponsor .ad{ padding: > 8px 0; } #ygrp-sponsor .ad #hd1{ font-family: Arial; font-weight: > bold; color: #628c2a; font-size: 100%; line-height: 122%; } > #ygrp-sponsor .ad a{ text-decoration: none; } #ygrp-sponsor .ad > a:hover{ text-decoration: underline; } #ygrp-sponsor .ad p{ margin: > 0; } o{font-size: 0; } .MsoNormal{ margin: 0 0 0 0; } #ygrp-text > tt{ font-size: 120%; } blockquote{margin: 0 0 0 4px;} > .replbq{margin:4} --> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iJwEAQECAAYFAkkF8sAACgkQ9hsrz6ieG2gXUgP/S2wjKB/yUF1SfqmEbMaL/3d/ 9YeVtKV4HhCqERSQeQvR7zFvoJ5618h9FixFwtSyvtp+YITy1Pe0J/X8Dve4JRBV JQWROoS/ALWlMMAh63IxxGeaOpBTDtsZaAN1v4xEbqJhjwt9tU8pkUtpmJOLlr0Y +FRKTEvIqtUN3fqU8do= =24Ff -----END PGP SIGNATURE-----
