Güreştiğiniz şey dikey bölümlemektir. Bu, performansı artırmak için fiziksel bir veritabanı tasarım tekniğidir. Herhangi bir fiziksel veritabanı tasarım tekniğinde olduğu gibi uygulanabilirliği, optimize etmeye çalıştığınız belirli sorgulara ve bu tekniğin bunları optimize edip etmediğine bağlıdır. Mantıksal bir bakış açısıyla, eğer bu yeni alanlar varlığınız için aday anahtarına bağlıysa, o zaman ona ait olan gerçeklerdir. Öncelikle, günlük sayfa görünümleriyle ilgili gerçekler olduğunu doğrulamak için bu yeni alanların aday anahtarlarınızdaki işlevsel bağımlılığını tam olarak anladığınızdan emin olmalısınız. Eğer öyleyse, onları başka bir tabloya ayırmaya karar vermek, yalnızca performans hedeflerinize ulaşması durumunda yapılması gereken bir performans optimizasyonudur.
Genel olarak, bu yeni sütunları nadiren ve orijinal tablodaki diğer sütunlardan farklı şekilde sorgulayacaksanız dikey bölümleme kullanışlıdır. Bu sütunları, mevcut tablonuzla aynı PK’yı paylaşan başka bir tabloya yerleştirerek, bu yeni sütunları istediğinizde doğrudan sorgulayabilir ve bu yeni tablo için diskte sayfa başına daha fazla satır olacak Orijinal tablodaki tüm sütunlar bu satırlarda oturmayacak. Ancak, bu sütunları her zaman orijinal tablodaki sütunlarla birlikte sorgulayacaksanız, dikey bir bölüm bunları almak için her zaman dış birleştirmeye ihtiyaç duyacağınız kadar anlamlı olmaz. Diskteki tablolardan gelen sayfalar bir DBMS'nin arabellek havuzuna bağımsız olarak gelir, asla önceden katılamaz, ve böylece, arabellek, veriler arabellek havuzuna sabitlenmiş olsa bile, her sorgu yürütmesinde gerçekleşmesi gerekir. Bu senaryoda, orijinal tablodaki NULLABLE sütunların yapılması, NULL olduğunda DBMS depolama motorunun verimli bir şekilde saklanmasını ve alımda katılma gereksinimini ortadan kaldırmasını sağlayacaktır.
Bana sanki kullanım durumunuz ikincisi gibi geliyor ve orijinal tablonuza NULLABLE olarak ekleyerek gitmek yoludur. Ancak, veritabanı tasarımındaki diğer her şeyde olduğu gibi, bu duruma bağlıdır ve doğru kararı vermek için beklenen iş yükünüzü ve iyi bir seçim yapmanın neye bağlı olduğunu bilmeniz gerekir. Dikey bölümleme için uygun bir kullanım durumunun iyi bir örneği, uygulamanızın birinin aramak isteyebileceği ancak nadiren yapabileceği bir kişi hakkında çok nadiren doldurulmuş bir bilgiye sahip olduğu bir kişi arama paneli olabilir. Bu bilgiyi farklı bir tabloya yerleştirirseniz, performans için bazı iyi seçeneklere sahip olursunuz. Aramayı, 2 sorgunuz olacak şekilde yazabilirsiniz - bir tanesi arama yapmak için her zaman en çok kullanılan bilgileri kullanan (yalnızca soyadı veya ssn gibi), ve dıştaki çok nadir bulunan bilgileri yalnızca arama istendiğinde birleştirir. Veya, dış birleştirme işleminin gerekli olmadığı ve gerçekleştirmeyeceği belli bir dizi ana bilgisayar değişkenini tanımak için yeterince akıllısa, DBMS iyileştiricisinden faydalanabilirsiniz ve bu nedenle yalnızca 1 sorgu oluşturmanız gerekir.
Hangi DBMS platformunu kullanıyorsunuz? Platformun NULL sütun depolamasını işleme şekli, sorgunuzu optimize eder ve ayrıca seyrek sütun desteğinin kullanılabilirliği (SQL Server buna sahiptir) kararı etkileyecektir. Sonuç olarak, her iki tasarımın da test ortamında, üretim büyüklüğü verileri ve iş yükü ile denenmesini ve hangisinin performans hedeflerinize daha iyi ulaşacağını görmenizi öneririm.