IS-A ilişkisini bir veritabanında nasıl eşlerim?

Aşağıdakileri göz önünde bulundur:

entity User
{
    autoincrement uid;
    string(20) name;
    int privilegeLevel;
}

entity DirectLoginUser
{
    inherits User;
    string(20) username;
    string(16) passwordHash;
}

entity OpenIdUser
{
    inherits User;
    //Whatever attributes OpenID needs... I don't know; this is hypothetical
}

Farklı türde kullanıcılar (Doğrudan Giriş kullanıcıları ve OpenID kullanıcıları) bir IS-A ilişkisi gösterir; yani, her iki kullanıcı türünün de kullanıcı olduğu. Şimdi bunun bir RDBMS'de gösterilebileceği birkaç yol var:

Bir yol

CREATE TABLE Users
(
    uid INTEGER AUTO_INCREMENT NOT NULL,
    name VARCHAR(20) NOT NULL,
    privlegeLevel INTEGER NOT NULL,
    type ENUM("DirectLogin", "OpenID") NOT NULL,
    username VARCHAR(20) NULL,
    passwordHash VARCHAR(20) NULL,
    //OpenID Attributes
    PRIMARY_KEY(uid)
)

Yol iki

CREATE TABLE Users
(
    uid INTEGER AUTO_INCREMENT NOT NULL,
    name VARCHAR(20) NOT NULL,
    privilegeLevel INTEGER NOT NULL,
    type ENUM("DirectLogin", "OpenID") NOT NULL,
    PRIMARY_KEY(uid)
)

CREATE TABLE DirectLogins
(
    uid INTEGER NOT_NULL,
    username VARCHAR(20) NOT NULL,
    passwordHash VARCHAR(20) NOT NULL,
    PRIMARY_KEY(uid),
    FORIGEN_KEY (uid) REFERENCES Users.uid
)

CREATE TABLE OpenIDLogins
(
    uid INTEGER NOT_NULL,
    // ...
    PRIMARY_KEY(uid),
    FORIGEN_KEY (uid) REFERENCES Users.uid
)

Yol üç

CREATE TABLE DirectLoginUsers
(
    uid INTEGER AUTO_INCREMENT NOT NULL,
    name VARCHAR(20) NOT NULL,
    privlegeLevel INTEGER NOT NULL,
    username VARCHAR(20) NOT NULL,
    passwordHash VARCHAR(20) NOT NULL,
    PRIMARY_KEY(uid)
)

CREATE TABLE OpenIDUsers
(
    uid INTEGER AUTO_INCREMENT NOT NULL,
    name VARCHAR(20) NOT NULL,
    privlegeLevel INTEGER NOT NULL,
    //OpenID Attributes
    PRIMARY_KEY(uid)
)

Neredeyse üçüncü yolun yanlış yol olduğundan eminim, çünkü veritabanındaki herhangi bir yerdeki kullanıcılara basit bir katılım mümkün değil.

Benim gerçek dünya örneğim, farklı giriş örnekleri olan bir kullanıcı olmasa da; Bu durumun genel durumda nasıl modelleneceği ile ilgileniyorum.

İkinci yol doğru yoldur.

Temel sınıfınız bir masa alır ve daha sonra alt sınıflar tanıttıkları ek alanların yanı sıra temel tabloya yabancı anahtar başvuruları ile kendi tablolarını alır.

Joel'in bu cevap hakkındaki yorumunda önerdiği gibi , bir kullanıcının ya doğrudan giriş yapmasını ya da bir OpenID girişini yapmasını garanti edersiniz, ancak geri dönen her bir alt tip tablosuna bir tür sütunu ekleyerek ikisinin de (ve muhtemelen ikisinin de değil) olacağını garanti edebilirsiniz. kök tabloya. Her bir alt-tip tablosundaki tip sütunu, o tablonun tipini temsil eden tek bir değere sahip olacak şekilde sınırlandırılmıştır. Bu sütun kök tablaya yabancı olduğundan, aynı anda yalnızca bir alt tip satır aynı kök satırına bağlanabilir.

Örneğin, MySQL DDL şöyle bir şeye benzeyebilir:

CREATE TABLE Users
(
      uid               INTEGER AUTO_INCREMENT NOT NULL
    , type              ENUM("DirectLogin", "OpenID") NOT NULL
    // ...

    , PRIMARY_KEY(uid)
);

CREATE TABLE DirectLogins
(
      uid               INTEGER NOT_NULL
    , type              ENUM("DirectLogin") NOT NULL
    // ...

    , PRIMARY_KEY(uid)
    , FORIGEN_KEY (uid, type) REFERENCES Users (uid, type)
);

CREATE TABLE OpenIDLogins
(
      uid               INTEGER NOT_NULL
    , type              ENUM("OpenID") NOT NULL
    // ...

    PRIMARY_KEY(uid),
    FORIGEN_KEY (uid, type) REFERENCES Users (uid, type)
);

(Diğer platformlarda CHECKbunun yerine bir kısıtlama kullanırsınız ENUM.) MySQL , bileşik yabancı anahtarları desteklediğinden sizin için çalışması gerekir.

Bunlardan biri geçerli, bu NULLsütunları boşa harcıyor olsanız da, bunların kullanımları kullanıcının türüne bağlı olarak değişiyor. Bunun avantajı, hangi tür kullanıcı türlerini depolamak için genişletmeyi seçmeniz ve bu türlerin ek sütunlar gerektirmemesi durumunda, alanınızın alanını genişletip ENUMaynı tabloyu kullanabilmenizdir.

Üçüncüsü, kullanıcılara her iki tabloyu da kontrol etmesi için başvuruda bulunan sorguları zorlar. Bu aynı zamanda tek bir kullanıcı tablosuna yabancı anahtar ile atıfta bulunmanızı önler.

Onlar isimlendirilirdi

1. Tek Tablo Kalıtım
2. Sınıf Tablo Mirası
3. Beton Tablo Kalıtım .

ve hepsinin meşru kullanımları vardır ve bazı kütüphaneler tarafından desteklenir. Hangisinin en uygun olduğunu bulmak zorundasın.

Birden fazla tablo olması veri yönetimini uygulama kodunuza daha fazla götürür, ancak kullanılmayan alanı azaltır.