É possível manter chaves primárias em classes de recurso com versão sem código de objetos de arcada?

Como não é uma boa ideia usar ObjectIDs como chaves primárias nos relacionamentos, alguma outra coluna precisará ser usada. É possível usar seqüências de DBMS para preencher colunas de chave primária em classes de versão com versão ou precisarei escrever código de objetos para fazer isso?

Ouvi dizer que IDs globais podem ser usados , mas os DBAs não GIS que mantêm tabelas relacionadas geralmente desaprovam essa ideia.

enterprise-geodatabase esri-geodatabase database-design

— Kirk Kuykendall
fonte

Movendo minha resposta para um comentário, pois minha memória está fraca e pode não ter funcionado corretamente: Há alguns anos, tentei usar um gatilho de inserção na tabela de adições. Se bem me lembro, funcionou. Acabei (e rapidamente) fui para uma solução do ArcObjects (que chamava de procedimento armazenado), porque era mais fácil (para mim) porque não precisava escrever um novo gatilho ao adicionar / versionar uma nova classe de recurso.

— Jay Cummins

Eu acho que foi um gatilho AFTER INSERT (oracle) com uma verificação nula, então a nova linha obteria o valor da chave primária existente se ela fosse movida. Se fosse nulo, seria preenchido. Talvez eu esteja errado e não estava funcionando direito e não percebi. Qual banco de dados está usando?

— Jay Cummins

@ Jay Obrigado por elaborar. Meu principal motivo para fazer esta pergunta é determinar se há outras abordagens para esse problema além do código de objetos que escrevi para fazer isso. Não quero dizer a alguém que minha solução é a única solução possível sem investigar completamente. E se sim, quão difícil é mantê-lo. Ocasionalmente, apenas escrevo procedimentos armazenados, e a maior parte disso está no servidor sql. Eu suspeito que existe uma maneira de fazer isso no nível de dbms (em vez de objetos de arcada), mas nunca o olhei de perto em todos os dbms.

— precisa saber é o seguinte

Sim, é possível - com algumas ressalvas.

Você pode fazer isso com gatilhos - mas a implementação será específica ao DBMS (já que você precisará implementar um gatilho AFTER INSERT diferente usando o mecanismo (específico) do banco de dados subjacente.

Você não poderá especificar nenhum tipo de restrição UNIQUE nesse campo, pois as Tabelas de Inserções e Base podem potencialmente ter entradas duplicadas para cada linha que você modificar (é assim que as atualizações são modeladas nos bancos de dados com versão). Se você cometer o erro de fazer isso na tabela base, acabará percebendo isso quando suas operações de compactação começarem a falhar ...

— Ragi Yaser Burhum
fonte