डेटाबेस

Question

में गुणों की गतिशील संख्या वाले डेटा को कैसे संग्रहीत करें मेरे पास अलग-अलग गुणों के साथ कई अलग-अलग ऑब्जेक्ट्स हैं। अब तक मैंने XML फ़ाइलों में डेटा सहेजा है जो आसानी से गुणों की एक सतत संख्या की अनुमति देता है। लेकिन मैं इसे डेटाबेस में ले जाने की कोशिश कर रहा हूं।

इस डेटा को स्टोर करने का आपका पसंदीदा तरीका क्या होगा?

कुछ रणनीतियों मैं अब तक पहचान की है:

• होने एक ही नामित क्षेत्र "विशेषता" वस्तु की तालिका में और डेटा धारावाहिक या वहाँ में json'ed की दुकान।
• डेटा को दो तालिकाओं (वस्तुओं, विशेषताओं) में संग्रहित करना और संबंधों को बचाने के लिए तीसरे का उपयोग करना, इसे एक वास्तविक n: m संबंध बनाना। बहुत साफ समाधान, लेकिन संभवतः एक संपूर्ण वस्तु और उसके सभी गुणों को लाने के लिए बहुत महंगा है
• गुणों की पहचान करना सभी वस्तुओं में समान है और इनके लिए ऑब्जेक्ट की तालिका में फ़ील्ड बनाना है। शेष गुणों को दूसरे क्षेत्र में क्रमबद्ध डेटा के रूप में स्टोर करें। खोजों को आसान बनाने, पहली रणनीति पर इसका लाभ है।

कोई विचार?

Answer 1

अद्यतन नहीं कर सकते तो आप विशिष्ट attribtes के लिए खोज पर कभी योजना है, यह करने के लिए एक बुरा विचार है, तो आप विशेषताओं द्वारा फ़िल्टर नहीं कर सकते -

Sstuffing> 1 एक ही ब्लॉब में विशेषता नहीं की सिफारिश की है उन्हें एक कॉलम में क्रमबद्ध करें, क्योंकि आपको जानकारी प्राप्त करने के लिए प्रति पंक्ति कार्यों का उपयोग करना होगा - यह कभी भी स्केल नहीं करता है।

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

उदाहरण के लिए:

objects: 
    object_id integer 
    object_name varchar(20) 
    primary key (object_id) 
attributes: 
    attr_id  integer 
    attr_name varchar(20) 
    primary key (attr_id) 
object_attributes: 
    object_id integer references (objects.object_id) 
    attr_id  integer references (attributes.attr_id) 
    primary key (object_id,attr_id) 

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

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

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

Answer 2

लगता है जैसे आपको कुछ चाटना couchdb, आरडीबीएमएस नहीं चाहिए।

टी 1:

Answer 3

अपने 2 डी समाधान पर एक बदलाव सिर्फ दो तालिकाओं (यह मानते हुए सभी विशेषताओं एक ही प्रकार के कर रहे हैं) है | ऑब्जेक्ट डेटा स्तंभ | object_id |

टी 2: | ऑब्जेक्ट आईडी | attribute_name | विशेषता मूल्य | (पहले 2 कॉलम पर अद्वितीय अनुक्रमणिका)

यह तीसरा समाधान, उदाहरण के साथ संयुक्त होने पर और भी अधिक कुशल है। सभी सामान्य क्षेत्र टी 1 में जाते हैं। आप कुशलतापूर्वक उन्हें

Answer 4

यदि आप बाद के बिंदुओं में विशेषताओं को संपादित/कुशल/हटाने के लिए जा रहे हैं, तो एक वास्तविक n: m (दूसरा विकल्प) एक ऐसा होगा जो मैं जाता हूं। (या इसे 2 टेबल बनाने का प्रयास करें जहां एक ही विशेषता दोहराती है। लेकिन डेटा का आकार ऊंचा होगा)

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

Answer 5

यदि आप एक रिलेशनल डीबी का उपयोग कर रहे हैं, तो मुझे लगता है कि आपने विकल्प सूचीबद्ध करने के लिए एक अच्छी नौकरी की है। उनमें से प्रत्येक के पास उनके पेशेवर और विपक्ष हैं। आप यह तय करने के लिए सबसे अच्छी स्थिति में हैं कि आपकी परिस्थितियों के लिए सबसे अच्छा क्या काम करता है।

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

संपादित करें - अपनी टिप्पणियों को और पढ़ें, यदि आप अपनी मुख्य चिंता करते हैं तो आप डीबी पर क्यों स्विच कर रहे हैं। आपके वर्तमान एक्सएमएल कार्यान्वयन के बारे में क्या बात है?

Answer 6

मैं this scheme लागू करने के लिए प्रयोग किया है:

t_class (id RAW(16), parent RAW(16)) -- holds class hierachy. 
t_property (class RAW(16), property VARCHAR) -- holds class members. 
t_declaration (id RAW(16), class RAW(16)) -- hold GUIDs and types of all class instances 
t_instance (id RAW(16), class RAW(16), property VARCHAR2(100), textvalue VARCHAR2(200), intvalue INT, doublevalue DOUBLE, datevalue DATE) -- holds 'common' properties 

t_class1 (id RAW(16), amount DOUBLE, source RAW(16), destination RAW(16)) -- holds 'fast' properties for class1. 
t_class2 (id RAW(16), comment VARCHAR2(200)) -- holds 'fast' properties for class2 
--- etc. 

RAW(16) वह जगह है जहाँ Oracle रखती GUID रों

आप एक वस्तु के लिए सभी गुण का चयन करना चाहते हैं, तो आप जारी करते हैं:

SELECT i.* 
FROM (
     SELECT id 
     FROM t_class 
     START WITH 
       id = (SELECT class FROM t_declaration WHERE id = :object_id) 
     CONNECT BY 
       parent = PRIOR id 
     ) c 
JOIN property p 
ON  p.class = c.id 
LEFT JOIN 
     t_instance i 
ON  i.id = :object_id 
     AND i.class = p.class 
     AND i.property = p.property 

t_property जिन सामानों को आप सामान्य रूप से खोज नहीं करते हैं उन्हें पकड़ें (जैसे, टेक्स्ट विवरण इत्यादि)

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

आपको तेज़ तालिकाओं का उपयोग करने और इन सभी तालिकाओं में अपने सभी डेटा को सीमित करने की आवश्यकता नहीं है।

Answer 7

मुझे DVK क्या कह रहा था के बारे में कुछ समझदारी दें।

मान लिया जाये कि मान तालिका कैसा दिखेगा एक ही प्रकार के कर रहे हैं (अच्छी किस्मत, मुझे लगता है कि आप इसे जरूरत के लिए जा रहे):

 
dynamic_attribute_table 
------------------------ 
id   NUMBER 
key  VARCHAR 
value  SOMETYPE? 

उदाहरण (कार):

 
|id| key | value | 
--------------------------- 
| 1|'Make' |'Ford'  | 
| 1|'Model' |'Edge'  | 
| 1|'Color' |'Blue'  | 
| 2|'Make' |'Chevrolet'| 
| 2|'Model' |'Malibu' | 
| 2|'MaxSpeed'|'110mph' | 

इस प्रकार ,
इकाई 1 = {('मेक', 'फोर्ड'), ('मॉडल', 'एज'), ('रंग', 'ब्लू'),
और,
इकाई 2 = {('मेक ',' शेवरलेट '), (' मॉडल ',' मालिबू '), (' मैक्सस्पेड ',' 110 एमएफ ')}।