डेटाबेस संरचना / डिजाइन

कोई सामान्य नियम या सर्वोत्तम अभ्यास नहीं है, विदेशी कुंजी शून्य नहीं होनी चाहिए। कई बार यह एक इकाई के लिए किसी अन्य इकाई के साथ संबंध न रखने के लिए एकदम सही समझ में आता है। उदाहरण के लिए, आपके पास कलाकारों की एक तालिका हो सकती है जिसे आप ट्रैक करते हैं, लेकिन इस समय, आपके पास उन कलाकारों द्वारा रिकॉर्ड की गई कोई सीडी नहीं है।

जहां तक ​​मीडिया (सीडी, डीवीडी, ब्लूरे) है जो या तो संगीत/ऑडियो या सॉफ्टवेयर हो सकता है, आपके पास सामान्य जानकारी वाली एक तालिका हो सकती है और फिर दो विदेशी कुंजियां, प्रत्येक विस्तार तालिका के लिए एक (ऑडियोडेटा और सॉफ्टवेयरडेटा), लेकिन एक NULL होना चाहिए . यह अन्य बातों के अलावा, एक विशेष चाप नामक स्थिति को प्रस्तुत करता है। यह आम तौर पर...समस्याग्रस्त माना जाता है।

जावा या सी ++ जैसी ओओ भाषा में एक सुपरक्लास और दो व्युत्पन्न कक्षाओं के बारे में सोचें। एक संबंधपरक स्कीमा में इसका प्रतिनिधित्व करने का एक तरीका है:

create table Media(
    ID      int not null, -- identity, auto_generated, generated always as identity...
    Type    char( 1 ) not null,
    Format  char( 1 ) not null,
    ... <other common data>,
    constraint PK_Media primary key( ID ),
    constraint FK_Media_Type foreign key( Type )
        references MediaTypes( ID ), -- A-A/V, S-Software, G-Game
    constraint FK_Media_Format foreign key( Format )
        references MediaFormats( ID ) -- C-CD, D-DVD, B-BluRay, etc.
);
create unique index UQ_Media_ID_Type( ID, Type ) on Media;
create table AVData( -- For music and video
    ID       int not null,
    Type     char( 1 ) not null,
    ... <audio-only data>,
    constraint PK_AVData primary key( ID ),
    constraint CK_AVData_Type check( Type = 'A',
    constraint FK_AVData_Media foreign key( ID, Type )
        references Media( ID, Type )
);
create table SWData( -- For software, data
    ID       int not null,
    Type     char( 1 ) not null,
    ... <software-only data>,
    constraint PK_SWData primary key( ID ),
    constraint CK_SWData_Type check( Type = 'S',
    constraint FK_SWData_Media foreign key( ID, Type )
        references Media( ID, Type )
);
create table GameData( -- For games
    ID       int not null,
    Type     char( 1 ) not null,
    ... <game-only data>,
    constraint PK_GameData primary key( ID ),
    constraint CK_GameData_Type check( Type = 'G',
    constraint FK_GameData_Media foreign key( ID, Type )
        references Media( ID, Type )
);

अब यदि आप एक फिल्म की तलाश में हैं, तो आप AVData तालिका खोजते हैं, फिर बाकी जानकारी के लिए मीडिया टेबल से जुड़ें और इसी तरह सॉफ्टवेयर या गेम के साथ। यदि आपके पास एक आईडी मान है, लेकिन यह नहीं पता कि यह किस प्रकार का है, तो मीडिया तालिका खोजें और प्रकार मान आपको बताएगा कि तीन (या अधिक) डेटा तालिकाओं में से किसके साथ जुड़ना है। मुद्दा यह है कि FK से . की बात कर रहा है सामान्य तालिका, इससे नहीं।

बेशक, एक मूवी या गेम या सॉफ़्टवेयर को एक से अधिक मीडिया प्रकारों पर रिलीज़ किया जा सकता है, इसलिए आपके पास Media के बीच प्रतिच्छेदन तालिकाएं हो सकती हैं तालिका और संबंधित डेटा तालिकाएँ। ओह, उन्हें आम तौर पर अलग-अलग एसकेयू के साथ लेबल किया जाता है ताकि आप उन्हें अलग-अलग आइटम के रूप में भी मान सकें।

कोड, जैसा कि आप उम्मीद कर सकते हैं, काफी जटिल हो सकता है, हालांकि बहुत बुरा नहीं है। ओटोह, हमारा डिज़ाइन लक्ष्य कोड सादगी नहीं बल्कि डेटा अखंडता है। यह मिश्रण करना असंभव बनाता है, उदाहरण के लिए, मूवी आइटम के साथ गेम डेटा। और आपको फ़ील्ड का एक सेट होने से छुटकारा मिलता है जहां केवल एक का मान होना चाहिए और अन्य को शून्य होना चाहिए।