La seconda idea (per creare un attributo booleano per la selezione) presenta molti vantaggi :
(i) documenta chiaramente ciò che deve essere etichettato,
(ii) è permanente e portatile come il set di dati sottostante,
(iii) fornisce un meccanismo semplice e diretto per determinare quali etichette appariranno (che è persino portabile su un altro GIS o pacchetto di stampa),
(iv) è anche suscettibile di analisi nel caso in cui ci siano mai domande sulle relazioni tra queste scelte di etichette e qualsiasi altra variabile, e
(v) codificando parsimoniosamente la scelta del cliente, non crea informazioni duplicate.
Ci sono alcuni principi generali di costruzione e gestione del database al lavoro qui , come saggiamente suggerito nella domanda. Uno di questi è che qualsiasi informazione coerente dovrebbe essere rappresentata in modo univoco nel database, se possibile. (Le informazioni utilizzate come chiavi per implementare i join e le relazioni ovviamente devono apparire in più punti in virtù della sua funzione di identificazione dei record corrispondenti in diverse tabelle.) Vi sono eccellenti ragioni per questo principio, in quanto chiunque abbia tentato di mantenere un valore non normalizzato il database relazionale può attestare: se non ricordi costantemente di aggiornare o rimuovere o aggiungere queste informazioni a tutti tabella in cui appare, il tuo database diventa presto incoerente internamente: è danneggiato, spesso irrimediabilmente così.
Un altro principio è che in una buona progettazione di database relazionali, ogni tabella dovrebbe rappresentare una singola "entità" concettuale : qualcosa che i dati stanno modellando o una relazione tra quelle cose. Quando un client specifica una selezione apparentemente arbitraria di funzionalità, specifica in modo efficace un sottoinsieme di righe in una tabella. Matematicamente, per l' assioma della separazione, ciò equivale a segnalarli con un campo booleano. Pertanto, qualsiasi sottoinsieme "arbitrario" di cose in un database può essere rappresentato da un campo booleano e, al contrario, un tale campo è un buon modo per memorizzare sottoinsiemi (o selezioni) arbitrari.
Un altro principio è che dovresti preferire utilizzare le capacità di gestione dei dati sottostanti del GIS per archiviare informazioni . L'alternativa è un po ' ad hocmetodo basato sulla capacità del GIS di memorizzare informazioni all'interno dei suoi "file di progetto" o in qualche altro modo indipendente. Un tipico esempio di ciò è la pratica di scegliere e posizionare manualmente le etichette desiderate. Spesso è facile e veloce farlo. I problemi sorgono ogni volta che è necessario un cambiamento o il lavoro deve essere riprodotto; l'una o l'altra di queste situazioni è praticamente inevitabile. Il posizionamento manuale delle etichette equivale alla memorizzazione di informazioni (vale a dire, quale sottoinsieme di funzioni dovrebbe essere etichettato) all'esterno di RDBMS in modo estremamente ellittico. Vale a dire, la selezione specificata esclusivamente da quali etichette compaiono e quali no. Pensa a come risolvere questi problemi successivi:
Il cliente desidera che le stesse etichette vengano visualizzate in una mappa correlata ma diversa, parte di un progetto diverso.
Sorge una domanda se le etichette siano associate ad altri attributi.
Dopo aver apportato diverse modifiche alle etichette nel tempo, ti viene chiesto di ripristinare la versione originale.
In questi casi, il lavoro necessario per risolvere il problema può essere enorme: è necessario ripetere nuovamente l'etichettatura o eseguire controlli incrociati manuali su tabelle di database o trovare e ripristinare un vecchio file di progetto archiviato. Se le etichette fossero invece rappresentate da un campo booleano nel database, il lavoro sarebbe invece quasi banale.
