Eski bir kod tabanında yeni bir gereksinim ortaya çıkmıştır, bu da temel olarak doğrudan ilişkili olmayan iki kullanıcı sınıfı arasında (tamamen farklı şemaya sahip farklı tablolarda depolanmıştır ve ne yazık ki kod neredeyse OO-farkındadır, daha az tasarlandığından ebeveyn sınıfı yoktur). Bu işlevselliği asla dikkate almayan bu eski düzene bir çanta asacağımız için, PK çarpışması olmadığının garantisi yoktur - kullanımdaki veri kümesi göz önüne alındığında, pratikte olduğu garanti edilir.
Yani, çözüm açık görünüyor: ateşle öldürün ve tüm karışıklığı yeniden yazın Bir eşleme tablosu. Haritayı uygulamanın olası yolları için iki yön aldım, ama ben bir DBA değilim, bu yüzden kaçırdığım herhangi bir artı ve eksileri olup olmadığından emin değilim.
Soyutlamayı açıklığa kavuşturmak için üç farklı kullanıcı verisi grubunu düşünün: Profesörler, Yönetim, Öğrenciler (Hayır, bu bir ev ödevi değil. Söz ver!)
Haritalama 1
(professor_id, admin_id ve student_id ilgili tablolarının yabancı anahtarlarıdır)
| mailing_id (KEY) | professor_id | admin_id | student_id |
-------------------------------------------------------
| 1001 | NULL | 87 | NULL |
| 1002 | 123 | NULL | NULL |
| 1003 | NULL | NULL | 123 |
Bu yaklaşımın +/- eksileri üzerinde oldukça ağır görünüyor:
- Satır başına iki "boşa" alanı
- İhlal 2NF
- Anormallikler eklemek / güncellemek için güvenlik açığı (yalnızca 0-1 alan NULL olarak ayarlanmış bir satır, ör.)
Profesyoneller kendi yararları olmadan değiller:
- Haritalama tek bir arama ile gerçekleştirilebilir
- Mailing_id'den belirli bir kullanıcı için "kaynak" verileri kolayca belirleyin
Gerçeği söylemek gerekirse, bağırsaklarımda, bu fikri hiç sevmiyorum.
Haritalama 2
(MSG_ * 'nın tanımlanmış sabitler, numaralandırma türleri veya başka bir uygun tanımlayıcı olduğunu varsayalım)
| mailing_id (KEY) | user_type (UNIQUE1) | internal_id (UNIQUE2)|
------------------------------------------------------------------
| 1001 | MSG_ADMIN | 87 |
| 1002 | MSG_PROF | 123 |
| 1003 | MSG_STUDENT | 123 |
Bu kurulum ve {user_type, internal_id} öğelerinin benzersiz bir bileşik dizini çok daha temiz hale gelir, 3NF korunur ve uygulama kodunun I / U anormalliklerini kontrol etmesi gerekmez.
Dezavantajlı olarak, DB dışında ele alınması gereken kullanıcı kaynak tablolarının belirlenmesinde, temel olarak kullanıcı_türü değerlerinin tablolarla uygulama düzeyinde eşleştirilmesine denk gelen bir miktar şeffaflık kaybı vardır. Şu anda, (oldukça güçlü bir şekilde) bu 2. haritaya doğru eğildim, çünkü olumsuz oldukça küçük.
AMA kendi sınırlamalarımın acı verici bir şekilde farkındayım ve muhtemelen her iki yönde de avantajları veya tökezleyen blokları kaçırdığımdan eminim, bu yüzden benimkinden daha akıllı zihinlere yöneliyorum.