डेटाबेस स्कीमा भ्रमित (सूचकांक और बाधाएं)

मैं दूसरा दृष्टिकोण पसंद करूंगा। सरोगेट आईडी नंबरों का उपयोग करके जब वे पहचान के लिए तार्किक रूप से आवश्यक नहीं होते हैं, तो आप अधिक अनिवार्य जुड़ाव पेश करते हैं। इसके लिए आपको "पूरे डेटाबेस में आईडी नंबरों का पीछा करना होगा", जो कि "पूरे डेटाबेस में पॉइंटर्स का पीछा करने" के बराबर SQL है। चेज़िंग पॉइंटर्स IMS की विशेषता थी, जो डेटाबेस आर्किटेक्चर में से एक था जिसे बदलने के लिए रिलेशनल मॉडल का इरादा था। (IMS एक पदानुक्रमित वास्तुकला का उपयोग करता है।) आज इसे फिर से बनाने का कोई मतलब नहीं है। (हालांकि एक बहुत लोग ऐसा ही करते हैं।)

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

प्रदर्शन का परीक्षण करना आसान है . बस अपनी पसंदीदा स्क्रिप्टिंग भाषा का उपयोग करके कुछ मिलियन यादृच्छिक-ईश पंक्तियां उत्पन्न करें, और उन्हें एक परीक्षण सर्वर में लोड करें। आप न केवल यह पाएंगे कि आपकी प्रदर्शन समस्याएं कहां छिपी हैं, आपको अपने तालिका बनाएं कोड में सभी त्रुटियां मिलेंगी। (आपका कोड यथावत काम नहीं करेगा।) EXPLAIN के बारे में जानें अगर आप इसके बारे में पहले से नहीं जानते हैं।

जहां तक ​​अनुक्रमण का संबंध है , आप परीक्षण कर सकते हैं कि आपके द्वारा उत्पन्न और लोड की गई यादृच्छिक-ईश पंक्तियों पर। यदि उपयोगकर्ता हमेशा पहले नाम की आपूर्ति करते हैं तो (first_name, last_name) पर एक बहु-स्तंभ अनुक्रमणिका सबसे अच्छा काम करेगी। लेकिन बहुत सारे उपयोगकर्ता ऐसा नहीं करेंगे, इसके बजाय अंतिम नाम से खोजना पसंद करेंगे। (first_name, last_name) पर एक बहु-स्तंभ अनुक्रमणिका उन उपयोगकर्ताओं के लिए प्रभावी नहीं है जो अंतिम नाम से खोजना पसंद करते हैं। आप इसका परीक्षण कर सकते हैं।

केवल इसी कारण से, पहले नामों और अंतिम नामों का अनुक्रमण आमतौर पर . होता है अधिक प्रभावी अगर दो अलग-अलग अनुक्रमणिकाएं हैं, एक प्रथम नाम के लिए, और एक अंतिम नाम के लिए।

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

create table A (
 a_id integer primary key,
 a_1 varchar(15) not null unique,
 a_2 varchar(15) not null
);

create table B (
  b_id integer primary key
  a_id integer not null references A (a_id),
  b_1  varchar(10) not null,
  unique (a_id, b_1),
);

create table C (
  c_id integer primary key,
  b_id integer not null references B (b_id),
  c_1 char(3) not null,
  c_2 varchar(20) not null,
  unique (b_id, c_1)
);

create table D (
  d_id integer primary key,
  c_id integer not null references C (c_id),
  d_1 integer not null,
  d_2 varchar(15),
  unique (c_id, d_1)
);

यदि आपको तालिका "डी" पर एक रिपोर्ट की आवश्यकता है, और रिपोर्ट की आवश्यकता है

• कॉलम D.d_1 और D.d_2, और
• कॉलम A.a_1 और A.a_2,

इसे पाने के लिए आपको 3 जॉइन चाहिए। (इसे आज़माएं।) आप आईडी नंबरों का पीछा कर रहे हैं। (आईएमएस में पॉइंटर्स का पीछा करने की तरह।) निम्नलिखित संरचना अलग है।

create table A (
 a_1 varchar(15) primary key,
 a_2 varchar(15) not null
);

create table B (
  a_1 varchar(15) not null references A (a_1),
  b_1  varchar(10) not null,
  primary key (a_1, b_1),
);

create table C (
  a_1 varchar(15) not null,
  b_1 varchar(10) not null,
  c_1 char(3) not null,
  c_2 varchar(20) not null,
  primary key (a_1, b_1, c_1),
  foreign key (a_1, b_1) references B (a_1, b_1)
);

create table D (
  a_1 varchar(15) not null,
  b_1 varchar(10) not null,
  c_1 char(3) not null,
  d_1 integer not null,
  d_2 varchar(15),
  primary key (a_1, b_1, c_1, d_1),
  foreign key (a_1, b_1, c_1) references C (a_1, b_1, c_1)
);

इस संरचना के साथ, एक ही रिपोर्ट को एक ही जुड़ाव की आवश्यकता होती है।

select D.d_1, D.d_2, A.a_1, A.a_2
from D
inner join A on D.a_1 = A.a_1;