मैं अलग-अलग स्कीमा से एक अस्थायी तालिका में सामान्य डेटा कैसे सम्मिलित कर सकता हूं?

सबसे पहले, आप एक VIEW बना सकते हैं यह कार्यक्षमता प्रदान करने के लिए:

CREATE VIEW orders AS
SELECT '1'::int            AS source -- or any other tag to identify source
      ,"OrderNumber"::text AS order_nr
      ,"InvoiceNumber"     AS tansaction_id -- no cast .. is int already
      ,"OrderDate" AT TIME ZONE 'UTC' AS purchase_date -- !! see explanation
FROM   tbl_newegg

UNION  ALL  -- not UNION!
SELECT 2
       "amazonOrderId"
      ,"merchant-order-id"
      ,"purchase-date"
FROM   tbl_amazon;

आप इस दृश्य को किसी अन्य तालिका की तरह क्वेरी कर सकते हैं:

SELECT * FROM orders WHERE order_nr = 123 AND source = 2;

source आवश्यक है यदि order_nr अद्वितीय नहीं है। आप अलग-अलग स्रोतों पर अद्वितीय ऑर्डर-नंबरों की गारंटी कैसे देंगे?
एक timestamp without time zone वैश्विक संदर्भ में अस्पष्ट है। यह केवल अपने समय क्षेत्र के संबंध में अच्छा है। अगर आप timestamp मिलाते हैं और timestamptz , आपको timestamp लगाना होगा एक निश्चित समय क्षेत्र में AT TIME ZONE . के साथ इस काम को करने के लिए निर्माण करें। अधिक स्पष्टीकरण के लिए पढ़ें यह संबंधित उत्तर ।

मैं समय क्षेत्र के रूप में यूटीसी का उपयोग करता हूं, हो सकता है कि आप एक अलग प्रदान करना चाहें। एक साधारण कास्ट "OrderDate"::timestamptz आपका वर्तमान समय क्षेत्र मान लेगा। AT TIME ZONE एक timestamp . पर लागू किया गया timestamptz . में परिणाम . इसलिए मैंने कोई और कास्ट नहीं जोड़ा।
जबकि आप कर सकते हैं , मैं सलाह देता हूं कि PostgreSQL कभी . में ऊंट-केस आइडेंटिफ़ायर का उपयोग न करें . कई तरह के संभावित भ्रम से बचा जाता है। मेरे द्वारा दिए गए लोअर केस आइडेंटिफ़ायर (अब अनावश्यक डबल-कोट्स के बिना) पर ध्यान दें।
varchar(25) . का इस्तेमाल न करें order_nr . के लिए टाइप के रूप में . बस text का उपयोग करें मनमाने ढंग से लंबाई संशोधक के बिना अगर इसे एक स्ट्रिंग होना है। यदि सभी ऑर्डर नंबरों में विशेष रूप से अंक होते हैं, तो integer या bigint तेज़ होगा।

प्रदर्शन

इस व्रत को करने का एक तरीका यह होगा कि दृश्य को साकार किया जाए। यानी, परिणाम को (अस्थायी) तालिका में लिखें:

CREATE TEMP TABLE tmp_orders AS
SELECT * FROM orders;

ANALYZE tmp_orders; -- temp tables are not auto-analyzed!

ALTER TABLE tmp_orders
ADD constraint orders_pk PRIMARY KEY (order_nr, source);

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

यदि आपकी टेबल बड़ी हैं, तो सुनिश्चित करें कि आपके पास पर्याप्त अस्थायी बफ़र्स हैं इसे पहले RAM RAM में संभालने के लिए आप अस्थायी तालिका बनाते हैं। नहीं तो यह वास्तव में आपको धीमा कर देगा।

SET temp_buffers = 1000MB;

आपके सत्र में अस्थायी वस्तुओं के लिए पहला कॉल होना चाहिए। इसे केवल अपने सत्र के लिए विश्व स्तर पर उच्च सेट न करें। वैसे भी आपके सत्र के अंत में एक अस्थायी तालिका स्वचालित रूप से हटा दी जाती है।

यह अनुमान लगाने के लिए कि आपको कितनी RAM की आवश्यकता है, एक बार तालिका बनाएं और मापें:

SELECT pg_size_pretty(pg_total_relation_size('tmp_orders'));

इस संबंधित प्रश्न के अंतर्गत dba.SE के अंतर्गत ऑब्जेक्ट आकारों के बारे में अधिक जानकारी ।

सभी ओवरहेड केवल तभी भुगतान करते हैं जब आपको एक सत्र के भीतर कई प्रश्नों को संसाधित करना होता है। अन्य उपयोग के मामलों के लिए अन्य समाधान हैं। यदि आप क्वेरी के समय स्रोत तालिका जानते हैं, तो इसके बजाय अपनी क्वेरी को स्रोत तालिका पर निर्देशित करना बहुत तेज़ होगा। अगर आप ऐसा नहीं करते हैं, तो मैं आपके order_nr . की विशिष्टता पर सवाल उठाऊंगा एक बार और। यदि यह, वास्तव में, अद्वितीय होने की गारंटी है, तो आप कॉलम को छोड़ सकते हैं source मैंने परिचय दिया।

केवल एक या कुछ प्रश्नों के लिए, भौतिक दृश्य के बजाय दृश्य का उपयोग करना तेज़ हो सकता है।

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

साथ ही, अगर आप text . से चिपके रहते हैं या varchar आपके order_nr . के लिए , COLLATE "C" इसके लिए।