Gagasan kedua (untuk membuat atribut boolean untuk seleksi) memiliki banyak keuntungan :
(i) secara jelas mendokumentasikan apa yang perlu diberi label,
(ii) itu permanen dan portabel seperti dataset yang mendasarinya,
(iii) ini menyediakan mekanisme sederhana dan langsung untuk menentukan label mana yang akan muncul (yang bahkan portabel untuk GIS lain atau paket plot),
(iv) bahkan dapat menerima analisis jika ada pertanyaan tentang hubungan antara pilihan label ini dan variabel lainnya, dan
(v) dengan menyandikan secara ketat pilihan klien, itu tidak membuat informasi rangkap.
Ada beberapa prinsip konstruksi dan manajemen basis data umum yang bekerja di sini , sebagaimana disarankan secara bijaksana dalam pertanyaan. Salah satunya adalah bahwa setiap informasi yang masuk akal harus diwakili secara unik dalam database jika memungkinkan. (Informasi yang digunakan sebagai kunci untuk menerapkan gabungan dan hubungan tentu saja harus muncul di banyak tempat berdasarkan fungsinya sebagai mengidentifikasi catatan yang sesuai dalam tabel yang berbeda.) Ada alasan yang sangat baik untuk prinsip ini, karena siapa pun yang telah berusaha mempertahankan non-normalisasi database relasional dapat membuktikan: jika Anda tidak secara konsisten ingat untuk memperbarui atau menghapus atau menambahkan informasi ini ke setiap orang tabel di mana ia muncul, database Anda segera menjadi tidak konsisten secara internal: itu rusak, sering kali tidak dapat diperbaiki.
Prinsip lain adalah bahwa dalam desain basis data relasional yang baik, setiap tabel harus mewakili "entitas" konseptual tunggal : sesuatu yang dimodelkan data atau hubungan di antara hal-hal itu. Ketika klien menentukan pilihan fitur yang tampaknya sewenang-wenang, mereka secara efektif menentukan subset baris dalam tabel. Secara matematis, dengan aksioma pemisahan ini sama dengan menandai mereka dengan bidang boolean. Dengan demikian, setiap subset "sewenang-wenang" yang bermakna dalam suatu basis data dapat diwakili oleh bidang boolean dan, sebaliknya, bidang tersebut adalah cara yang baik untuk menyimpan subset (atau pilihan) sewenang-wenang.
Namun prinsip lain adalah Anda sebaiknya memilih menggunakan kemampuan manajemen data yang mendasari SIG untuk menyimpan informasi . Alternatifnya adalah beberapa ad hocmetode berdasarkan pada kemampuan GIS untuk menyimpan informasi dalam "file proyek" atau dengan cara independen lainnya. Contoh khas dari ini adalah praktik memilih dan menempatkan label yang diinginkan secara manual. Seringkali ini cepat dan mudah dilakukan. Masalah muncul ketika salah satu perubahan diperlukan atau pekerjaan perlu direproduksi; salah satu dari situasi ini praktis tidak bisa dihindari. Penempatan label secara manual sama dengan menyimpan informasi (yaitu, subset fitur apa yang harus diberi label) di luar RDBMS dengan cara yang sangat elips. Yaitu, pemilihan yang ditentukan hanya oleh label mana yang muncul dan mana yang tidak. Pikirkan bagaimana Anda akan menyelesaikan masalah berikut ini:
Klien ingin label yang sama muncul di peta yang terkait tetapi berbeda, bagian dari proyek yang berbeda.
Muncul pertanyaan apakah label dikaitkan dengan beberapa atribut lainnya.
Setelah membuat beberapa perubahan pada label dari waktu ke waktu, Anda diminta untuk kembali ke versi aslinya.
Dalam kasus ini, pekerjaan yang terlibat untuk menyelesaikan masalah bisa sangat besar: Anda harus mengulang kembali pelabelan, atau melakukan pemeriksaan silang secara manual terhadap tabel database, atau menemukan dan mengembalikan file proyek yang diarsipkan lama. Jika label yang diwakili oleh bidang boolean dalam database, pekerjaan itu malah hampir sepele.
