A segunda ideia (criar um atributo booleano para seleção) tem muitas vantagens :
(i) documenta claramente o que precisa ser rotulado,
(ii) é tão permanente e portátil quanto o conjunto de dados subjacente,
(iii) fornece um mecanismo simples e direto para determinar quais rótulos aparecerão (que são até portáteis para outro GIS ou pacote de plotagem),
(iv) é até passível de análise, caso haja alguma dúvida sobre as relações entre essas escolhas de rótulos e quaisquer outras variáveis, e
(v) codificando parcimoniosamente a escolha do cliente, ele não cria informações duplicadas.
Existem alguns princípios gerais de construção e gerenciamento de banco de dados em funcionamento aqui , como sabiamente sugerido na pergunta. Uma delas é que qualquer informação coerente deve ser representada exclusivamente no banco de dados, se possível. (Informações utilizadas como chaves para implementar une e relaciona-se, naturalmente, deve aparecer em vários lugares em virtude de sua função como identificar registros correspondentes em diferentes tabelas.) Existem excelentes razões para este princípio, como qualquer um que tenha tentado manter um não-normalizado banco de dados relacional pode atestar: se você não se lembrar constantemente de atualizar ou remover ou adicionar essas informações a todos tabela em que aparece, seu banco de dados logo se torna internamente inconsistente: está corrompido, geralmente irrecuperavelmente.
Outro princípio é que, em um bom design de banco de dados relacional, cada tabela deve representar uma única "entidade" conceitual : algo que os dados estão modelando ou um relacionamento entre essas coisas. Quando um cliente especifica uma seleção aparentemente arbitrária de recursos, ele efetivamente especifica um subconjunto de linhas em uma tabela. Matematicamente, pelo axioma da separação, é o mesmo que sinalizá-los com um campo booleano. Assim, qualquer subconjunto "arbitrário" significativo de coisas em um banco de dados pode ser representado por um campo booleano e, inversamente, esse campo é uma boa maneira de armazenar subconjuntos (ou seleções) arbitrários.
Outro princípio é que você deve preferir usar os recursos subjacentes de gerenciamento de dados do GIS para armazenar informações . A alternativa é ad hocmétodo baseado na capacidade do GIS para armazenar informações em seus "arquivos de projeto" ou de alguma outra maneira independente. Um exemplo típico disso é a prática de escolher e colocar manualmente os rótulos desejados. Muitas vezes, é rápido e fácil fazer isso. Os problemas surgem sempre que uma mudança é necessária ou o trabalho precisa ser reproduzido; uma ou outra dessas situações é praticamente inevitável. O posicionamento manual das etiquetas equivale a armazenar informações (a saber, que subconjunto de recursos deve ser rotulado) fora do RDBMS de maneira extremamente elíptica. Ou seja, a seleção especificada apenas por quais rótulos aparecem e quais não. Pense em como você resolveria esses problemas subsequentes:
O cliente deseja que os mesmos rótulos apareçam em um mapa relacionado, mas diferente, parte de um projeto diferente.
Surge uma questão sobre se os rótulos estão associados a algum outro atributo.
Após fazer várias alterações nos rótulos ao longo do tempo, você será solicitado a reverter para a versão original.
Nesses casos, o trabalho envolvido para resolver o problema pode ser enorme: é necessário refazer a rotulagem novamente, executar verificações cruzadas manuais em tabelas do banco de dados ou encontrar e restaurar um arquivo de projeto arquivado antigo. Se os rótulos fossem representados por um campo booleano no banco de dados, o trabalho seria quase trivial.
