La segunda idea (para crear un atributo booleano para la selección) tiene muchas ventajas :
(i) documenta claramente lo que hay que etiquetar,
(ii) es tan permanente y portátil como el conjunto de datos subyacente,
(iii) proporciona un mecanismo sencillo y directo para determinar qué etiquetas aparecerán (que incluso es portátil a otro SIG o paquete de trazado),
(iv) es incluso susceptible de análisis en caso de que alguna vez surjan dudas sobre las relaciones entre estas elecciones de etiquetas y cualquier otra variable, y
(v) al codificar de forma parsimoniosa la elección del cliente, no crea información duplicada.
Aquí entran en juego algunos principios generales de construcción y gestión de bases de datos como sabiamente se sugiere en la pregunta. Una de ellas es que cualquier información coherente debe ser únicamente representados en la base de datos si es posible. (La información utilizada como claves para aplicar uniones y relaciones, por supuesto, debe aparecer en varios lugares en virtud de su función como identificación de registros correspondientes en tablas diferentes). Existen excelentes razones para aplicar este principio, ya que cualquiera que haya intentado mantener una no normalizado base de datos relacional puede dar fe: si no se acuerda sistemáticamente de actualizar o eliminar o añadir esta información a cada tabla en la que aparece, su base de datos pronto se vuelve internamente incoherente: se corrompe, a menudo de forma irrecuperable.
Otro principio es que en un buen diseño de base de datos relacional, cada tabla debe representar una única "entidad" conceptual algo que los datos están modelando o una relación entre esas cosas. Cuando un cliente especifica una selección aparentemente arbitraria de características, en realidad está especificando un subconjunto de filas de una tabla. Matemáticamente, por la axioma de separación es lo mismo que marcarlos con un campo booleano. Así, cualquier Un subconjunto "arbitrario" de cosas en una base de datos puede representarse mediante un campo booleano y, a la inversa, un campo de este tipo es una buena forma de almacenar subconjuntos arbitrarios (o selecciones).
Otro principio es que debes prefieren utilizar las capacidades de gestión de datos subyacentes del SIG para almacenar información . La alternativa es ad hoc basado en la capacidad del SIG para almacenar información en sus "archivos de proyecto" o de alguna otra forma independiente. Un ejemplo típico es la práctica de elegir y colocar manualmente las etiquetas deseadas. A menudo es rápido y fácil hacerlo. Los problemas surgen cuando es necesario realizar un cambio o reproducir el trabajo; una u otra de estas situaciones es prácticamente inevitable. La colocación manual de las etiquetas equivale a almacenar información (a saber, qué subconjunto de características debe etiquetarse) fuera del RDBMS de forma extremadamente elíptica. Es decir, la selección especificada únicamente por las etiquetas que aparecen y las que no. Piense en cómo resolvería entonces estos problemas derivados:
-
El cliente quiere que las mismas etiquetas aparezcan en un mapa relacionado pero distinto, que forma parte de un proyecto diferente.
-
Se plantea la cuestión de si las etiquetas están asociadas a algún otro atributo.
-
Después de realizar varios cambios en las etiquetas a lo largo del tiempo, se le pide que vuelva a la versión original.
En estos casos, el trabajo necesario para resolver el problema puede ser enorme: hay que rehacer de nuevo el etiquetado, o realizar comprobaciones manuales cruzadas con las tablas de la base de datos, o encontrar y restaurar un antiguo fichero de proyecto archivado. En cambio, si las etiquetas estuvieran representadas por un campo booleano en la base de datos, el trabajo sería casi trivial.
