Gerenciando o ArcSDE?

Depois de passar um tempo pesquisando as melhores práticas de gerenciamento do ArcSDE no Google, vim de mãos vazias. Eu tenho um bom entendimento dos bancos de dados espaciais e seu gerenciamento, tendo implementado vários bancos de dados Oracle Spatial em larga escala, mas queria ter suas idéias sobre práticas ou padrões que devem ser adotados para facilitar a vida deles e seus recursos espaciais utilizáveis ​​e seguros.

Quais práticas você emprega no banco de dados do ArcSDE para garantir a integridade, segurança e consistência da sua instância do ArSDE?

Quais são os objetivos de seu projeto ao planejar sua instância do ArcSDE e por quê?

São perguntas amplas, e a resposta pode mudar significativamente com o tamanho, os requisitos e o escopo da implementação, mas eu gostaria de avaliar o interesse em um guia baseado na comunidade para este tópico.

Isso é realmente algo em que você encontrará pouca documentação publicamente. Existem aulas / workshops que a ESRI cobra ou que você pode assistir na ESRIUC, mas menos no espaço público.

Alguns dos pontos mencionados são decorrentes das boas práticas de DBA; mas alguns realmente não dependem e realmente de seus sistemas e necessidades.

Para integridade, com certeza é essencial uma plataforma de hardware estável (eu sempre uso sistemas em cluster); e usando o back-end correto do banco de dados. Eu sou de uma sólida formação estadual e federal, por isso costumo me basear em grandes bancos de dados como MSSQL ou Oracle. O MSSQL2008 espacial fornece um bom kit de ferramentas para o custo; em comparação, se você realmente deseja uma prova de bala com acesso de terceiros, deseja considerar o Oracle; onde muitos aplicativos se conectam ao lado espacial.

Segurança; bem, aí você tem uma forte necessidade de DBA para garantir que as contas estejam configuradas corretamente; mas também é necessário usar os controles ESRI internos para quem pode ler / gravar etc de seus bancos de dados. Isso também põe em questão a estrutura de seus dados e de seus sistemas; você precisa criar silos de segurança mais altos, onde você tem mais segurança no nível do usuário; ou é apenas um grande banco de dados único ok, mantendo o usuário por permissões no nível do usuário nos recursos.

O que você também deseja pensar é usar objetos internos, como domínios versus tabelas de referência, com esses valores adequados para você; os domínios podem não estar acessíveis a partir de aplicativos de terceiros que analisam seus dados; onde uma tabela de referência pode ser unida e você tem esses valores codificados.

A normalização de dados é um grande tópico a ser considerado; algumas pessoas estão felizes em fazer um design normalizado sólido, com apenas os recursos SDE da geometria e, em seguida, todo o material tabular nas tabelas de negócios que você possui muitos índices e visualizações para otimizar o desempenho da pesquisa por outros aplicativos.

Portanto, se você tem áreas específicas, está curioso; fique à vontade para adicionar mais detalhes às suas perguntas, mas muito do que você procura realmente depende da sua plataforma e das suas necessidades funcionais. Um aplicativo da web de alta velocidade pode não querer SDE versus apenas fGDB; versus dados dinâmicos exigiria SDE.

Eu acho que DeWright bateu na unha na cabeça. Quanto mais complexa for a estratégia de segurança que você deseja, mais sofisticada será a utilização dos seus rdbms.

Sempre tive o desejo de criar bancos de dados com vários tipos de acesso. Como sdo, postgis. Permitindo que mais de um software ou IDE manipule ou exiba os dados.

Eu sugeriria pegar o caminho mais alto e gastar mais tempo em cenários de pesquisa / teste antes de cometer. Algumas dessas opções parecem ótimas, mas têm limitações.

A otimização, a normalização e o design sólido de banco de dados antes da mão permitirão muita flexibilidade (espacialmente) a longo prazo.