Bom dia! Estamos estruturando um banco de dados PostgreSQL para utilizar o E3, e gostaríamos de dividir as tabelas em schemas distintos, distinguindo eles por meio da “função” que a tabela possui. Por exemplo, um histórico gostaria de salvar dentro do banco como “historicos.hist_est_01”, e os dados de uma pena real temporária em outro, como “temporarios.pena_est_01”. É possível realizar isso no E3?
Definição de schema para tabela no PostgreSQL
Sim, é só alterar a propriedade ‘banco de dados’ da sua conexão com o banco, isso será o seu schema:
Depois o nome da tabela você vai configurar no histórico que vai usar pra salvar
Não, isso é o banco de dados.
No PostgreSQL, a estrutura de tabelas é assim: database.schema.table
Se utilizar 2 bancos distintos, por exemplo, não tenho como realizar uma consulta com JOIN, a menos que cadastre a tabela como um Foreign Data Wrapper. Isso fica inviável de acordo com a evolução do sistema. Porém, se utilizo dois schemas dentro de um banco, consigo normalmente consultar cruzado, como SELECT * FROM schema1.tabela1, schema2.tabela2. Nesse exemplo simplifiquei um inner join sem utilizar um ON/WHERE, mas é uma consulta válida. No entanto, usando o schema public padrão, não poderia fazer SELECT * FROM db1.public.tabela1, db2.public.tabela2 sem usar um FDW para consultar entre os bancos.
De fato, o E3 só usa o schema public, confundi as coisas
Bom dia galera, um pequena contribuição sobre esse tema apesar que no meu caso foi SQLServer espero que ajude em algum ponto.
Acredito que o equivalente ao schema public no PostgreSQL é o dbo no SQLServer para facilitar a explicação.
Trantando de objetos nátivos do E3 (histórico) é até possível “enxergar” os objetos (tabelas, procedure e etc) pertecente a esquemas diferentes do dbo quando utiliza a opção “Vincular histórico a uma tabela já existente” e a tabela já existe no banco, mas é gerado um erro ao tentar inserir os dados indicando a inexistência do objeto (tabela).
Não foi possível gerar a tabela a partir do objeto nátivo do E3 (histórico) da forma esperada ele acaba criando no schema dbo concatenando o schema desejado, EX.: dbo.[historico.historico]
Algo funcional é utilizar o objeto de consulta para inserir na tabela com a opção Habilitar edição direta do SQL. Utilizando os comandos de manipulação desejado e realizando o Execute
OBS.: Caso for utilziar usuários dedicados para cada esquema pelo menos no SQLServer deve haver permissões para o schema dbo devido a necessidade de manipulação de algumas procedures no momento de conexão com o banco pelo objeto do E3 (DBServer)
Você está correto. DBO é equivalente ao public no esquema, e quanto a forma que o E3 faz essa concatenação mencionada.
A solução para esse cenário seria então obrigatoriamente trabalhar com o public usando o objeto de histórico/alarmes/etc. ou trabalhar com scripts brutos.
Seria interessante a adição de um “modo avançado” para configuração de objetos relacionados aos bancos de dados, permitindo maior flexibilidade aos desenvolvedores.
2 Likes
Sim e gerenciar por exemplo a tabela de alarmes dessa forma seria quase que impossivel.
Poderia utilizar grupos no banco caso a necessidade seja controle de acesso aos objetos além da organização dos mesmos que o schema oferece.