İkinci fikrin (seçim için bir boolean niteliği oluşturmak için) birçok avantajı vardır :
(i) neyin etiketlenmesi gerektiğini açıkça belgeliyorsa,
(ii) temel alınan veri kümesi kadar kalıcı ve taşınabilir olması,
(iii) hangi etiketlerin görüneceğini belirlemek için basit ve doğrudan bir mekanizma sağlar (hatta başka bir CBS veya çizim paketine taşınabilir),
(iv) bu etiket seçimleri ile diğer değişkenler arasındaki ilişkiler hakkında herhangi bir soru olması durumunda analize bile uygundur ve
(v) müşterinin seçimini eşzamanlı olarak kodlayarak, yinelenen bilgi oluşturmaz.
Burada akıllıca önerildiği gibi , bazı genel veri tabanı yapım ve yönetim ilkeleri vardır . Bunlardan biri, tutarlı bir bilgi parçasının mümkünse veritabanında benzersiz bir şekilde temsil edilmesi gerektiğidir . (Elbette birleştirmeleri ve ilişkilendirmeleri uygulamak için anahtar olarak kullanılan bilgiler, farklı tablolarda karşılık gelen kayıtları tanımlama işlevi nedeniyle birden fazla yerde görünmelidir.) Bu ilkenin, normalleştirilmemiş bir koruma sağlamaya çalışan herkes için mükemmel nedenleri vardır. ilişkisel veritabanı şunları kanıtlayabilir: Bu bilgileri her zaman güncellemeyi, kaldırmayı veya eklemeyi hatırlamıyorsanız göründüğü tablo, veritabanınız yakında dahili olarak tutarsız hale gelir: bozuk, genellikle geri döndürülemez şekilde.
Diğer bir ilke, iyi bir ilişkisel veritabanı tasarımında, her tablonun tek bir kavramsal "varlığı" temsil etmesi gerektiğidir : verinin modellediği bir şey veya bu şeyler arasında bir ilişki. İstemci, görünüşte keyfi bir özellik seçimi belirlediğinde, bir tablodaki satırların alt kümesini etkili bir şekilde belirtir. Matematiksel olarak, ayrılık aksiyomu ile bu, onları bir boole alanıyla işaretlemekle aynıdır. Bu nedenle, bir veritabanındaki şeylerin anlamlı herhangi bir "keyfi" alt kümesi, bir boole alanı ile temsil edilebilir ve tersine, böyle bir alan, keyfi alt kümeleri (veya seçimleri) depolamanın iyi bir yoludur.
Yine bir başka ilke, bilgi depolamak için CBS'nin temel veri yönetimi yeteneklerini kullanmayı tercih etmenizdir . Alternatif bazı geçiciyöntemi, CBS'nin "proje dosyaları" içinde veya başka bir bağımsız yolla bilgi depolayabilme yeteneğine dayanmaktadır. Bunun tipik bir örneği, istenen etiketleri manuel olarak seçme ve yerleştirme pratiğidir. Genellikle bunu yapmak hızlı ve kolaydır. Sorunlar, bir değişikliğe ihtiyaç duyulduğunda veya işin yeniden üretilmesi gerektiğinde ortaya çıkar; bu durumlardan biri ya da diğeri pratikte kaçınılmazdır. Etiketlerin manuel olarak yerleştirilmesi, RDBMS dışında son derece eliptik bir şekilde bilgi depolamakla (yani, hangi özellik alt kümesinin etiketlenmesi gerektiği) eşdeğerdir. Yani, seçim yalnızca hangi etiketlerin görüneceği ve hangilerinin görünmeyeceği ile belirtilir. Daha sonra bu takip sorunlarını nasıl çözeceğinizi düşünün:
Müşteri, aynı etiketlerin farklı bir projenin parçası olan ilgili ancak farklı bir haritada görünmesini istiyor.
Etiketlerin başka bir özellikle ilişkilendirilip ilişkilendirilmediği sorusu ortaya çıkar.
Zaman içinde etiketlerde birkaç değişiklik yaptıktan sonra, orijinal sürüme geri dönmeniz istenir.
Bu durumlarda, sorunu çözmek için yapılan çalışmalar çok büyük olabilir: etiketlemeyi tekrar tekrar yapmanız veya veritabanı tablolarına karşı manuel çapraz kontroller yapmanız veya eski bir arşivlenmiş proje dosyasını bulup geri yüklemeniz gerekir. Etiketler bunun yerine veritabanındaki bir boole alanı ile temsil edildiyse, çalışma neredeyse önemsiz olurdu.
