La segunda idea (crear un atributo booleano para la selección) tiene muchas ventajas :
(i) documenta claramente lo que debe etiquetarse,
(ii) es tan permanente y portátil como el conjunto de datos subyacente,
(iii) proporciona un mecanismo simple y directo para determinar qué etiquetas aparecerán (que es incluso portátil para otro SIG o paquete de trazado),
(iv) incluso es susceptible de análisis en caso de que alguna vez haya preguntas sobre las relaciones entre estas opciones de etiquetas y cualquier otra variable, y
(v) al codificar parsimoniosamente la elección del cliente, no crea información duplicada.
Aquí hay algunos principios generales de construcción y gestión de bases de datos en funcionamiento , como se sugiere sabiamente en la pregunta. Una de ellas es que cualquier información coherente debe estar representada de manera única en la base de datos si es posible. (La información utilizada como claves para implementar uniones y relaciones, por supuesto, debe aparecer en varios lugares en virtud de su función como identificación de los registros correspondientes en diferentes tablas). Existen excelentes razones para este principio, como cualquier persona que haya intentado mantener un sistema no normalizado. la base de datos relacional puede dar fe: si no recuerda constantemente actualizar, eliminar o agregar esta información a cada En la tabla en la que aparece, su base de datos pronto se vuelve internamente inconsistente: está dañada, a menudo irremediablemente.
Otro principio es que en un buen diseño de base de datos relacional, cada tabla debe representar una sola "entidad" conceptual : algo que los datos están modelando o una relación entre esas cosas. Cuando un cliente especifica una selección de características aparentemente arbitraria, está especificando efectivamente un subconjunto de filas en una tabla. Matemáticamente, por el axioma de separación, esto es lo mismo que marcarlos con un campo booleano. Por lo tanto, cualquier subconjunto de cosas "arbitrario" significativo en una base de datos puede ser representado por un campo booleano y, por el contrario, dicho campo es una buena manera de almacenar subconjuntos (o selecciones) arbitrarios.
Otro principio es que debe preferir utilizar las capacidades de gestión de datos subyacentes del SIG para almacenar información . La alternativa es alguna ad hocmétodo basado en la capacidad del SIG para almacenar información dentro de sus "archivos de proyecto" o de alguna otra forma independiente. Un ejemplo típico de esto es la práctica de elegir y colocar manualmente las etiquetas deseadas. A menudo es rápido y fácil hacer esto. Los problemas surgen cuando se necesita un cambio o el trabajo necesita ser reproducido; una u otra de estas situaciones es prácticamente inevitable. La colocación manual de las etiquetas equivale a almacenar información (es decir, qué subconjunto de características debe etiquetarse) fuera del RDBMS de una manera extremadamente elíptica. A saber, la selección especificada únicamente por qué etiquetas aparecen y cuáles no. Piense cómo resolvería estos problemas siguientes:
El cliente quiere que las mismas etiquetas aparezcan en un mapa relacionado pero diferente, parte de un proyecto diferente.
Surge una pregunta sobre si las etiquetas están asociadas con algún otro atributo.
Después de realizar varios cambios en las etiquetas a lo largo del tiempo, se le solicita que vuelva a la versión original.
En estos casos, el trabajo involucrado para resolver el problema puede ser enorme: debe rehacer el etiquetado nuevamente, o realizar verificaciones cruzadas manuales en las tablas de la base de datos, o buscar y restaurar un antiguo archivo de proyecto archivado. Si las etiquetas se representaran con un campo booleano en la base de datos, el trabajo sería casi trivial.
