Drugi pomysł (stworzenie atrybutu logicznego do wyboru) ma wiele zalet :
(i) wyraźnie dokumentuje, co należy oznakować,
(ii) jest tak trwały i przenośny jak podstawowy zbiór danych,
(iii) zapewnia prosty i bezpośredni mechanizm określania, które etykiety pojawią się (które można nawet przenosić na inny system GIS lub pakiet wydruku),
(iv) możliwa jest nawet analiza na wypadek, gdyby kiedykolwiek pojawiły się pytania dotyczące związków między tymi wyborami etykiet a innymi zmiennymi oraz
(v) przez oszczędne kodowanie wyboru klienta nie tworzy duplikatów informacji.
Działają tu pewne ogólne zasady budowy i zarządzania bazami danych , jak mądrze zasugerowano w pytaniu. Jednym z nich jest to, że każda spójna informacja powinna być w unikalny sposób reprezentowana w bazie danych, jeśli to możliwe. (Informacje używane jako klucze do implementacji sprzężeń i relacji muszą oczywiście pojawiać się w wielu miejscach ze względu na swoją funkcję identyfikowania odpowiednich rekordów w różnych tabelach.) Istnieją doskonałe powody tej zasady, ponieważ każdy, kto próbował utrzymać nienormalizowane relacyjna baza danych może poświadczyć: jeśli nie pamiętasz konsekwentnie o aktualizowaniu, usuwaniu lub dodawaniu tych informacji do każdego tabeli, w której się pojawia, twoja baza danych wkrótce staje się wewnętrznie niespójna: jest uszkodzona, często nieodwracalnie.
Inną zasadą jest to, że w dobrym projekcie relacyjnej bazy danych każda tabela powinna reprezentować pojedynczy koncepcyjny „byt” : coś, co modelują dane lub związek między tymi rzeczami. Gdy klient określa pozornie arbitralny wybór funkcji, skutecznie określa podzbiór wierszy w tabeli. Matematycznie przez aksjomat separacji jest to to samo, co oznaczanie ich polem boolowskim. Tak więc każdy znaczący „arbitralny” podzbiór rzeczy w bazie danych może być reprezentowany przez pole boolowskie i, przeciwnie, takie pole jest dobrym sposobem do przechowywania dowolnych podzbiorów (lub selekcji).
Jeszcze inną zasadą jest to, że powinieneś preferować wykorzystanie podstawowych funkcji zarządzania danymi GIS do przechowywania informacji . Alternatywą jest trochę ad hocmetoda oparta na zdolności GIS do przechowywania informacji w „plikach projektu” lub w inny niezależny sposób. Typowym tego przykładem jest praktyka ręcznego wybierania i umieszczania pożądanych etykiet. Często jest to szybkie i łatwe. Problemy pojawiają się za każdym razem, gdy potrzebna jest zmiana lub trzeba odtworzyć utwór; jedna lub druga z tych sytuacji jest praktycznie nieunikniona. Ręczne umieszczanie etykiet jest równoznaczne z przechowywaniem informacji (a mianowicie, jaki podzbiór funkcji powinien być oznaczony) poza RDBMS w sposób wyjątkowo eliptyczny. Mianowicie, wybór określony wyłącznie według tego, które etykiety się pojawiają, a które nie. Zastanów się, jak możesz rozwiązać następujące problemy:
Klient chce, aby te same etykiety pojawiały się na powiązanej, ale innej mapie, będącej częścią innego projektu.
Powstaje pytanie, czy etykiety są powiązane z jakimś innym atrybutem.
Po wprowadzeniu kilku zmian w etykietach w czasie pojawi się monit o przywrócenie oryginalnej wersji.
W takich przypadkach praca związana z rozwiązaniem problemu może być ogromna: musisz powtórzyć etykietowanie od nowa, ręcznie wykonać kontrole krzyżowe w tabelach bazy danych lub znaleźć i przywrócić stary zarchiwizowany plik projektu. Gdyby zamiast tego etykiety były reprezentowane przez pole logiczne w bazie danych, praca byłaby prawie banalna.
