İlişkisel veritabanlarındaki arama tablolarıyla ilgili en iyi uygulamalar nelerdir?

Arama tabloları (veya bazılarının dediği gibi kod tabloları ) genellikle belirli bir sütun için verilebilecek olası değerlerin toplamıdır.

Örneğin party, iki sütunu olan (siyasi partiler hakkında bilgi depolamak için) adlı bir arama tablonuz olduğunu varsayalım :

• party_code_idn, sistem tarafından oluşturulan sayısal değerleri tutar ve ( iş alanı anlamından yoksundur ) gerçek anahtar için bir vekil olarak çalışır.
• party_code, iş alanı çağrışımları olan değerleri koruduğu için tablonun gerçek veya "doğal" anahtarıdır .

Ve böyle bir tablonun aşağıdaki verileri sakladığını söyleyelim:

 +----------------+------------+
 | party_code_idn | party_code |
 +----------------+------------+
 |              1 | Republican |
 |              2 | Democratic |
 +----------------+------------+

party_codeDeğerler 'Cumhuriyet' ve 'Demokratik', tablonun gerçek tuşu olan UNIQUE sınırlamasıyla kurulur, ama isteğe bağlı olarak ilave tutar sütun, party_code_idnve olsa masanın (bir PK olarak tanımlanan mantıksal konuşma , party_codePRIMARY KEY [PK]) olarak çalışabilir.

Soru

İşlem tablolarından arama değerlerine işaret etmenin en iyi uygulamaları nelerdir ? YABANCI ANAHTAR (FK) ya (a) doğrudan doğal ve anlamlı değere ya da (b) değerleri aşmak için referanslar oluşturmalı mıyım ?

Seçenek (a) , örneğin,

 +---------------+------------+---------+
 | candidate_idn | party_code |  city   |
 +---------------+------------+---------+
 |             1 | Democratic | Alaska  |
 |             2 | Republican | Memphis |
 +---------------+------------+---------+

aşağıdaki özelliklere sahiptir ¹ :

1. Son kullanıcı için okunabilir (+)
2. Sistemler arasında kolay ithalat-ihracat (+)
3. Tüm referans tablolarında değişiklik yapılması gerektiğinden değeri değiştirmek zor (-)
4. Yeni değer eklemek pahalı değildir (=)

Uygulama programlama jargonunda fonksiyon çağrısından bir benzetme yapmak neredeyse “ değere göre geç ” gibi bir şey .

Seçenek (b) , örneğin,

 +---------------+----------------+---------+
 | candidate_idn | party_code_idn |  city   |
 +---------------+----------------+---------+
 |             1 |              1 | Alaska  |
 |             2 |              2 | Memphis |
 +---------------+----------------+---------+

aşağıdaki özelliklere sahiptir:

1. Son kullanıcı için okunamıyor (-)
2. İhtiyaç duymamamız gerektiğinden ithalat-ihracat yapmak zor (-)
3. Yalnızca işlem tablolarında referansları depoladığımız için değerleri değiştirmek kolaydır (+)
4. Yeni değer eklemek pahalı değildir (=)

Uygulama programlama bölümünde fonksiyon çağrısı ile karşılaştırıldığında " referans ile geç " e çok benzer .

İthalat-İhracat da farklı bir şekilde yapılabilir, yani sadece arama tablosunu tekrar doldurarak ve sonra vekil sütunu yeniden tohumlayabilirsiniz. Umarım bunu doğru anlıyorum, bu bir olasılık olarak duyduğum bir şey.

_{1. Not olduğunu +, -ve =bu özelliklerin yararını göstermektedir.}

Soru

Oldukça önemli: Eğer ikinci yaklaşımı kullanacaksak, bir arama (veya kod ) tablosu ile FK referansı arasında bir fark var mıdır ? Bence aynı şekilde çalışıyorlar.

Alakalı kaynaklar

• Arama Tabloları Ne Kadar Önemli?

• Kod veya Arama Tablolarıyla En İyi Uygulamalar

• Arama Tabloları En İyi Uygulamalar DB Tabloları veya Numaralandırmalar

By IDNSanırım sen bir demek IDENTITY, SEQUENCEya da AUTO_INCREMENTalan? Buraya ve buraya bir bakmalısın .

Şekil 10 altında, ilk başvurunun 5. bölümüne (Veri değerlerini Veri Öğesi Olarak Yanlış Kullanma) dikkat edin

Tabii ki satış personeli için ayrı bir masaya sahip olabilir ve daha sonra, yukarıda gösterilen sales_person_id gibi basit bir yedek anahtarla yabancı bir anahtar kullanarak referans verebilirsiniz.

Bu nedenle, bu uzman anahtarları "ertelemeniz" gerektiğini düşünüyor. Gerçekten oldukça basit bir SQL tekniğidir ve günlük SQL'inizde sorunlara neden olmamalıdır. Şekil 10'da bir hata var gibi görünüyor - SalesData'daki sales_person metni değil bir yedek anahtar (yani bir sayı) olmalıdır. Bunu yukarıdaki alıntıdan çıkarım.

Her ne pahasına olursa olsun kaçınmalısınız ne (1) Ortak Arama Tabloları bölümünde özetlenen hatayı taahhüt cazip (acemi veritabanı programcıları için çok yaygın). Bu genellikle MUCK ( Devasa Birleştirilmiş Kod Anahtarı ) yaklaşımı olarak adlandırılır ( kazara değil :-), özellikle Joe Celko tarafından , OTLT - Bir Gerçek Arama Tablosu olarak da bilinir ) ve her türlü zorluğa yol açar. Acemi programcıları tek bir kod / arama / herhangi bir tablonun "temiz" olduğunu ve gerçeğin ötesinde bir şey olmadığında daha verimli olacağını düşünüyorlar.

Yukarıdaki ikinci referanstan:

Normalleştirme gereksiz verileri ortadan kaldırır, böylece veri bütünlüğünü zorlama görevini çok daha basit hale getirir, ancak bir MUCK oluşturma işlemi tamamen başka bir şeydir. göstereceğim gibi, daha az tablo basitlik eşit değildir.

Burada ele aldığım ilgili EAV ( Varlık Öznitelik Değeri ) paradigmasına da göz atmak isteyebilirsiniz .

İki seçeneğinizin avantajlarından bazılarına sahip olan üçüncü bir yaklaşım var - kod tablosuna gerçek bir kod koyun. Bununla, tam değerin özünü yakalayan ve benzersiz olan kısa bir karakter dizisini kastediyorum. Verdiğiniz örnek için,

Idn: 1
Name: Democrats
Code: D      (or DEM)

Kod, yabancı anahtar olarak işlem tablolarına taşınır. Kısa, anlaşılır ve "gerçek" verilerden biraz bağımsızdır. Bir adda yapılan artımlı değişiklikler, kod değişikliği yapılmasını önermez. Ancak Cumhuriyetçiler topluca çökerse , yedek bir kimliğin oluşmayacağı sorunlarıyla birlikte bir kod değişikliği gerekli olabilir.

Bu stile kısaltma kodlaması denir. Celko'nun bu konudaki yazısını önerebilirim. Google kitaplar çeşitli örneklere sahiptir. Arama sonucu "Celko encoding".

Diğer örnekler: ülkeler için 2 veya 3 harfli kodlama, para birimi kodları için 3 harfli kodlama (GBP, USD, EUR). Kısa, kendi kendini açıklayan ve değişmeyen (ve onlar için bir ISO var).