दुनिया में क्यों मेरे पास कई संबंध होंगे?

Question

मैं सिर्फ रिश्ते और डेटाबेस के बारे में एक दिलचस्प स्थिति में फंस गयी। मैं एक रूबी ऐप लिख रहा हूं और मेरे डेटाबेस के लिए मैं postgresql का उपयोग कर रहा हूं। मेरे पास एक मूल वस्तु "उपयोगकर्ता" और संबंधित वस्तु "चीज़" है जहां उपयोगकर्ता के पास एक या अधिक चीज़ें हो सकती हैं। अभिभावक तालिका में किसी फ़ील्ड के भीतर डेटा को एम्बेड करने के लिए एक अलग तालिका का उपयोग करने का क्या फायदा होगा?

ActiveRecord से

उदाहरण:

एक संबंधित तालिका का उपयोग कर:

def change 
    create_table :users do |i| 
     i.text :name 
    end 
    create_table :thingies do |i| 
     i.integer :thingie 
     i.text :discription 
    end 
end 
class User < ActiveRecord::Base 
    has_many :thingies 
end 
class Thingie < ActiveRecord::Base 
    belongs_to :user 
end 

एक एम्बेडेड डेटा संरचना का उपयोग कर (बहुआयामी सरणी) विधि:

def change 
    create_table :users do |i| 
     i.text :name 
     i.text :thingies, array: true # example contents: [[thingie,discription],[thingie,discription]] 
    end 
end 
class User < ActiveRecord::Base 
end 

प्रासंगिक जानकारी

मैं हम हूँ मेरे डेटाबेस के रूप में heroku और heroku-posgres ing। मैं अपने मुफ़्त विकल्प का उपयोग कर रहा हूं, जो मुझे 10,000 पंक्तियों तक सीमित करता है। ऐसा लगता है कि मैं बहुआयामी सरणी तरीके का उपयोग करना चाहता हूं, लेकिन मुझे वास्तव में पता नहीं है।

Answer 1

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

मामलों में जहां एम्बेडेड क्षेत्र अधिक उपयुक्त हो सकता है कर रहे हैं, लेकिन इस सवाल का एक उदाहरण के रूप में मैं एक मामला है कि एक संबंधित तालिका approch के फायदे पर प्रकाश डाला गया का उपयोग करेगा के लिए।

एक ब्लॉग के लिए एक उपयोगकर्ता और पोस्ट उदाहरण कल्पना कीजिए।

एक एम्बेडेड पद समाधान के लिए, अगर आप इस तरह एक मेज कुछ (psuedocode - इन शायद वैध DDL नहीं हैं) के लिए होता है:

create table Users { 
id int auto_increment, 
name varchar(200) 
post text[][], 
} 

संबंधित तालिकाओं के साथ

, आप

create table Users { 
id int auto_increment, 
name varchar(200) 
} 
create table Posts { 
id auto_increment, 
user_id int, 
content text 
} 

की तरह कुछ करना होगा

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

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

Editor.where(name: 'Bob').posts 

एम्बेडेड पक्ष के लिए, आप डेटाबेस में प्रत्येक उपयोगकर्ता के माध्यम से चलने के लिए कोड लिखने के लिए होता है हर एक को पार्स उनके पदों के और संपादक क्षेत्र में 'बॉब' की तलाश करें।

प्रदर्शन: कल्पना कीजिए कि आपके पास 10,000 उपयोगकर्ताओं के औसत के साथ 10,000 उपयोगकर्ता हैं। अब आप एक निश्चित तारीख पर किए गए सभी पदों को खोजना चाहते हैं। एम्बेडेड फ़ील्ड के साथ, आपको प्रत्येक रिकॉर्ड के माध्यम से लूप करना होगा, सभी पोस्टों की पूरी सरणी पार्स करना होगा, तिथियां निकालें और अपनी इच्छानुसार जांच करें। यह दोनों cpu और डिस्क i/0 चबाएगा। डेटाबेस के लिए, आप आसानी से दिनांक फ़ील्ड को अनुक्रमित कर सकते हैं और प्रत्येक उपयोगकर्ता से प्रत्येक पोस्ट को पार्स किए बिना आपको आवश्यक सटीक रिकॉर्ड खींच सकते हैं।

मानकों: एक विक्रेता विशिष्ट डेटा संरचना का उपयोग करना मतलब है कि आपके एप्लिकेशन को दूसरे डेटाबेस में ले जाना दर्द हो सकता है। पोस्टग्रेज़ में डेटा प्रकारों का समृद्ध सेट प्रतीत होता है, लेकिन वे MySQL, ओरेकल, एसक्यूएल सर्वर आदि के समान नहीं हैं। यदि आप मानक डेटा प्रकारों के साथ चिपके रहते हैं, तो आपके पास बैकएंड्स को स्वैप करने में बहुत आसान समय होगा।

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

Answer 2

क्या होगा यदि उपयोगकर्ता जॉन और एन में समान चीज़ें हों? रिकॉर्ड डुप्लिकेट किए जाएंगे और यदि आप चीज का नाम बदलने का फैसला करते हैं तो आपको दो या दो से अधिक रिकॉर्ड्स बदलना होगा। यदि चीज़ को अलग तालिका में संग्रहीत किया जाता है तो आपको केवल एक रिकॉर्ड बदलना होगा। FYI करें https://en.wikipedia.org/wiki/Database_normalization

Answer 3

एक के लाभ कई लोगों के लिए:

1. आसान ORM (वस्तु संबंधपरक मानचित्रण) एकीकरण। आप इसे किसी भी तरह से उपयोग कर सकते हैं, लेकिन आपको मूल सारणी के साथ अपनी तालिकाओं को परिभाषित करना होगा। अलग-अलग तालिकाओं को रखना आसान है और आप ऑटो-जनरेटेड मैपिंग का उपयोग कर सकते हैं।
2. 10,000 पंक्तियों की आपकी अंतरिक्ष सीमा इस मामले में कई रिश्तों के साथ आगे बढ़ेगी कि 2 या अधिक लोगों के पास "चीजें" हो सकती हैं।
3. उपयोगकर्ताओं और चीज़ों को अलग से संभाल लें। कुछ मामलों में, आप केवल लोगों या चीज़ों की देखभाल कर सकते हैं, न कि एक दूसरे के साथ उनके रिश्ते। कुछ उदाहरण, उपयोगकर्ता नाम या चीज़ विवरण को अपडेट करना, सभी चीज़ों (या सभी उपयोगकर्ताओं) की एक सूची प्राप्त करना। एकल तालिका से चयन करने से यह काम करने में कठिनाई हो सकती है।
4. रखरखाव और हेरफेर आसान है। यदि उपयोगकर्ता या किसी चीज़ को अपडेट किया गया है (नाम परिवर्तन, ईमेल पता अपडेट इत्यादि), तो आपको अपडेट स्टेटमेंट्स लिखने के बजाय केवल अपनी तालिका में 1 रिकॉर्ड अपडेट करना होगा "जहां user_id =?"।
5. लागू करने योग्य डेटाबेस बाधाएं। क्या होगा यदि किसी चीज़ का स्वामित्व किसी के पास नहीं है? क्या उपयोगकर्ता कॉलम अब शून्य है? इसे एकल तालिका के मामले में होना होगा, इसलिए उदाहरण के लिए, आप एक सरल "शून्य नहीं" उपयोगकर्ता नाम लागू नहीं कर सके।

पाठ्यक्रम के कई कारण हैं। यदि आप एक रिलेशनल डेटाबेस का उपयोग कर रहे हैं, तो आपको अपनी ऑब्जेक्ट्स (उपयोगकर्ता और चीज़ों) को अलग-अलग टेबल के रूप में अलग करके कई लोगों का उपयोग करना चाहिए। रिकॉर्ड की संख्या पर अपनी सीमा को ध्यान में रखते हुए और आपके डेटासेट का आकार छोटा है (10,000 से कम), आपको सामान्यीकृत डेटा के नीचे की ओर महसूस नहीं करना चाहिए।

छोटी सच्चाई यह है कि दोनों के लाभ हैं। उदाहरण के लिए, आप एकल तालिका दृष्टिकोण से तेज़ी से पढ़ने के समय प्राप्त कर सकते हैं क्योंकि आपको जटिल जुड़ाव की आवश्यकता नहीं है।

यहां दोनों के पेशेवरों/विपक्ष के साथ एक अच्छा संदर्भ है (सामान्यीकृत एकाधिक तालिका दृष्टिकोण है और denormalized एकल तालिका दृष्टिकोण है)। http://www.ovaistariq.net/199/databases-normalization-or-denormalization-which-is-the-better-technique/

Answer 4

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