Convenções de nomenclatura para o banco de dados PostGIS? [fechadas]

Fechado . Esta questão é baseada em opiniões . No momento, não está aceitando respostas.

Deseja melhorar esta pergunta? Atualize a pergunta para que ela possa ser respondida com fatos e citações editando esta postagem .

Fechado há 2 anos .

Estamos começando a criar um banco de dados com o PostGIS. O banco de dados deve ser para uma equipe de cerca de 5 a 8 pesquisas que trabalham frequentemente com dados geográficos e estatísticas.

Alguém tem experiência com convenções de nomenclatura ao configurar um banco de dados?

algumas coisas importantes que eu já descobri são:

use apenas letras minúsculas
use_underscores não espaços
não use caracteres especiais como ä, é, etc
use apenas um idioma (pode parecer trivial, mas somos internacionais)
nomear tabelas e colunas sempre em singular
encontre uma maneira padronizada de nomear os objetos no banco de dados, ou seja, topic_year_source_format

Especialmente o último ponto é complicado. Armazenando meus próprios dados, reconheci que às vezes você recebe nomes enormes. Portanto, seria melhor armazenar essas informações em metadados de fácil acesso, em vez de criar esses nomes enormes que podem ser bastante irritantes.

postgis-2.0 naming-conventions

— Dspanes
fonte

Parece que você elaborou as convenções técnicas. Não acho que a pergunta que você está fazendo tenha uma resposta correta, mas vou lhe dizer o que inventei para uso em minha organização.

Prefiro organizar dados por grupos porque, como todos sabemos, às vezes os metadados simplesmente não são preenchidos. Descobri que a construção de alguns dos metadados mais básicos da convenção de nomenclatura é muito benéfica.

Para começar, criei uma planilha listando as principais categorias de dados que minha organização gerencia e dei a cada um deles um código exclusivo de duas letras. A planilha também possui uma descrição da categoria e exemplos de recursos que podem ser encontrados em cada categoria. Esta planilha está disponível para todos na minha organização e eu a incluo junto com os dados exportados.

Começo cada nome com o código de duas letras seguido de um sublinhado. Obviamente, você poderia expandir essa ideia e criar o nome dos criadores de dados. Tente manter os nomes curtos e documente seus métodos. Aqui estão alguns exemplos das categorias que eu uso:

BI - interior do edifício; BO - limites; CT - Cartográfico; EL - Recursos de elevação; EM - Resposta de Emergência; GE - geológico; LT - iluminação; PG - Grades e layouts de página; PL - Planimétrico; RA - Raster; RD - Desenho de Referência; SI - Melhorias / Terrenos do Site; SU - Pesquisa; UT - Utilitários.

— Paulo
fonte

Este é um método válido, mas eu realmente não gosto de abreviações. Obviamente, isso é uma questão de gosto pessoal, mas especialmente se você estiver em uma equipe internacional, essas abreviações podem confundir todos e sempre será necessário um dicionário de dados sempre que ele precisar usar o banco de dados. O PostgreSQL permite, se não me engano, 64 nomes de objetos de letras. Faça bom uso desse espaço e crie os nomes mais descritivos que puder encontrar, em um idioma que todos possam entender.

— George Silva

Eu realmente gosto da idéia de categorizar os dados e discutirei isso com meus colegas. Ainda não tenho certeza sobre como nomear os dados dentro do banco de dados. Seus argumentos fazem totalmente sentido que, para a usabilidade, será melhor fornecer nomes claros dentro do banco de dados. Mas temo que o documento de metadados possa ser menos usado assim. Eu pensei que nomear os dados com números abstratos levaria os usuários a se referirem ao documento de metadados e, com isso, contribuir mais para isso, de maneira que as pessoas preenchem mais informações de metadados, pois precisam se referir a eles diariamente e o documento é já aberto ...

— Dspanes

@ Dspanes, esse é um argumento interessante. Como eu disse, não há resposta certa. Em geral, não tenho certeza se gosto da ideia de tornar os nomes intencionalmente confusos, a fim de fazer com que os usuários confiem nos metadados ... é uma ideia interessante.

— Paul

@ Paul Sim, isso parece meio que eu sei;) Mas pelo que eu expirei até agora, as pessoas usam apenas o que é útil para elas. Quanto mais úteis, mais eles usam e quanto mais usam, melhor os metadados podem obter ... O problema é que não temos uma pessoa para cuidar dos metadados, por isso precisamos de uma abordagem participativa na qual todos contribuam. o documento de metadados talvez também traga benefícios, por exemplo, você poderia ter melhores funções de pesquisa e filtro que permitam encontrar dados mais adequados ... mas, sem dúvida, também estou pensando em abordagens alternativas para promover a participação ...

— Dspanes