वैकल्पिक ओरेकल में कई-से-कई संबंध कार्यान्वयन

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

हालाँकि, मेरे पास एक नेस्टेड टेबल का उपयोग करके कई-से-कई संबंध ( MANY-TO-MANY RELATIONSHIP ) को लागू करने का विचार था, क्योंकि यह विचार इतना आकर्षक है - एक विदेशी कुंजी का उपयोग करने के बजाय, एक विशिष्ट रिकॉर्ड के लिए उनके सेट को स्टोर करें - जो एक मानवीय दृष्टिकोण से अधिक तार्किक हो सकता है। तर्क? लेकिन सवाल उठता है - क्या मोमबत्ती के लायक खेल है?

उदाहरण

एक उदाहरण का उपयोग करके प्रस्तावित संरचना को दिखाना आसान है, और यह जांचने का भी एक अच्छा तरीका है कि किस पद्धति से सिस्टम कम लोड होता है।

मान लीजिए कि एक वैक्यूम में एक बस बेड़ा गोलाकार है। बस के बेड़े में कई बसें और कई ड्राइवर हैं। कई ड्राइवर एक ही बस (कई पारियों) पर सवारी करते हैं। इस पार्क की विशेषताएं ऐसी हैं कि एक चालक कई बसों पर सवारी कर सकता है, उदाहरण के लिए, सप्ताह के दिन।

चलो दो बहुत ही साधारण टेबल बनाते हैं, जिसका उद्देश्य केवल उनके बीच संबंध बनाना है।

CREATE TABLE tab_bus
( b_id NUMBER PRIMARY KEY
, bus_number VARCHAR2(9) NOT NULL
);
CREATE SEQUENCE seq_bus;

CREATE TABLE tab_driver
( d_id NUMBER PRIMARY KEY
, driver_name VARCHAR2(255) NOT NULL
);
CREATE SEQUENCE seq_driver;

* This source code was highlighted with Source Code Highlighter .

शुरू करने के लिए, हम सबसे आम दृष्टिकोण का उपयोग करके रिश्ते को लागू करते हैं: रिश्तों की एक तालिका बनाएं।

CREATE TABLE bus_driver
( bus_id NUMBER
, driver_id NUMBER
, CONSTRAINT pk_driver_bus PRIMARY KEY (bus_id, driver_id)
, CONSTRAINT fk_bus_id FOREIGN KEY (bus_id) REFERENCES tab_bus (b_id)
, CONSTRAINT fk_driver_id FOREIGN KEY (driver_id) REFERENCES tab_driver (d_id)
);

* This source code was highlighted with Source Code Highlighter .

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

उदाहरण में संबंध बनाने, हटाने और चयन करने के लिए, प्रक्रियाओं का उपयोग किया जाएगा - परीक्षण की सुविधा के लिए। इसके अलावा, मुझे प्रक्रियाओं के साथ परीक्षण करने में रुचि थी, क्योंकि प्रोग्रामिंग के दृष्टिकोण से यह कार्यक्रम के शरीर में प्रश्नों के संकलन की तुलना में अधिक सुविधाजनक है। यह ध्यान दिया जाना चाहिए कि एक प्रक्रिया में कोई प्रतिबद्ध ( COMMIT; ) नहीं है। सबसे पहले, जब मैं इसका परीक्षण करता हूं, तो मैं इसे मैन्युअल रूप से करता हूं, और दूसरी बात, रिश्तों को जोड़ने और हटाने की प्रक्रियाएं परीक्षण के दौरान एक लूप में शुरू होती हैं - इस मामले में, प्रतिबद्ध केवल हस्तक्षेप करेगा।

CREATE PROCEDURE add_relation
( p_bus NUMBER
, p_driver NUMBER
) AS
BEGIN
INSERT INTO bus_driver VALUES ( p_bus, p_driver );
END ;

CREATE PROCEDURE drop_relation
( p_bus NUMBER
, p_driver NUMBER
) AS
BEGIN
DELETE bus_driver WHERE bus_id = p_bus AND driver_id = p_driver;
END ;

CREATE PROCEDURE select_relation
( p_data OUT SYS_REFCURSOR
) AS
BEGIN
OPEN p_data FOR
SELECT b.bus_number, d.driver_name
FROM tab_bus b, tab_driver d, bus_driver r
WHERE (b.b_id = r.bus_id) AND (r.driver_id = d.d_id);
END ;

* This source code was highlighted with Source Code Highlighter .

यह शायद ध्यान देने योग्य है कि यहां चयन प्रक्रिया में, WHERE निर्माण का उपयोग टेबल जॉइन ( JOIN ) के रूप में किया जाता है। इसके दो कारण हैं: ओरेकल ध्यान नहीं देता है, वह इसे JOIN मानता है, और SQL क्वेरी क्वेरी के निर्माण की जटिलता की तुलना करना मेरे लिए अधिक सुविधाजनक है।

यह पहली संबंध संरचना के निर्माण को पूरा करता है। निम्नलिखित संबंध योजना लागू की गई थी: दो तालिकाओं और एक अतिरिक्त तालिका, जो रिश्तों की एक सूची संग्रहीत करती है।

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

नेस्टेड तालिकाओं के एक स्तंभ के साथ एक तालिका तुरंत बनाई जा सकती है, लेकिन इस मामले में, संबंध तैयार-निर्मित दो तालिकाओं से निर्मित होता है, इसलिए एक अलग दृष्टिकोण का उपयोग किया जाता है: तालिकाओं में से एक को बदल दिया जाता है।

CREATE OR REPLACE TYPE obj_list AS OBJECT
( r_driver NUMBER
);
CREATE OR REPLACE TYPE nt_list AS TABLE OF obj_list;
ALTER TABLE tab_bus ADD
( bus_drivers nt_list NULL
) NESTED TABLE bus_drivers STORE AS nt_bus_drivers;

* This source code was highlighted with Source Code Highlighter .

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

CREATE FUNCTION check_fk
( p_id NUMBER
) RETURN NUMBER IS
fk_count NUMBER;
BEGIN
SELECT COUNT (d_id) INTO fk_count
FROM tab_driver WHERE d_id = p_id;
RETURN fk_count;
END ;

* This source code was highlighted with Source Code Highlighter .

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

CREATE PROCEDURE add_relation
( p_bus NUMBER
, p_driver NUMBER
) AS
BEGIN
IF (check_fk(p_driver) = 1) THEN
INSERT INTO TABLE
( SELECT bus_drivers
FROM tab_bus
WHERE b_id = p_bus
)
VALUES ( obj_list(p_driver) );
ELSE
RAISE_APPLICATION_ERROR(-20665, 'Record doesn' 't exist.' );
END IF ;
DBMS_OUTPUT.PUT_LINE( TO_CHAR( (DBMS_UTILITY.GET_TIME-start_time)/100, '09.99' ) );
EXCEPTION
WHEN OTHERS THEN
UPDATE tab_bus
SET bus_drivers = nt_list ( obj_list(p_driver) )
WHERE b_id = p_bus;
END add_relation;

CREATE PROCEDURE drop_relation
( p_bus NUMBER
, p_driver NUMBER
) AS
BEGIN
IF (check_fk(p_driver) = 1) THEN
DELETE TABLE
( SELECT bus_drivers
FROM tab_bus d
WHERE d.b_id = p_bus
) nt
WHERE nt.r_driver = p_bus;
END IF ;
EXCEPTION
WHEN OTHERS THEN
NULL ;
END drop_relation;

CREATE PROCEDURE select_relation
( p_data OUT SYS_REFCURSOR
) AS
BEGIN
OPEN p_data FOR
SELECT b.bus_number, d.driver_name
FROM tab_bus b, tab_driver d, TABLE (b.bus_drivers) r
WHERE (b.b_id = p_bus) AND (d.d_id = p_driver);
END ;

* This source code was highlighted with Source Code Highlighter .

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

INSERT INTO tab_driver VALUES ( seq_driver.NEXTVAL, 'Viktor Jeliseev' );
INSERT INTO tab_driver VALUES ( seq_driver.NEXTVAL, 'Stepan Kljavin' );
INSERT INTO tab_driver VALUES ( seq_driver.NEXTVAL, 'Marija Baranka' );
INSERT INTO tab_driver VALUES ( seq_driver.NEXTVAL, 'Arsenij Dubov' );
INSERT INTO tab_bus VALUES ( seq_bus.NEXTVAL, 'p666pp' );
INSERT INTO tab_bus VALUES ( seq_bus.NEXTVAL, 'LT-3216' );
INSERT INTO tab_bus VALUES ( seq_bus.NEXTVAL, 'zox-15' );
INSERT INTO tab_bus VALUES ( seq_bus.NEXTVAL, 'x234oo' );

BEGIN
add_relation (1, 3);
add_relation (1, 4);
add_relation (3, 3);
add_relation (3, 2);
add_relation (2, 2);
drop_relation (3, 2);
drop_relation (2, 2);
END ;

DECLARE
g_data SYS_REFCURSOR;
BEGIN
select_relation (1, 4, g_data);
select_relation (3, 3, g_data);
select_relation (2, 2, g_data);
select_relation (1, 1, g_data);
END ;

* This source code was highlighted with Source Code Highlighter .

परीक्षण

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

CREATE OR REPLACE
PROCEDURE random_insert_data
( record_count NUMBER
) AS
start_time NUMBER DEFAULT DBMS_UTILITY.GET_TIME;
counter NUMBER;
field_value VARCHAR2(255);
BEGIN
FOR counter IN 1..record_count
LOOP
field_value := DBMS_RANDOM.STRING( 'A' , 9);
INSERT INTO tab_bus (b_id, bus_number) VALUES
( seq_bus.NEXTVAL
, field_value
);
END LOOP;
FOR counter IN 1..record_count
LOOP
field_value := INITCAP(DBMS_RANDOM.STRING( 'L' , 6))|| ' ' ||INITCAP(DBMS_RANDOM.STRING( 'L' , 9));
INSERT INTO tab_driver VALUES
( seq_driver.NEXTVAL
, field_value);
END LOOP;
DBMS_OUTPUT.PUT_LINE( TO_CHAR( (DBMS_UTILITY.GET_TIME-start_time)/100, '09.99' ) );
END ;

-- for standart many-to-many relations
CREATE PROCEDURE random_insert_rel
( rel_count NUMBER
, rel_from NUMBER
, rel_to NUMBER
) AS
start_time NUMBER DEFAULT DBMS_UTILITY.GET_TIME;
rel1_value VARCHAR2(255);
rel2_value VARCHAR2(255);
counter NUMBER;
BEGIN
FOR counter IN 1..rel_count
LOOP
rel1_value := ROUND(DBMS_RANDOM. VALUE (rel_from, rel_to));
rel2_value := ROUND(DBMS_RANDOM. VALUE (rel_from, rel_to));
add_relation(rel1_value, rel2_value);
END LOOP;
DBMS_OUTPUT.PUT_LINE( TO_CHAR( (DBMS_UTILITY.GET_TIME-start_time)/100, '09.99' ) );
END ;

-- for standart many-to-many relations
CREATE PROCEDURE random_delete_rel
( rel_count NUMBER
, rel_from NUMBER
, rel_to NUMBER
) AS
start_time NUMBER DEFAULT DBMS_UTILITY.GET_TIME;
rel1_value VARCHAR2(255);
rel2_value VARCHAR2(255);
counter NUMBER;
BEGIN
FOR counter IN 1..rel_count
LOOP
rel1_value := ROUND(DBMS_RANDOM. VALUE (rel_from, rel_to));
rel2_value := ROUND(DBMS_RANDOM. VALUE (rel_from, rel_to));
drop_relation(rel1_value, rel2_value);
END LOOP;
DBMS_OUTPUT.PUT_LINE( TO_CHAR( (DBMS_UTILITY.GET_TIME-start_time)/100, '09.99' ) );
END ;

-- for alternative many-to-many system with nested table
CREATE PROCEDURE random_insert_rel
( rel_count NUMBER
, rel_from NUMBER
, rel_to NUMBER
) AS
start_time NUMBER DEFAULT DBMS_UTILITY.GET_TIME;
rel1_value VARCHAR2(255);
rel2_value VARCHAR2(255);
counter NUMBER;
BEGIN
FOR counter IN 1..rel_count
LOOP
rel1_value := ROUND(DBMS_RANDOM. VALUE (rel_from, rel_to));
rel2_value := ROUND(DBMS_RANDOM. VALUE (rel_from, rel_to));
add_relation(rel1_value, rel2_value);
END LOOP;
DBMS_OUTPUT.PUT_LINE( TO_CHAR( (DBMS_UTILITY.GET_TIME-start_time)/100, '09.99' ) );
END ;

-- for alternative many-to-many system with nested table
CREATE PROCEDURE random_delete_rel
( rel_count NUMBER
, rel_from NUMBER
, rel_to NUMBER
) AS
start_time NUMBER DEFAULT DBMS_UTILITY.GET_TIME;
rel1_value VARCHAR2(255);
rel2_value VARCHAR2(255);
counter NUMBER;
BEGIN
FOR counter IN 1..rel_count
LOOP
rel1_value := ROUND(DBMS_RANDOM. VALUE (rel_from, rel_to));
rel2_value := ROUND(DBMS_RANDOM. VALUE (rel_from, rel_to));
drop_relation(rel1_value, rel2_value);
END LOOP;
DBMS_OUTPUT.PUT_LINE( TO_CHAR( (DBMS_UTILITY.GET_TIME-start_time)/100, '09.99' ) );
END ;

* This source code was highlighted with Source Code Highlighter .

कृपया ध्यान दें कि परीक्षण प्रक्रियाओं में कोई प्रतिबद्धता नहीं है।

परिणाम

N = 4, 1000, 100000 की मात्रा में डेटा पर परीक्षण किया गया था। यह समझा जाता है कि प्रत्येक तालिका में n रिकॉर्ड हैं, और n संबंध बनाए जाते हैं। परीक्षण 10 पदों पर किया गया था, उनमें से 6 नीचे दी गई तालिका में प्रस्तुत किए गए हैं, जिनमें सबसे महत्वपूर्ण समय अंतर हैं और सबसे महत्वपूर्ण डेटा प्रदर्शित करते हैं।

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

जिस तरह से रिकॉर्डिंग	नमूना 1	नमूना २	नमूना ३	नमूना ४	नमूना ५	का निर्माण
ext। तालिका 4	00,844	00,792	00,967	00.01	00.02	00,032
में। तालिका 4	00,694	00,707	00,026	00.00	00.00	00,034
ext। तालिका, 1000	00,642	00,645	00,698	00.02	00.02	00,142
में। तालिका, 1000	00,687	00,695	00,344	00.00	00.00	00,721
ext। तालिका, 100000	00,648	00,697	01,323	००.१४	००.४९	14,613
में। तालिका, 100000	00,741	00,829	01,117	00.00	00.00	84,630

समय सेकंड में है।

नमूना 1: संबंधित ब्लॉक का उपयोग करते हुए, अनाम ब्लॉक से कर्सर के लिए एक एकल संबंध प्राप्त करें।
नमूना 2: संबंधित चर का उपयोग करके प्रक्रिया द्वारा एक संबंध का नमूना।
नमूना 3: एक अनाम ब्लॉक से कर्सर तक संबंधों का चयन करता है।
नमूना 4: कर्सर में प्रक्रिया द्वारा सभी रिश्तों का पहला चयन।
नमूना 5: कर्सर में प्रक्रिया द्वारा सभी रिश्तों के बाद के नमूने।
जोड़ें: n रिश्तों को जोड़ने का समय।

मैं यह कहना चाहूंगा कि यदि हम 1-2 सेकंड के बारे में बात कर रहे हैं, तो समय बिल्कुल भी महत्वपूर्ण नहीं है, लेकिन यह ध्यान में रखना चाहिए कि यह माना जाता है कि या तो वास्तविक डेटाबेस बड़ा होगा या सर्वर कमजोर होगा। यह तथ्य कि जिस सर्वर पर दोनों विकल्पों का परीक्षण किया गया था, वह काफी शक्तिशाली है, इसके माइनस भी हैं: साइड ऑपरेशन में बहुत अधिक समय लगता है, जिससे डेटा की थोड़ी मात्रा पर तुलना करना मुश्किल हो जाता है।

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

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

B.bus_number, d.driver_name का चयन करें टैब_बस बी से, टैब_ड्राइवर डी, बस_ड्राइवर आर जहां (b.b_id = r.bus_id) और (r.driver_id = d.d_id);

B.bus_number, d.driver_name का चयन करें टैब_बस बी से, टैब_ड्राइवर डी, टेबल (b.bus_drivers) आर जहां (b.b_id = p_bus) और (d.d_id = p_driver);

निष्कर्ष

सामान्य तौर पर, नेस्टेड तालिकाओं का उपयोग करके कई-से-कई संबंध बनाने का विचार उतना निराशाजनक नहीं था जितना कि यह पहले लग रहा था। इस तथ्य के बावजूद कि संबंध बनाने और हटाने के संचालन में परिमाण का एक क्रम लंबा होता है, यहां तक ​​कि बड़े प्रश्नों का चयन भी तेज हो जाता है, और क्वेरी संरचना स्वयं लगभग जटिलता में समान है। नमूना कोड की जटिलता से, दोनों दृष्टिकोण समान रूप से सरल हैं, लेकिन संबंध बनाने या निकालने के लिए, वैकल्पिक दृष्टिकोण के लिए अधिक कठिन है।

एक नेस्टेड तालिका का उपयोग करके एक रिश्ते को लागू नहीं किया जाना चाहिए यदि:

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

यह रिश्ते को वैकल्पिक तरीके से लागू करने के बारे में सोचने के लिए समझ में आता है, यदि

• एक तालिका कई-कई आधारों पर कई अन्य (डेटा की संरचना और तर्क की समझ को सरल करती है) से जुड़ी है;
  
• संबंध बहुत कम ही बनाए और मिटाए जाते हैं, और एक में रिकॉर्ड किए गए और लिंक किए गए तालिकाओं को हटा दिया जाता है और जोड़ा भी नहीं जाता है (गति में कोई हानि नहीं होती है);
  
• डेटाबेस के साथ काम करने के लिए, केवल प्रक्रियाओं, अभ्यावेदन और, संभवतः, चयन का उपयोग किया जाता है;
  
• कई तालिकाओं पर एक विदेशी कुंजी को लागू करने की आवश्यकता है, और एक पर नहीं (एक अधिक सुरुचिपूर्ण समाधान, कई कॉलम बनाने के विपरीत, खासकर जब से क्षेत्र के पहचानकर्ता के पत्राचार की जांच करने का कार्य किसी भी मामले में आवश्यक है)।