Design af relationer omkring en arvestruktur

Der er et lignende spørgsmål her ved at bruge en Media-supertype og tilføje undertyper af CD, VCR, DVD osv.

Dette er skalerbart ved, at når du opretter f.eks. en BluRay-undertype, opretter du tabellen til at indeholde de BluRay-specifikke data og tilføjer en post til MediaTypes-tabellen. Ingen ændringer er nødvendige for eksisterende data eller kode -- bortset fra selvfølgelig at tilføje koden, der fungerer med BluRay-data.

I dit tilfælde ville brugere være supertypetabellen med lærere og elever undertypetabellerne.

create table Users(
    ID      int not null auto_generating,
    Type    char( 1 ) check( Type in( 'T', 'S' )),
    -- other data common to all users,
    constraint PK_Users primary key( ID ),
    constraint UQ_UserType unique( ID, Type ),
    constraint FK_UserTypes foreign key( Type )
        references UserTypes( ID )
);
create table Teachers(
    TeacherID int not null,
    TeacherType char( 1 ) check( TeacherType = 'T' )),
    -- other data common to all teachers...,
    constraint PK_Teachers primary key( TeacherID ),
    constraint FK_TeacherUser foreign key( TeacherID, TeacherType )
        references Users( ID, Types )
);

Sammensætningen af ​​elevbordet ville ligne lærerbordet.

Da både lærere og elever kan ansætte andre lærere og elever, vil tabellen, der indeholder denne relation, referere til tabellen Brugere.

create table Employment(
    EmployerID    int not null,
    EmployeeID    int not null,
    -- other data concerning the employment...,
    constraint CK_EmploymentDupes check( EmployerID <> EmployeeID ),
    constraint PK_Employment primary key( EmployerID, EmployeeID ),
    constraint FK_EmploymentEmployer foreign key( EmployerID )
        references Users( ID ),
    constraint FK_EmploymentEmployee foreign key( EmployeeID )
        references Users( ID )
);

Som jeg forstår det, er meddelelser grupperet efter arbejdsgiver:

create table Notifications(
    EmployerID    int not null
    NotificationDate date,
    NotificationData varchar( 500 ),
    -- other notification data...,
    constraint FK_NotificationsEmployer foreign key( EmployerID )
        references Users( ID )
);

Forespørgslerne skal være enkle nok. For eksempel, hvis en bruger ønskede at se alle meddelelser fra sin arbejdsgiver(e):

select  e.EmployerID, n.NotificationDate, n.NotificationData
from    Employment  e
join    Notifications n
    on  n.EmployerID = e.EmployerID
where   e.EmployeeID = :UserID;

Dette er selvfølgelig en indledende skitse. Forfinelser er mulige. Men til dine nummererede punkter:

1. Beskæftigelsestabellen relaterer arbejdsgivere til ansatte. Det eneste tjek, om at gøre bruger arbejdsgivere kan ikke ansætte sig selv, men ellers kan enhver bruger være både en medarbejder og arbejdsgiver.
2. Brugertabellen tvinger hver bruger til enten at være lærer ('T') eller elev ('S'). Kun brugere defineret som 'T' kan placeres i lærertabellen, og kun brugere defineret som 'S' kan placeres i elevtabellen.
3. Tabellen Beskæftigelse forbindes kun med tabellen Brugere, ikke til både lærer- og elevtabellerne. Men det skyldes, at både lærere og elever kan være både arbejdsgivere og ansatte, ikke af nogen præstationsgrund. Generelt skal du ikke bekymre dig om ydeevne under det indledende design. Din primære bekymring på dette tidspunkt er dataintegritet. Relationelle databaser er meget gode med joins. Hvis et ydeevneproblem skulle dukke op, og løs det derefter. Omstrukturer ikke dine data for at løse problemer, der endnu ikke eksisterer og måske aldrig eksisterer.
4. Tja, prøv dette og se, hvordan det virker.