PostgreSQL: उत्पन्न कॉलम


16

क्या PostgreSQL जनरेट किए गए कॉलम का समर्थन करता है ? वर्चुअल कॉलम के रूप में भी जानते हैं । मैं कॉलम की बात नहीं कर रहा हूं ।IDENTITY

मुझे इस उल्लेखनीय विशेषता के बारे में कोई जानकारी नहीं मिली है, लेकिन मुझे पता है कि यह SQL सर्वर पर उपलब्ध है, और मारियाडीबी और मायक्यूएल के नवीनतम संस्करणों में।

एसक्यूएल: 2003 मानक में इस सुविधा का उल्लेख है , और 2006 के आसपास पोस्टग्रेक्यूएल मंचों पर कुछ चर्चा हुई थी, लेकिन मुझे इस मामले पर कुछ भी पर्याप्त नहीं मिला।

एसओ पर कुछ चर्चा है, लेकिन यह अभी काफी पुराना है, इसलिए यह अच्छी तरह से पुराना हो सकता है।


2
एसओ पर 2012 से संबंधित यह जवाब मदद का हो सकता है: stackoverflow.com/questions/11165450/… अभी भी वैध है।
इरविन ब्रांडस्टेटर

@ErwinBrandstetter क्षमा करें मुझे यह टिप्पणी याद आई। यह एक उपयोगी ट्रिक है। धन्यवाद।
शाम 12:53

जवाबों:


17

सुनिश्चित नहीं हैं कि यह वही है जो आप चाहते हैं, लेकिन विशेषता संकेतन row.full_nameऔर फ़ंक्शन संकेतन full_name(row)postgresql में बराबर हैं।

इसका मतलब है कि आप एक टेबल लेते हैं

CREATE TABLE people (
  first_name text,
  last_name text
);

और एक समारोह:

CREATE FUNCTION full_name(people) RETURNS text AS $$
  SELECT $1.first_name || ' ' || $1.last_name;
$$ LANGUAGE SQL;

और इसे इस तरह से कॉल करें:

select full_name from people

क्या आपको यही चाहिए?

चीजों को गति देने के लिए आप एक अभिव्यक्ति सूचकांक बना सकते हैं:

CREATE INDEX people_full_name_idx ON people
USING GIN (to_tsvector('english', full_name(people)));

या सब कुछ भौतिक दृष्टि से संग्रहीत करें।

यहाँ से लिया गया उदाहरण: http://bernardoamc.github.io/sql/2015/05/11/postgres-virtual-columns/


2
यह सही जवाब है। उदाहरण के लिए, पोस्टग्रैस्ट इस व्यवहार को "कंप्यूटेड कॉलम" के रूप में संदर्भित करता है।
फिएटजैफ

टाइपो, मुझे लगता है - चयन का होना चाहिए select people.full_name from peopleया select full_name(people) from people?
बरगद

नहीं, यह उस तरह काम करता है। "सिलेक्ट लोग.फुल_नाम लोगों से" में उपसर्ग को नियमित एसक्यूएल की तरह छोड़ा जा सकता है।
फेबियन जिएंडल

मुझे यह उत्तर याद आ रहा था, जैसा कि मैंने दिया था, तब तक वह आ रहा था। सलाह के लिये धन्यवाद।
मन्नजो

1
क्या आप स्वीकार किए गए उत्तर को बदल सकते हैं?
फेबियन ज़ींड्ल

6

नहीं, यह वर्तमान में है (पोस्टग्रेज 9.6 के अनुसार) समर्थित नहीं है।

एकमात्र समाधान एक ट्रिगर या एक दृश्य का उपयोग करना है यदि यह एक सरल गणना है जिसे आपको अनुक्रमित करने की आवश्यकता नहीं है।


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

1
MVView की कोई आवश्यकता नहीं है। ट्रिगर वाला कॉलम आपको कॉलम की सामग्री को अनुक्रमणित करने देगा
a_horse_with_no_name

मेरे पास अतिरिक्त वास्तविक स्तंभों को संग्रहीत करने के लिए एक दार्शनिक मुद्दा है जो मूल रूप से अन्य डेटा का दोहराव है। यह तालिका को डी-सामान्य करता है।
मन्नोजो

5
ठीक है, एक संकलित स्तंभ ठीक यही है: डेटा को सामान्यीकृत करना। गणना किए गए स्तंभ का मान कैसे उत्पन्न होता है, इससे कोई फर्क नहीं पड़ता। मुझे "वास्तविक" कंप्यूटेड कॉलम और ट्रिगर के माध्यम से उत्पन्न होने वाले एक के बीच वैचारिक अंतर दिखाई नहीं देता है
a_horse_with_no_name

एक और वर्कअराउंड (कुछ मामलों के लिए) एक अभिव्यक्ति को अनुक्रमित करना है।
ypercube y

5

हाँ: GENERATED ALWAYS AS … STORED

पोस्टग्रेज 12 उत्पन्न कॉलम के लिए कार्यक्षमता जोड़ता है, जैसा कि SQL: 2003 मानक में वर्णित है ।

मान INSERTया के समय उत्पन्न होता है UPDATE, फिर किसी अन्य मान की तरह पंक्ति के साथ संग्रहीत किया जाता है।

एक जनरेट उसी तालिका के आधार स्तंभ पर या एक अपरिवर्तनीय फ़ंक्शन पर आधारित होना चाहिए ।

सिंटैक्स सरल है, इस पर एक खंड CREATE TABLE:

GENERATED ALWAYS AS ( generation_expr ) STORED 

उदाहरण:

CREATE TABLE people (
    ...,
    height_cm NUMERIC,
    height_in NUMERIC GENERATED ALWAYS AS ( height_cm / 2.54 ) STORED
);

विशेषताएं:

  • अनुक्रमित किया जा सकता है।
  • SQL मानक का हिस्सा।

चेतावनियां:

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

देख:


उस जानकारी के लिए धन्यवाद। मैं देखता हूं कि संस्करण 12 अभी पूरी तरह से जारी नहीं हुआ है, लेकिन मैं इसके लिए उत्सुक हूं। मैं ध्यान देता हूं कि PostgreSQL अधिक मानक सिंटैक्स का उपयोग करता है, लेकिन अन्यथा MSSQL के समान है। मुझे यहाँ SQL2003 विनिर्देशन मिले: sigmodrecord.org/publications/sigmodRecord/0403/… । मैंने हमेशा कहा है कि एसक्यूएल बहुत धीमी गति से चलने वाला मानक है, और डीबीएमएस कार्यान्वयन भी धीमा है।
मिंगजो जू

0

आपके उपयोग-मामले के आधार पर, आप इस तरह के व्यवहार को एक नया कॉलम घोषित कर सकते हैं और इसे सम्मिलित / अद्यतन पर ट्रिगर के साथ आबाद कर सकते हैं।

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

मैंने इस दृष्टिकोण को एक ऐसे मुद्दे से निपटने के लिए माना, जहां मेरे पास कभी-कभी 18-अंकों की कुंजी के केवल 15 अंक थे (अंतिम 3 अंक सिर्फ एक चेकसम हैं) लेकिन एक विदेशी-कुंजी संबंध लागू करने में सक्षम होना चाहता था।

ट्रिगर पर पीजी डॉक्स: https://www.postgresql.org/docs/9.6/sql-creativerig.html

W3 उदाहरण: https://www.w3resource.com/PostgreSQL/postgresql-triggers.php

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.