मैं वर्तमान में अपने SQL डेटाबेस के भीतर एक तालिका को लागू करने का प्रयास कर रहा हूं। मैं एक टेबल बनाना चाहता हूं जिसका उपयोग यह जांचने के लिए किया जा सकता है कि मेरी वेबसाइट पर किसी उपयोगकर्ता ने कोई पोस्ट पसंद किया है या नहीं। विचार यह है कि वेबसाइट पर पदों को पुनरावृत्त करने वाली एक अक्ष वाली तालिका और उपयोगकर्ता आईडी मानों के साथ एक अक्ष पुनरावृत्त हो। फिर प्रत्येक बॉक्स में एक बाइनरी मान रखें कि क्या उन्हें यह पसंद आया है। मैं बस सोच रहा हूं कि मैं इसे कैसे कार्यान्वित करूंगा। मैं इसे सी # में एंटिटी फ्रेमवर्क 6.4.0 का उपयोग करके कक्षाएं बनाकर और सर्वर साइड कोड में परिवर्तित करके कर रहा हूं। कोई भी मदद बहुत अच्छी रहेगी।

0
Stuart Jerry 3 मार्च 2020, 18:36
1
ऐसा लगता है कि आपको डेटाबेस में कई-से-अनेक संबंध तालिका की आवश्यकता है
 – 
Tal
3 मार्च 2020, 18:41
लगता है जैसे आपको एक त्वरित डेटाबेस डिज़ाइन ट्यूटोरियल करके शुरुआत करने की आवश्यकता है। ईथर पीएस में 1000 हैं, इसे उस तरह से न करें जिस तरह से आपने वर्तमान में अनुमान लगाया है
 – 
RiggsFolly
3 मार्च 2020, 18:42

2 जवाब

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

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

निम्नलिखित कॉलम के साथ तालिका user_like_posts कहें:

user_id -- foreign key to the "users" table
post_id -- foreign key to the "posts" table

आप ब्रिज टेबल में अतिरिक्त कॉलम जोड़ना चाह सकते हैं, जैसे टाइमस्टैम्प जब उपयोगकर्ता ने पोस्ट को पसंद किया, या इसी तरह।

0
GMB 3 मार्च 2020, 18:44

क्या हर पोस्ट पर हर यूजर की राय होगी? यदि नहीं तो आपके पास आपके द्वारा वर्णित डेटा नहीं है। यदि उपयोगकर्ता और पोस्ट एक से एक से संबंधित नहीं हैं तो आपका एक साधारण संबंध है। उपयोगकर्ता द्वारा पसंद की जाने वाली (या नापसंद?) प्रत्येक पोस्ट के लिए उस उपयोगकर्ता के लिए एक प्रविष्टि है:

पसंद/नापसंद तालिका: उपयोगकर्ता पहचानकर्ता पोस्ट पहचानकर्ता बाइनरी मान जो पसंद या नापसंद को इंगित करता है

यदि तालिका केवल 'पसंद' इंगित करती है तो आपको अंतिम कॉलम की आवश्यकता नहीं है।

इस तरह का एक डिज़ाइन काम करेगा, भले ही प्रत्येक उपयोगकर्ता और प्रत्येक पोस्ट इस तालिका में हो। तालिका जल्दबाजी में बड़ी हो सकती है और हर बार जब आप कोई नई पोस्ट पेश करते हैं तो बढ़ती रहती है। लेकिन अगर इस तालिका में केवल वास्तविक 'पसंद' (और/या 'नापसंद') शामिल हैं तो इसे प्रबंधनीय होना चाहिए।

एक वर्ग के लिए आपके पास केवल एक गणना योग्य है जिसमें पोस्ट 'पसंद' हैं (और संभवतः दूसरा जो 'नापसंद' पदों को इंगित करता है।)

इस बारे में सोचें कि आप क्या प्रतिनिधित्व करने की कोशिश कर रहे हैं। अपने आप से प्रश्न पूछें। किसी विचार को केवल पकड़कर न रखें और उसे 'करने' का प्रयास करें।

क्या हर पोस्ट के बारे में हर यूजर की राय होगी? क्या आपको 'पसंद' और 'नापसंद' दोनों को स्टोर करने की ज़रूरत है? क्या किसी पोस्ट पर 'तटस्थ' राय हो सकती है? क्या उपयोगकर्ता अपनी राय बदल सकते हैं?

आप केवल उन सभी प्रश्नों को पूछकर और उत्तर देकर सही डेटा संरचना की खोज कर सकते हैं जो आपकी स्थिति के लिए महत्वपूर्ण हैं (मेरी सूची संपूर्ण नहीं है - यह केवल एक उदाहरण है।)

0
TerrierJack 3 मार्च 2020, 19:02