Bire bir ilişkileri yoğunlaştırmak hiç mantıklı gelmiyor mu?

Tablo B ile bire bir ilişkisi olan Tablo A'ya sahipsek, onları ayırmak hiç mantıklı geliyor mu? Yoksa onları tek bir masaya birleştirmek asla acıtmaz mı? Bu senaryolardan herhangi biri (birleştirilmiş tabloya karşı iki tablo) normal biçimiyle (1NF, 2NF, 3NF, vb.) İlgili herhangi bir şeyi etkiliyor mu?

Evet, bunun daha iyi tasarım olmasının birçok nedeni var.

Devralma / uzatma ilişkiniz olabilir, örneğin bir Usertablonuz ve daha sonra Administratordaha fazla alana sahip bir tablonuz olabilir . Her iki tablonun da birincil Kullanıcı Kimliği anahtarı olabilir (ve bu nedenle 1: 1 ilişkisi olabilir) ancak tüm kullanıcıların Administratortabloda bir kaydı olmayacaktır . Bir iş akışını destekliyorsanız benzer bir şeye ihtiyacınız vardır, örneğin bir ScheduledTasktablo ve CompletedTasktablo.

Sık kullanılan veriler için hafif bir tabloya Userve daha sonra çok sık ihtiyacınız olmayan ayrıntılar için daha büyük bir tabloya sahip olmak isteyebilirsiniz UserDetails. Tek bir veri sayfasına daha fazla kayıt sığdırabileceğiniz için bu performansı artırabilir.

Tablolar için farklı izinler isteyebilirsiniz, örneğin UserveUserCredentials

Farklı yedekleme stratejileri istiyor ve bu nedenle örneğin farklı bölümleri üzerinde iki tablo koyabilir TransactionveTransactionArchive

Tek bir tabloda desteklenenden daha fazla sütuna ihtiyacınız olabilir; örneğin, dizine eklemeniz gereken çok sayıda büyük metin sütunu varsa ve DB platformunuz 4K veri sayfaları veya whathaveyou ile sınırlıysa.

@ John-wu'nun mükemmel cevabına bir başka ek olarak, başka bir sebep de resim gibi A BLOB tipi bir sütununuz olması.

Bu BLOB sütununu, yalnızca kullanıcı tablosundaki sorgular için değil, aynı zamanda bloğu içeren tabloyu daha ucuz, daha yavaş depolamada farklı bir tablo alanına taşıyabileceğiniz ve en çok sorgulanan verileri daha hızlı bir depolama alanı.

Birebir ilişkiler yalnızca Tablo B'deki ilgili kaydın isteğe bağlı olmasını istediğinizde anlamlıdır .

Bazen istediğiniz bir varyant kaydı veya Etiketli Birliktir . Bu, farklı bilgiler içeren birden fazla tablonuz olduğu anlamına gelir, ancak hepsi birebir ilişkilerde Tablo A ile ilgilidir. Daha sonra Tablo A'daki bir alana göre ilişkilendirilecek tabloyu seçersiniz

Örneğin:

type Transaction(The_Type: PaymentType := Cash) is record

    Amount: Integer;

    case The_Type is
        when Cash =>
            Discount: boolean;
        when Check =>
            CheckNumber: Positive;
        when Credit =>
            CardNumber: String(1..5);
            Expiration: String(1..5);
    end case;
end record;

İş modellemesinde, mantıksal olarak bir iş açısından ayrı olan iki A ve B varlığı tipik olarak farklı tablolarla eşleşir.

Örneğin, nesne yönelimli araçlarla iş modellemesi yaparken, genellikle bir tür nesne-ilişkisel eşlemeniz olur. Bir nesne modeliyle başlayabilir ve ilişkisel modelinizi bundan türetebilirsiniz. Nesne modelinizde, nesnelerin 1: 1 yazışmasına rağmen, tek sorumluluk ilkesi nedeniyle ayrı kalması gereken A ve B sınıfları oluşturduğunuzu düşünün . Nesne modelinizde, bu sınıfların yalnızca özniteliklere sahip tablolar olmadığını, yöntemlerde uygulanan bazı davranışlarla iş nesnelerini temsil edebileceğini unutmayın. Ve bu sınıfları artık doğrudan ilişkisel bir modele eşlediğinizde, A ve B tablolarını 1: 1 ilişki ile alırsınız.

Bir iş veya OO veri modeli oluştururken, bu mantıksal ayrım, 1: 1 ilişkiler için performans, bireysel güvenlik veya bölümleme gibi "fiziksel" nedenlerden çok daha tipiktir.