2012-01-26 10 views
11

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

  1. वस्तु के प्रत्येक प्रकार के लिए उपयोगकर्ता पसंदीदा के लिए एक मेज बनाने की है।
  2. सभी उपयोगकर्ताओं के लिए वस्तुओं के सभी प्रकार के लिए एक आम तालिका बनाओ।

1 संरचना के साथ समस्या यह है कि मैं एक विशेष उपयोगकर्ता की पसंदीदा प्रदर्शित करने के लिए टेबल के एक बहुत क्वेरी करने के लिए होगा। लेकिन यह मुझे पसंदीदा श्रेणियों को अलग-अलग श्रेणियों में आसानी से समूहित करने की अनुमति देगा।

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

दो रणनीतियों में से कौन अधिक विश्वसनीय हो जाएगा।

पहला वाला एकाधिक डेटाबेस प्रश्न पूछता है, और दूसरा एक एक बड़ी एकल तालिका में शामिल होता है।

यदि यह मदद करता है, मैं MySql

+0

# 2, अगर तालिका ठीक से सूचकांक है कि एक बड़ी मेज के खिलाफ क्वेरी प्रदर्शन # 1 के समान होना चाहिए। –

उत्तर

8

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

4

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

सबसे पहले अधिकांश भाग के लिए मॉड्यूल के लिए मेरे टेबल के सबसे उसी तरह संरचित कर रहे:

  • आईडी
  • शीर्षक
  • सामग्री
  • user_id (लेखक)
  • तारीख
  • आदि
किया जा रहा है कि कभी कभी शीर्षक प्रश्न कहा जाता है या कोई सामग्री स्तंभ है कुछ अपवादों के साथ

। इससे कोई समस्या नहीं आती है।

मेरे टेबल पसंद करती है इस तरह की स्थापना की है:

  • आईडी
  • page_id
  • module_id (क्या तालिका यह से आया ...मैं एक मॉड्यूल तालिका जहां प्रत्येक मॉड्यूल एक शीर्षक है, जुड़े आईडी, निर्देशिका, आदि)
  • post_id (मॉड्यूल तालिका आईडी से मेल खाती है)
  • user_id (उपयोगकर्ता के लिए जो पसंद या पोस्टिंग)
  • स्थिति किया (0 है = जैसे, 1 = नापसंद)
  • तारीख (जब पसंद/disliking जगह ले ली)

मॉड्यूल तालिका उदाहरण:

  • आईडी
  • शीर्षक
  • निर्देशिका
  • post_type

उदाहरण

id  title    directory   post_type 
1  News    news    news 
2  Episode Guide  episodes   episode 
3  Albums   discography/albums album 

अनिवार्य रूप से तुम्हारा एक समान सेट अप है, टेबल संरचना को संशोधित अपनी आवश्यकताओं के लिए आवश्यक के रूप में होगा।

क्वेरी किसी विशेष उपयोगकर्ता के लिए सभी पसंद और पसंदीदा पाने के लिए:

$getlikes = mysql_query("SELECT DISTINCT post_id, module_id, page_id FROM likes WHERE user_id = $profile_id ORDER BY id DESC LIMIT $offset, $likes_limit", $conn); 
$likes = mysql_num_rows($getlikes); 

if($likes == "0"){ 
echo "<br><Center>$profile_username does not have any liked posts at this time.</center><BR>"; 
} 
else { 
echo "<table width='100%' cellspacing='0' cellpadding='5'> 

<Tr><th>Post</th><th align='center'>Module</th><th align='center'>Page</th><tr>"; 

while ($rowlikes = mysql_fetch_assoc($getlikes)) { 
    // echo data 

$like_page_id = $rowlikes['page_id']; 
$like_module_id = $rowlikes['module_id']; 
$like_post_id = $rowlikes['post_id']; 


// different modules have different fields for the "title", most are called title but quotes is called "content" and polls is called "questions" 
if($like_module_id == "11"){ 
$field = "question"; 
} 
elseif($like_module_id == "19"){ 
$field = "content"; 
} 
else{ 
$field = "title"; 
} 





// FUNCTIONS 
PostURL($like_page_id, $like_module_id, $like_post_id); 
ModTitle($like_module_id); 
ModTable($like_module_id); 
ModURL($like_page_id, $like_module_id); 
fpgURL($like_page_id); 


$getpostinfo = mysql_query("SELECT $field AS field FROM $mod_table WHERE id = $like_post_id", $conn); 
$rowpostinfo = mysql_fetch_assoc($getpostinfo); 
$like_post_title = $rowpostinfo['field']; 

// Using my "tiny" function to shorten the title if the module is "Quotes" 
if($like_module_id == "19"){ 
Tiny($like_post_title, "75"); 
$like_post_title = "\"$tiny\""; 
} 


if(!$like_post_title){ 
$like_post_title = "<i>Unknown</i>"; 
} 
else { 
$like_post_title = "<a href='$post_url'>$like_post_title</a>"; 
} 

echo "<tr class='$altrow'> 
<td>$like_post_title</td> 
<td align='center'><a href='$mod_url'>$mod_title</a></td> 
<td align='center'>$fpg_url</td> 


</tr>"; 

$altrow = ($altrow == 'altrow')?'':'altrow'; 

} // end while 

echo "<tr><Td align='center' colspan='3'>"; 

// FUNCTIONS - Pagination links 
PaginationLinks("$cs_url/users/$profile_id", "likes"); 

echo "</td></tr></table>"; 

} // end else if no likes 

ठीक है कि मुश्किल के बाद से मैं अपने ही चर के बहुत है आप को समझने के लिए हो सकता है, लेकिन मूल रूप से यह मॉड्यूल आईडी हो जाता है और पसंद तालिका से आईडी पोस्ट करें और फिर पोस्ट का शीर्षक पाने के लिए एक क्वेरी चलाएं और कोई अन्य जानकारी जिसे मैं मूल लेखक की तरह चाहता हूं।

"मॉड्यूल" कार्यों सेट मैं किया है कि यूआरएल या मॉड्यूल के शीर्षक दिया तो इसके लिए आपको आईडी प्रदान वापस आ जाएगी।

+0

हे आपके द्वारा दिए गए संपूर्ण उत्तर के लिए बहुत बहुत धन्यवाद। मेरे पास एक संरचना भी आपके समान है, इसलिए इसे एक ही टेबल में रखना मुश्किल नहीं है। इसके अलावा मैं अजगर के 'Django' ढांचे में काम कर रहा हूं जिसमें एक सामान्य विदेशी कुंजी है। यह मुझे एक ही तालिका में अलग-अलग ऑब्जेक्ट संदर्भ रखने की अनुमति देता है। लेकिन मेरा प्रश्न परिचालन नहीं है प्रदर्शन के आधार पर अधिक है। क्या होगा जब उपयोगकर्ताओं की संख्या में वृद्धि होगी और ये टेबल भरना शुरू हो जाएंगे? – Sachin