एक ही आईडी के साथ नई और अंतिम सम्मिलित प्रविष्टि का योग कैसे करें और नई प्रविष्टि में परिणाम सम्मिलित करें

दृष्टिकोण

आपके दृष्टिकोण में दो त्रुटियां हैं, जो जटिलता का परिचय देती हैं।

1. कोई भी स्तंभ जो व्युत्पन्न किया जा सकता है, जैसे कि आपका AVERAGE नहीं . होना चाहिए संग्रहित किया जाए।

   यदि इसे संग्रहीत किया जाता है, तो यह एक डुप्लिकेट कॉलम बनाता है ... जो एक अद्यतन विसंगति की ओर जाता है, जैसा कि आप अनुभव कर रहे हैं। सामान्यीकरण का उद्देश्य डेटा दोहराव को समाप्त करना है, और इस प्रकार अद्यतन विसंगतियों को समाप्त करना है। यह इस तरह के जटिल कोड के साथ-साथ ट्रिगर आदि को भी समाप्त करता है।

   परिणाम सेट केवल . में SUM(), AVG(), आदि की गणना करें , मक्खी पर।

2. आईडी कॉलम का उपयोग, जिसका मूल रूप से मतलब है कि आपके पास एक रिकॉर्ड फाइलिंग सिस्टम है, कोई रिलेशनल डेटाबेस नहीं है। इसके कारण होने वाली कई समस्याओं की गणना किए बिना (मैंने इसे कहीं और किया है), बस समस्या का नाम यहाँ बता रहे हैं

   • आपके पास एक आईडी मानसिकता है।

   आईडी एक भौतिक रिकॉर्ड सूचक है, यह संबंधपरक डेटाबेस के लिए आवश्यक पंक्ति विशिष्टता प्रदान नहीं करता है।

   आईडी एक भौतिक रिकॉर्ड सूचक है, इसका मतलब कुछ भी नहीं है, उपयोगकर्ता को इसे नहीं देखना चाहिए। लेकिन आपने (और अन्य) ने इसका अर्थ दिया है।

   जो आपको डेटा की तार्किक संरचना के बजाय फ़ाइल की भौतिक संरचना से चिपका देता है। जो बदले में आपके कोड को जटिल बनाता है।

   इसलिए, आपको सही किए बिना CREATE TABLE आदेश, आपका जैसा है, वैसा ही छोड़ कर, आइए हम यह दिखावा करें कि फ़ाइल में ID और AVERAGE मौजूद नहीं हैं।

एक तीसरा आइटम, दृष्टिकोण से संबंधित नहीं है, ऐसा लगता है कि दिए गए आंकड़े से, 10.58, आप किलोमीटर प्रति लीटर चाहते हैं, जबकि आपके द्वारा विस्तृत अंकगणित (लीटर प्रति 100 किमी) 9.44 का उत्पादन करेगा। यदि आप किसी प्रकार का औसत चाहते हैं, तो बेहतर होगा कि आप पहले तत्वों का पता लगा लें।

समाधान

    (Code obsolete due to revision)

संशोधित प्रश्न

मैं आपके द्वारा दिए गए आंकड़ों को प्राप्त करने का प्रयास कर रहा था, जबकि प्रश्न उलझन में रहा (इस आशय की टिप्पणियों पर ध्यान दें)। चूँकि आपके पास संशोधित है आपका प्रश्न, आवश्यकता अब स्पष्ट है। अब ऐसा प्रतीत होता है कि आप चाहते हैं (ए) लीटर प्रति 100 किमी [अभी भी एक "औसत" नहीं है], और (बी) प्रत्येक रिकॉर्ड के लिए एक समग्र आंकड़ा [एक प्रकार का कुल चल रहा है]। ऐसे में इस कोड का इस्तेमाल करें।

उपरोक्त नोट वैध और लागू रहते हैं।

    SELECT  CARID,
            DATETIME,
            KM,
            LI,
            LPCK = ( LI_TOT / ( ( KM_LAST-KM_FIRST / 100 ) )  -- not stored
        FROM (
            -- create a Derived Table with KM_FIRST
            SELECT  CARID,
                    DATETIME,
                    -- not stored
                    KM_FIRST = (
                SELECT  MIN( KM )        -- get the first KM for car
                    FROM CONSUM
                    WHERE CARID = C.CARID
                    ),
                    KM_LAST = (
                SELECT  MAX( KM )        -- get the last KM for car
                    FROM CONSUM
                    WHERE CARID = C.CARID
                    ),
                    KM,                  -- KM for this row
                    LI,                  -- LI for this row
                    LI_TOT = (
                SELECT  SUM( LI )        -- get the total LI for car
                    FROM CONSUM
                    WHERE CARID = C.CARID
                    AND KM != (          -- exclude first LI for car
                    SELECT  MIN( KM )    -- get the first KM for car
                        FROM CONSUM
                        WHERE CARID = C.CARID
                        )
                    )
                FROM CONSUM C
            ) AS CONSUM_EXT

        ORDER BY CARID,
            DATETIME

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

यह आपकी /first entry . को भी हटा देता है मुद्दा।

बेशक, CARID साथ ही उपयोगकर्ता के लिए अर्थहीन है।

कृपया बेझिझक टिप्पणी करें या प्रश्न पूछें, आदि।

हार्ड स्टोरेज

व्युत्पन्न किए जा सकने वाले मूल्य को संग्रहीत करने में कई समस्याएं हैं। यह डेटा स्टोरेज स्तर पर हार्ड-कोडिंग है। ज़रूर, आप दर्द को कम करने के लिए एक ट्रिगर का उपयोग कर सकते हैं, लेकिन यह अभी भी काम नहीं करेगा, क्योंकि (ए) सिद्धांत टूट गया है और (बी) यह मौजूदा इंजीनियरिंग सिद्धांतों का उल्लंघन करता है। उदा. क्या होता है जब एक पंक्ति के लिए एलआई गलत तरीके से दर्ज किया जाता है (उदाहरण के लिए 700.17), और बाद में सही किया जाता है (उदाहरण के लिए 70.17)? उस कार के लिए बाद की सभी पंक्तियाँ अब गलत हैं, और उन्हें फिर से परिकलित और अद्यतन किया जाना है। तो अब आपको एक अपडेट ट्रिगर के साथ-साथ एक इंसर्ट ट्रिगर भी चाहिए। कैंसर अपने आप जुड़ जाता है।

एक अद्यतन विसंगति की अवधारणा, प्राप्त किए जा सकने वाले मूल्यों को संग्रहीत करने का निषेध, अच्छे कारण के लिए 1970 से हमारे साथ है। अच्छे कारणों से हम उनसे बचते हैं।