कई विशेषताओं वाले तालिका

Question

मैं कुछ डेटाबेस प्रोजेक्ट बनाने की योजना बना रहा हूं।

तालिकाओं में से एक में बहुत सारे गुण हैं।

मेरा प्रश्न है: कक्षा को 2 अलग-अलग तालिकाओं में विभाजित करने या उन्हें सभी को एक तालिका में रखने के लिए बेहतर क्या है। नीचे एक उदाहरण है

create table User { id, name, surname,... show_name, show_photos, ...) 

या

create table User { id, name, surname,...) 
create table UserPrivacy {usr_id, show_name, show_photos, ...) 

प्रदर्शन मैं लगता है की वजह से मैं सूचकांक का उपयोग कर सकते समान है।

Answer 1

मैं कुछ भिन्नता का सुझाव दूंगा। ऐसा लगता है कि भविष्य में आपको प्रबंधन के लिए 'अभी तक एक और विशेषता' के लिए कहा जाएगा। एक कॉलम जोड़ने के बजाय, आप केवल एक विशेषता तालिका में एक पंक्ति जोड़ सकते हैं:

TABLE Attribute 
(
    ID 
    Name 
) 
TABLE User 
(
    ID 
    ... 
) 
TABLE UserAttributes 
(
    UserID FK Users.ID 
    Attribute FK Attributes.ID 
    Value... 
) 

सभी से अच्छी टिप्पणियां। मुझे मेरी प्रतिक्रिया में स्पष्ट होना चाहिए था।

हम विशेष मामलों को संभालने के लिए यह बहुत कुछ करते हैं जहां ग्राहक हमें किसी भी तरह से उनके लिए अपनी साइट तैयार करने के लिए कहते हैं। हम एक प्रश्न में एनवीपी के स्तंभों में कभी भी 'पिवट' नहीं करते हैं - हम हमेशा पूछताछ करते हैं "क्या मुझे यह करना चाहिए?" किसी ग्राहक के लिए सूचीबद्ध एक विशिष्ट विशेषता की तलाश करके। यदि यह वहां है, तो यह एक 'सत्य' है। इसलिए इन्हें बूलियन-कॉलम का एक टन होने के बजाय, जिनमें से अधिकतर अधिकांश ग्राहकों के लिए झूठी या नल होगी, और इन सुविधाओं के लिए संख्या में वृद्धि की प्रवृत्ति, यह हमारे लिए अच्छा काम करता है।

Answer 2

यदि आप सभी गोपनीयता विशेषताओं को कम करने योग्य हैं और आपको शायद NULL के मान होंगे तो आपको टेबल को विभाजित करने पर विचार करना चाहिए।

इससे आपको मुख्य तालिका को छोटा रखने में मदद मिलेगी।

यदि गोपनीयता विशेषताओं को अधिकतर भर दिया जाएगा, तो तालिका को विभाजित करने में कोई बात नहीं है, क्योंकि डेटा को लाने के लिए अतिरिक्त JOIN एस की आवश्यकता होगी।

Answer 3

मैं 2 अलग-अलग टेबल कहूंगा विशेष रूप से यदि आप ओआरएम का उपयोग कर रहे हैं। ज्यादातर मामलों में प्रत्येक तालिका को किसी विशेष वस्तु से मेल खाने के लिए सर्वोत्तम होता है और उसके क्षेत्र या "विशेषताएँ" चीजें हैं जो उस ऑब्जेक्ट का वर्णन करने के लिए आवश्यक होती हैं।

आपको उपयोगकर्ता का वर्णन करने के लिए 'show_photos' की आवश्यकता नहीं है लेकिन आपको उपयोगकर्ता गोपनीयता का वर्णन करने की आवश्यकता है।

Answer 4

एक उपयोगकर्ता तालिका क्यों है और तालिका सुविधाएँ नहीं, जैसे:

create table User (id int primary key, name varchar(255) ...)

create table Features ( user_id int, feature varchar(50), enabled bit, primary key (user_id, feature) )

फिर अपने विशेषताएं तालिका में डेटा लगेगा जैसे:

 
| user_id | feature  | enabled 
| ------------------------------- 
| 291  | show_photos | 1 
| ------------------------------- 
| 291  | show_name | 1 
| ------------------------------- 
| 292  | show_photos | 0 
| ------------------------------- 
| 293  | show_name | 0 

Answer 5

यह सभी विशेषताओं डाल करने के लिए सबसे अच्छा है एक ही टेबल में।

यदि आप किसी तालिका में विशेषता नाम संग्रहीत करना प्रारंभ करते हैं, तो आप अपने डेटाबेस में मेटा डेटा संग्रहीत कर रहे हैं, जो पहले सामान्य रूप को तोड़ देता है।

इसके अलावा, उन्हें एक ही तालिका में रखने से आपके प्रश्नों को सरल बना दिया जाता है।

आप बल्कि होगा:

SELECT show_photos FROM User WHERE user_id = 1 

या

SELECT up.show_photos FROM User u 
LEFT JOIN UserPrivacy up USING(user_id) 
WHERE u.user_id = 1 

शामिल ठीक हैं, लेकिन उन्हें अलग संस्थाओं और 1-> एन रिश्ते जोड़ने के लिए रहते हैं।

कॉलम की संख्या की एक सीमा है, और केवल तभी यदि आपको लगता है कि आप उस सीमा को मार सकते हैं तो आप कुछ और करेंगे।

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

इसके अलावा, कृपया ध्यान दें कि उपयोगकर्ता पर आपका आईडी फ़ील्ड user_id होना चाहिए, न केवल आईडी, जब तक आप रूबी का उपयोग नहीं कर रहे हैं, जो केवल आईडी को मजबूर करता है। 'User_id' क्योंकि सिर्फ आईडी के साथ पसंद किया जाता है, अपने मिलती है इस तरह दिखेगा:

ON u.id = up.user_id 

कौन सा अजीब लगता है, और पसंदीदा तरीका यह है:

ON u.user_id = up.user_id 

या अधिक बस:

USING(user_id) 

'अभी तक एक और विशेषता जोड़ें' से डरो मत। यह सामान्य है, और यह ठीक है।

Answer 6

के बाद से यह एक रिश्ते के लिए एक प्रतीत होता है, मैं सामान्य रूप से यह सब एक तालिका में रखना होगा जब तक:

आप बाइट की संख्या कि एक पंक्ति में संग्रहित किया जा सकता की सीमा के पास हो सकता है - तो आपको इसे विभाजित करना चाहिए।

या यदि आप सामान्य रूप से मुख्य तालिका से अलग से पूछताछ करेंगे और अधिकतर समय उन क्षेत्रों की आवश्यकता नहीं होगी।

Answer 7

कुछ कॉलम (नहीं identifiable or dependentprimary key पर) है या उन स्तंभों के लिए एक अलग टेबल बनाने के लिए और एक एक के बाद एक के लिए संबंध बनाए रखने तालिका (एक definite/fixed सेट से मूल्यों repeatedly किया जा रहा है) है।