Bire bir ilişki normalleştirilmiş mi?

Bir kayıt için geniş bir istatistiksel veri setimiz olduğunu düşünün; örneğin 20-30 INTsütun. Hepsi bir kayda ait olduğundan VEYA bire bir ilişkiyle bağlantılı başka bir tablo oluşturarak tüm seti bir tabloda tutmak daha iyidir.

Birincisinin avantajı JOIN, ilgili kayıt için tüm istatistiksel verilere engel olmak ve bunlara hızlı bir şekilde erişmektir.

İkincisinin avantajı sütunu düzenli tutmaktır. İlk sütun okuma yoğun, ikincisi yazma yoğun. Tabii ki, InnoDB'yi satır düzeyinde engelleme ile kullandığım için performans üzerinde önemli bir etkisi olmadığını düşünüyorum.

Genel olarak, tek bir kayıt için farklı veri kümelerini ayırmanın faydalı olup olmadığını bilmek istiyorum.

Normalleştirme kurallarına uyuyorsa, 1: 1 ilişkiler normalleştirilebilir (tanım gereği!) - Başka bir deyişle, 1: 1 ilişkiler hakkında normal formlara uymalarını imkansız kılan hiçbir şey yoktur.

1: 1 ilişkilerinin pratikliği hakkındaki sorunuzu yanıtlamak için, bunun farklı tahminlere (sütunlara) sahip alt türleriniz olduğu gibi, son derece yararlı bir yapı olduğu zamanlar vardır.

1: 1 ilişkilerini kullanmanızın nedenleri bakış açınıza bağlıdır. DBA'lar her şeyi performans kararı olarak görme eğilimindedir. Veri modelleyicileri ve programcıları bu kararları tasarım veya model odaklı olarak görme eğilimindedir. Aslında, bu bakış açıları arasında çok fazla çakışma var. Bu, bakış açılarınızın ve önceliklerinizin ne olduğuna bağlıdır. İşte 1: 1 ilişkiler için bazı motivasyon örnekleri:

• Çok geniş bazı sütun alt kümeniz var ve performans nedenleriyle bunları depolama alanınızda fiziksel olarak ayırmak istiyorsunuz.

• Sık okunmayan veya güncellenmeyen bazı sütun alt kümeleriniz var ve bunları performans nedenleriyle sık kullanılan sütunlardan ayrı tutmak istiyorsunuz.

• Genel olarak isteğe bağlı bazı sütunlarınız var, ancak kaydın belirli bir türde olduğunu bildiğinizde bunlar zorunludur.

• Mantıksal olarak bir alt tür için ait olan bazı sütunlarınız var ve bunları kodunuzun nesne modeline uyacak şekilde modellemek istiyorsunuz.

• Süper varlık türünün yalnızca bazı alt türlerine uygulanabilecek bazı sütunlarınız vardır ve şemanızın bu alt türler için bu verilerin yokluğunu zorunlu kılmasını istersiniz.

• Bir varlığa ait bazı sütunlarınız var, ancak bu kısıtlayıcı sütunları daha kısıtlayıcı erişim kuralları (örn. Çalışan tablosunda maaş) kullanarak korumanız gerekiyor.

Gördüğünüz gibi, bazen sürücü performans, bazen model saflığı veya sadece bildirim şeması kurallarından tam olarak yararlanma arzusu.

Büyük bir tabloyu ikiye bölmek için bire bir eşleme kullanmanızın başlıca nedenleri performans nedenlerinden kaynaklanmaktadır:

a) Tablo, sık erişilen bir tabloda ikili / clob / blob verilerine sahiptir, bu nedenle büyük sütunlar farklı şekilde işlendiği için performansı düşürür.

b) Tablonun farklı sorgular tarafından erişilen birçok sütunu vardır, bu nedenle performans düşer, dolayısıyla erişim performansını artırmak için ilgili sütunları ayrı bir tabloya taşırsınız

Bununla birlikte, birçok tamsayı sütuna sahip olmak, tabloyu ayrı tablolara bölmek ve bunları sorgulamak zorunda kalmanın ek çabalarını haklı çıkarmaz.