एक विरासत संरचना के आसपास संबंधों को डिजाइन करना

एक समान प्रश्न है यहां मीडिया सुपरटाइप का उपयोग करना और सीडी, वीसीआर, डीवीडी आदि के उपप्रकार जोड़ना।

यह मापनीय है कि एक BluRay उपप्रकार बनाने, कहने में, आप BluRay-विशिष्ट डेटा रखने के लिए तालिका बनाते हैं और MediaTypes तालिका में एक प्रविष्टि जोड़ते हैं। मौजूदा डेटा या कोड के लिए किसी बदलाव की आवश्यकता नहीं है -- सिवाय, ज़ाहिर है, उस कोड को जोड़ने के लिए जो ब्लूरे डेटा के साथ काम करेगा।

आपके मामले में, उपयोगकर्ता सुपरटाइप टेबल होंगे, जिसमें शिक्षक और छात्र सबटाइप टेबल होंगे।

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 )
);

छात्र तालिका का श्रृंगार शिक्षक तालिका के समान होगा।

चूंकि शिक्षक और छात्र दोनों अन्य शिक्षकों और छात्रों को नियुक्त कर सकते हैं, इस संबंध वाली तालिका उपयोगकर्ता तालिका को संदर्भित करेगी।

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 )
);

जैसा कि मैं इसे समझता हूं, अधिसूचनाएं नियोक्ता द्वारा समूहीकृत की जाती हैं:

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

प्रश्न काफी सरल होने चाहिए। उदाहरण के लिए, यदि कोई उपयोगकर्ता अपने नियोक्ता से सभी सूचनाएं देखना चाहता है:

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

यह एक प्रारंभिक स्केच है, बिल्कुल। शोधन संभव है। लेकिन आपके गिने-चुने बिंदुओं पर:

1. रोजगार तालिका नियोक्ताओं को कर्मचारियों से संबंधित करती है। एकमात्र जांच है कि क्या उपयोगकर्ता को नियोक्ता स्वयं कर्मचारी नहीं बना सकता है, लेकिन अन्यथा कोई भी उपयोगकर्ता कर्मचारी और नियोक्ता दोनों हो सकता है।
2. उपयोगकर्ता तालिका प्रत्येक उपयोगकर्ता को शिक्षक ('T') या छात्र ('S') बनने के लिए बाध्य करती है। केवल 'टी' के रूप में परिभाषित उपयोगकर्ताओं को शिक्षक तालिका में रखा जा सकता है और केवल 'एस' के रूप में परिभाषित उपयोगकर्ताओं को ही छात्र तालिका में रखा जा सकता है।
3. रोजगार तालिका केवल उपयोगकर्ता तालिका से जुड़ती है, शिक्षक और छात्र दोनों तालिकाओं से नहीं। लेकिन ऐसा इसलिए है क्योंकि शिक्षक और छात्र दोनों नियोक्ता और कर्मचारी दोनों हो सकते हैं, न कि किसी प्रदर्शन कारण से। सामान्य तौर पर, प्रारंभिक डिज़ाइन के दौरान प्रदर्शन के बारे में चिंता न करें। इस बिंदु पर आपकी प्राथमिक चिंता डेटा अखंडता है। जॉइन के साथ रिलेशनल डेटाबेस बहुत अच्छे हैं। अगर एक प्रदर्शन समस्या क्रॉप होनी चाहिए, फिर उसे ठीक करें। उन समस्याओं को हल करने के लिए अपने डेटा का पुनर्गठन न करें जो अभी तक मौजूद नहीं हैं और जो कभी मौजूद नहीं हो सकती हैं।
4. ठीक है, इसे आज़माएं और देखें कि यह कैसे काम करता है।