Decidindo o comprimento dos campos de shapefile?


8

No meu trabalho, herdei vários shapefiles originários do MapInfo que estou trazendo para um novo projeto no QGIS. Tenho a oportunidade de alterar os nomes das colunas, adicionar e subtrair colunas e, como ainda não há muitos dados, posso começar de novo e ajustar também os comprimentos dos campos.

Percebo que alguns comprimentos de campo são muito maiores do que precisam e lembro-me da criação anterior de bancos de dados há 20 anos, mais ou menos, que é melhor manter os comprimentos de campo não mais do que precisam. economize em 'espaço', para melhorar a eficiência.

Isso ainda é desejável ou o comprimento do campo não importa mais?


Depende do formato que você está usando.
precisa saber é o seguinte

1
O comprimento do campo provavelmente deve ser mantido como "não mais do que precisa", por definição, você não precisa de mais nada. É claro que depende do que você está capturando para determinar qual o comprimento "necessário".
DMusketeer

3
Na IMO, a melhor prática mais importante é parar de usar os shapefiles, se possível.
alphabetasoup

Respostas:


12

A resposta depende do formato dos dados. Os arquivos do dBase-III +, que são usados ​​nos shapefiles para atributos, têm largura fixa, portanto, a definição de uma coluna FIPS para ter 254 caracteres de largura usa 254 bytes. Pior ainda, o dBase tem uma largura máxima de registro de 4000 bytes, portanto os 249 desperdiçados em um campo de cinco caracteres não estão disponíveis para outros campos (dos quais existe um máximo de 100 ou 255, dependendo de quem está implementando o padrão). Os limites também se aplicam ao tamanho total do arquivo dBase (2Gb), que pode ser acessado por 536k registros na largura máxima, quando registros de 5,36m estarão disponíveis na largura de 400 bytes.

Há outro motivo para limitar a largura do campo - a qualidade dos dados. Se um designador puder conter apenas dois caracteres legalmente, mas você o definir com dez, aumentará a possibilidade de ter um valor inválido com o dedo gordo aceito pelo arquivo de dados.

Por outro lado, se você fornecer apenas a largura necessária e obter dados internacionais no formato UTF-8, poderá ficar com pouco espaço quando um caractere pode usar de 2 a 6 bytes.

Portanto, para os campos de sequência de banco de dados (que inclui o geodatabase), que geralmente são encerrados e, portanto, não desperdiçam espaço em linha, a flexibilidade é uma opção, mas para formatos de largura fixa as regras antigas ainda se aplicam.


Obrigado pelas respostas. Não sei se entendi completamente a resposta de Vince, pois não conheço muito sobre diferentes estruturas de banco de dados, mas entendo o essencial. Acho que a minha principal consideração, então será com a integridade dos dados e não a criação de nada mais do que ele precisa ser - o que parece óbvio agora - graças
Martin Hugi

As principais ferramentas para agradecer a quem responder à sua pergunta são votar e marcar a pergunta respondida. Se você não tiver certeza de alguma coisa, pergunte. A idéia aqui é criar boas respostas.
Vince

1
@Vince respondeu bem, há apenas mais uma pequena razão que eu acrescentaria: deixar clara a intenção. Quando um campo chamado "state" possui apenas 2 caracteres, é óbvio que o campo deve conter a abreviação padrão de um estado. No entanto, se você criar esse campo com 50 ou 200 caracteres, ele poderá ser interpretado como mantendo o nome completo do estado. Isso está relacionado à qualidade geral dos dados.
RustProof Labs

Acompanhamento - Após 18 meses, tudo isso faz muito mais sentido agora - ótima resposta
Martin Hügi
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.