La deuxième idée (pour créer un attribut booléen pour la sélection) présente de nombreux avantages :
(i) il documente clairement ce qui doit être étiqueté,
(ii) il est aussi permanent et portable que l'ensemble de données sous-jacent,
(iii) il fournit un mécanisme simple et direct pour déterminer quelles étiquettes apparaîtront (ce qui est même portable sur un autre SIG ou ensemble de traçage),
(iv) il peut même être analysé au cas où il y aurait des questions sur les relations entre ces choix d'étiquettes et toute autre variable, et
(v) en codant avec parcimonie le choix du client, il ne crée aucune information en double.
Il y a quelques principes généraux de construction et de gestion de base de données à l'œuvre ici , comme le suggère judicieusement la question. L'un d'eux est que toute information cohérente doit être représentée de manière unique dans la base de données si possible. (Informations utilisées comme clés pour mettre en œuvre des jointures et concerne bien sûr doit apparaître à plusieurs endroits en vertu de sa fonction d' identification des enregistrements correspondants dans différents tableaux.) Il y a d' excellentes raisons de ce principe, comme toute personne qui a tenté de maintenir un non normalisé base de données relationnelle peut attester: si vous ne vous souvenez pas toujours de mettre à jour ou supprimer ou ajouter ces informations à tous les dans laquelle il apparaît, votre base de données devient vite incohérente: elle est corrompue, souvent de manière irrémédiable.
Un autre principe est que dans une bonne conception de base de données relationnelle, chaque table doit représenter une seule "entité" conceptuelle : quelque chose que les données modélisent ou une relation entre ces choses. Lorsqu'un client spécifie une sélection apparemment arbitraire de fonctionnalités, il spécifie effectivement un sous-ensemble de lignes dans une table. Mathématiquement, par l' axiome de la séparation, cela revient à les signaler avec un champ booléen. Ainsi, tout sous-ensemble significatif "arbitraire" de choses dans une base de données peut être représenté par un champ booléen et, inversement, un tel champ est un bon moyen de stocker des sous-ensembles (ou sélections) arbitraires.
Encore un autre principe est que vous devriez préférer utiliser les capacités sous-jacentes de gestion des données du SIG pour stocker des informations . L'alternative est une ad hocméthode basée sur la capacité du SIG à stocker des informations dans ses "fichiers de projet" ou d'une autre manière indépendante. Un exemple typique de ceci est la pratique de choisir et de placer manuellement les étiquettes souhaitées. C'est souvent rapide et facile à faire. Les problèmes surviennent chaque fois qu'un changement est nécessaire ou que l'œuvre doit être reproduite; l'une ou l'autre de ces situations est pratiquement inévitable. Le placement manuel des étiquettes revient à stocker des informations (à savoir, quel sous-ensemble de fonctionnalités doit être étiqueté) en dehors du SGBDR d'une manière extrêmement elliptique. A savoir, la sélection spécifiée uniquement par laquelle les étiquettes apparaissent et celles qui ne le font pas. Réfléchissez à la façon dont vous pourriez alors résoudre ces problèmes de suivi:
Le client souhaite que les mêmes étiquettes apparaissent dans une carte associée mais différente, faisant partie d'un projet différent.
Une question se pose de savoir si les étiquettes sont associées à un autre attribut.
Après avoir apporté plusieurs modifications aux étiquettes au fil du temps, vous êtes invité à revenir à la version d'origine.
Dans ces cas, le travail nécessaire pour résoudre le problème peut être énorme: vous devez recommencer l'étiquetage à nouveau, ou effectuer des recoupements manuels avec les tables de base de données, ou rechercher et restaurer un ancien fichier de projet archivé. Si les étiquettes étaient plutôt représentées par un champ booléen dans la base de données, le travail serait à la place presque trivial.
