एसक्यूएल: यह रिकॉर्ड करने के लिए सबसे तेज़ प्रश्न क्या है कि किसी रिकॉर्ड को रिकॉर्ड किया गया है

मेरे पास यह टेबल संरचना है

Table A
-------
id , name
1  , A1
2  , A2
3  , A3
4  , A4
5  , A5
6  , A6

Table B
-------
id , name , tableA_id
1  , B1   , 1
2  , B2   , 2
....

Table C
-------
id , name , tableA_id
1  , C1   , 3
2  , C2   , 4
....

Table D
-------
id , name , tableA_id
1  , C1   , 5
2  , C2   , 6
....

प्रश्न

  • अगर मुझे टेबल ए आईडी दी गई थी: 3 खोजने का सबसे तेज़ तरीका क्या है बी, सी, डी टेबल से संबंधित पंक्ति?
  • मैं इसे बहुत से चलाऊंगा यह ठीक रहेगा?
  • मैं कैसे सुनिश्चित कर सकता हूं कि तालिका में प्रत्येक रिकॉर्ड के लिए ए केवल 1 और केवल 1 रिकॉर्ड होगा बी या सी, डी
  • क्या मैं संरचना में सुधार करने के लिए कुछ भी कर सकता हूं ताकि मैं तेज़ी से पूछताछ के लिए जो खोज रहा हूं उसे प्राप्त कर सकूं? मैं 2 समाधानों के बारे में सोच रहा था लेकिन मुझे यकीन नहीं है कि यह एक अच्छा अभ्यास होगा

समाधान 1:

Table A
-------
id , name , B_id, C_id, D_id
1  , A1   ,  1  ,     ,
2  , A2   ,  2  ,     ,
3  , A3   ,     ,  1  ,
4  , A4   ,     ,  2  ,
5  , A5   ,     ,     , 1
6  , A6   ,     ,     , 2

समाधान 2:

Table A
-------
id , name , table, id
1  , A1   ,  B  ,  1
2  , A2   ,  B  ,  2
3  , A3   ,  C  ,  1
4  , A4   ,  C  ,  2
5  , A5   ,  D  ,  1 
6  , A6   ,  D  ,  2

लेकिन मैं दोनों समाधानों से सहज नहीं हूं क्योंकि मुझे नहीं लगता कि मैं प्रतिबंध लागू कर सकता हूं/इसे उचित विदेशी कुंजी के रूप में मानचित्र बना सकता हूं

1
@uvais सब कुछ एक उद्देश्य है, अन्यथा कोई बी, सी, डी नहीं होगा
जोड़ा लेखक trrrrrrm, स्रोत
@ क्लॉकवर्क-म्यूज़ जो मैं हासिल करने की कोशिश कर रहा हूं वह यह है कि मेरे पास 3 अलग-अलग लेबल हैं जिन्हें मैं अपनी वेबसाइट में बेच रहा हूं (फर्नीचर, कार, घर) उनमें से प्रत्येक में अपनी संपत्तियां और उपयोग में आसान है। वे कुछ कॉलम (शीर्षक, desc .. आदि) के रूप में साझा करते हैं लेकिन उनमें से प्रत्येक में 10+ अद्वितीय कॉलम होते हैं। लेकिन आदेश/गाड़ी/अन्य स्तरों पर उन्हें सभी उत्पाद के रूप में माना जाता है। मैं उन सभी को जोड़ने का एक तरीका ढूंढने की कोशिश कर रहा हूं, इसलिए कार्ट/ऑर्डर में मैं product_id से निपट सकता हूं, जिस पर मुझे कोई परवाह नहीं है कि यह ऑर्डर टेबल बनाने के बजाय कार या घर है - उ
जोड़ा लेखक trrrrrrm, स्रोत
@uvais मैंने वर्णन किया कि मैं क्या करने की कोशिश कर रहा हूं, धन्यवाद!
जोड़ा लेखक trrrrrrm, स्रोत
जबकि मुझे एक ही टेबल में सबकुछ डालने के बारे में पता नहीं है, यह जानने के लिए कि आप सिस्टम का उपयोग कर हैं क्या एक अच्छा विचार है। इसके अलावा, 'अद्वितीय' लिंक वाली पंक्ति प्राप्त करने का प्रयास करना आपके वर्तमान डिज़ाइन के साथ मुश्किल होगा; मेरा मानना ​​है कि अधिकांश/सभी आरडीबीएमएस को ट्रिगर्स की आवश्यकता होगी, और आपको इसे काम करने के लिए अनिवार्य रूप से टेबल (और जोखिम डेडलॉक) को लॉक करना होगा। आपके अन्य समाधान इस प्रारंभिक समस्या को हल करते हैं, लेकिन मुझे उन्हें बहुत पसंद नहीं है; क्या हम अधिक जानकारी प्राप्त कर सकते हैं? यह संभावित तालिका-विरासत समस्या है, लेकिन मुझे नहीं
जोड़ा लेखक Clockwork-Muse, स्रोत
आप किस उद्देश्य के लिए टेबल बी, सी, डी का उपयोग कर रहे हैं? मुझे कृपया बताएं, मुझे लगता है कि कोई ज़रूरत नहीं है, एक टेबल पर्याप्त हो सकता है क्योंकि आप सभी तीन तालिकाओं में एक ही डेटा संग्रहीत कर रहे हैं
जोड़ा लेखक uvais, स्रोत
ठीक है तो आप बाहरी शामिल हो सकते हैं
जोड़ा लेखक uvais, स्रोत
और आप वास्तव में क्या चाहते हैं, कृपया इसे आकर्षित करें
जोड़ा लेखक uvais, स्रोत

2 उत्तर

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

ID, Name, CategoryType, tableA_id

नमूना डेटा के साथ:

ID  Name  CategoryType tableA_id
1   C1     C             1
2   B1     B             2
3   A1     A             3

हालांकि यदि तालिका ए में एक रिकॉर्ड तालिका बी या सी या डी में एक और एक रिकॉर्ड से संबंधित है तो यह एक तालिका में होना चाहिए।

दूसरी तरफ, आपकी वर्तमान डीबी संरचना का उपयोग करके आप संभवतः एक कोड दिखाए जाने के लिए परिणाम और LIMIT 1 को मर्ज करने के लिए UNION ALL का उपयोग कर सकते हैं, जैसे:

SELECT a.id, b.name as OneName
FROM tableA A
INNER JOIN tableB B
ON a.id = b.tableA_id
UNION ALL
SELECT a.id, b.name as OneName
FROM tableA A
INNER JOIN tableC C 
ON a.id = c.tableA_id
UNION ALL
SELECT a.id, b.name as OneName
FROM tableA A
INNER JOIN tableC D 
ON a.id = d.tableA_id
LIMIT 1
1
जोड़ा
मैं पूरी तरह से समझता हूं लेकिन प्रत्येक बी, सी, डी टेबल में 10+ अद्वितीय कॉलम होते हैं, इसलिए उन्हें विलय करना लंबे समय तक अच्छा विचार नहीं लगता है, मैं तालिका ए में साझा कॉलम रखता हूं और उनमें से प्रत्येक के लिए अद्वितीय कॉलम अपनी तालिका में रखता हूं ।
जोड़ा लेखक trrrrrrm, स्रोत
यदि ऐसा है तो आपके द्वारा दिखाए गए आपके समाधान 1 और 2 दोनों एक अच्छा समाधान भी नहीं होंगे। तो, जिसका अर्थ है कि आप अपनी वर्तमान डीबी संरचना के साथ चिपके रहते हैं और आप शायद यूनियन ऑल (सभी सामान्य क्षेत्रों के लिए) और फिर LIMIT 1 का उपयोग करके यह सुनिश्चित कर सकते हैं कि तालिका बी, सी या डी में केवल एक ही मैच शामिल है।
जोड़ा लेखक Edper, स्रोत

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

Product_Category
----------------
id  -- autoincrement id
name  --  varchar

Product
----------
id  -- autoincrement id
productCategoryId  -- fk referenct to Product_Category.id
name  -- varchar
price  -- decimal/numeric
(other columns as needed)

Attribute
------------
id  -- autoincrement id
name  -- varchar
type  -- code
description  -- varchar

Product_Attribute
-------------------
productId  -- fk reference to Product.id
attributeId -- fk reference to Attribute.id
value  -- varchar

(हाँ, जितना मैं सामान्य रूप से ईएवी सेटअप को नफरत करता हूं, यह इस तरह का मामला है जिसके लिए इसे बनाया गया था)

इस तरह की चीजें क्यों करते हैं? खैर, आम तौर पर जब भी आप एक नया उत्पाद प्रकार जोड़ते हैं तो एक नई टेबल जोड़ने के लिए बहुत अच्छा नहीं है। असल में, आप product के अंदर जितना संभव हो उतना गुण रखना चाहते हैं - इसे संतुलित संतुलन करने की आवश्यकता होगी - यह जानने का प्रयास करें कि कुछ सामान्य रूप से पूछे जाने वाले गुण क्या हैं और उन्हें उस तालिका में रखें, < em> भले ही प्रत्येक श्रेणी में उन्हें न हो (जाहिर है, इसके लिए निरर्थक कॉलम की आवश्यकता होगी) इसके अतिरिक्त, कुछ <कोड> उत्पाद कॉलम संभावित रूप से 'डबल ड्यूटी' (... प्रकार ...) खींच सकते हैं; कारों में स्पष्ट रूप से रंग होता है, जैसा कि फर्नीचर करता है - यह केवल एक रंग है और दूसरा दाग है।
बाकी सब कुछ Product_Attribute में जाता है। गुणों और डुप्लिकेट प्रविष्टियों के गलत वर्तनी जैसी चीजों को रखने में मदद के लिए विशेषता के उपयोग पर ध्यान दें (और यह आपके उत्पाद-प्रविष्टि टीम को कुछ नहीं होना चाहिए, ग्राहकों को नहीं)। हालांकि, आपको आश्चर्य हो सकता है कि आपके शीर्षक/विवरणों पर एक अच्छी अनुक्रमणिका और खोज फ़ंक्शन क्या उत्पन्न कर सकता है।

1
जोड़ा
आपके उत्तर के लिए बहुत बहुत धन्यवाद, मेरे पास सिर्फ एक प्रश्न है, मोटे तौर पर प्रदर्शन को प्रभावित किए बिना उत्पाद तालिका कितने कॉलम/रिकॉर्ड हो सकती है?
जोड़ा लेखक trrrrrrm, स्रोत
धन्यवाद! बहुत बढ़िया जवाब
जोड़ा लेखक trrrrrrm, स्रोत
मुझे नहीं पता कि MySQL क्या ऊपर है (कृपया अपने दस्तावेज़ों से परामर्श लें, लेकिन आप आमतौर पर वास्तविक डीबी सीमा को हिट करने से पहले कॉलम गिनती के लिए 'अच्छी डिजाइन' सीमा में भाग लेते हैं। पंक्ति गणना के लिए, यह उस पर आधारित होगा हार्डवेयर जिसका आप उपयोग कर रहे हैं, और 'प्रदर्शन' से आपका क्या मतलब है - अधिकांश आधुनिक आरडीबीएमएस 1000 पंक्तियों के तहत पूरी तरह से स्मृति में कुछ भी स्टोर करते हैं। कम से कम, आप सूचकांक का एक अच्छा सेट चाहते हैं। सभ्य 'सर्वर' हार्डवेयर मानते हैं, आप किसी तालिका में 1 मिलियन पंक्तियों के बाद तक कोई वास्तविक समस्या नहीं होगी ...
जोड़ा लेखक Clockwork-Muse, स्रोत