डीबीए: सिंक्रनाइज़ेशन और आयात को सक्षम रूप से व्यवस्थित करें

बड़े डेटा सेट के जटिल प्रसंस्करण के लिए (अलग-अलग)। ईटीएल प्रक्रियाएं: आयात, रूपांतरण और बाहरी स्रोत के साथ सिंक्रनाइज़ेशन) की अक्सर आवश्यकता होती है अस्थायी रूप से "याद रखें" और तुरंत त्वरित प्रक्रिया करें कुछ विशाल.

इस तरह का एक सामान्य कार्य आमतौर पर कुछ इस तरह लगता है: "यहीं लेखा विभाग ग्राहक बैंक से उतार दिया गया अंतिम प्राप्त भुगतान, आपको उन्हें तुरंत वेबसाइट पर अपलोड करना होगा और उन्हें अपने खातों से लिंक करना होगा।"

लेकिन जब इस "कुछ" की मात्रा सैकड़ों मेगाबाइट में मापी जाने लगती है, और सेवा को डेटाबेस के साथ 24x7 काम करना जारी रखना चाहिए, तो कई दुष्प्रभाव उत्पन्न होते हैं जो आपके जीवन को बर्बाद कर देंगे।

PostgreSQL (और केवल इसमें ही नहीं) में उनसे निपटने के लिए, आप कुछ अनुकूलन का उपयोग कर सकते हैं जो आपको हर चीज को तेजी से और कम संसाधन खपत के साथ संसाधित करने की अनुमति देगा।

1. कहाँ भेजना है?

सबसे पहले, आइए तय करें कि हम उस डेटा को कहां अपलोड कर सकते हैं जिसे हम "प्रोसेस" करना चाहते हैं।

1.1. अस्थायी टेबल (अस्थायी टेबल)

सिद्धांत रूप में, PostgreSQL के लिए अस्थायी तालिकाएँ किसी अन्य के समान ही हैं। इसलिए अंधविश्वास पसंद है "वहां सब कुछ केवल स्मृति में संग्रहीत है, और यह समाप्त हो सकता है". लेकिन इसमें कई महत्वपूर्ण अंतर भी हैं।

डेटाबेस से प्रत्येक कनेक्शन के लिए आपका अपना "नेमस्पेस"।

यदि दो कनेक्शन एक ही समय में कनेक्ट करने का प्रयास करें CREATE TABLE x, तो कोई न कोई तो मिलेगा ही गैर-विशिष्टता त्रुटि डेटाबेस ऑब्जेक्ट.

लेकिन अगर दोनों अमल करने की कोशिश करते हैं CREATE TEMPORARY TABLE x, तो दोनों इसे सामान्य रूप से करेंगे, और सभी को मिलेगा आपकी प्रति टेबल. और उनके बीच कुछ भी सामान्य नहीं होगा.

डिस्कनेक्ट होने पर "आत्म-विनाश"।

जब कनेक्शन बंद हो जाता है, तो सभी अस्थायी तालिकाएँ स्वचालित रूप से हटा दी जाती हैं, इसलिए मैन्युअल रूप से DROP TABLE x इसके अलावा कोई मतलब नहीं है...

यदि आप काम कर रहे हैं लेनदेन मोड में pgbouncer, तो डेटाबेस यह मानता रहता है कि यह कनेक्शन अभी भी सक्रिय है, और इसमें यह अस्थायी तालिका अभी भी मौजूद है।

इसलिए, pgbouncer से भिन्न कनेक्शन से इसे दोबारा बनाने का प्रयास करने पर त्रुटि उत्पन्न होगी। लेकिन इसका उपयोग करके इससे बचा जा सकता है CREATE TEMPORARY TABLE IF NOT EXISTS x.

सच है, वैसे भी ऐसा न करना बेहतर है, क्योंकि तब आप "अचानक" वहां "पिछले मालिक" से बचा हुआ डेटा पा सकते हैं। इसके बजाय, मैनुअल को पढ़ना और यह देखना बेहतर है कि तालिका बनाते समय इसे जोड़ना संभव है ON COMMIT DROP - यानी, जब लेनदेन पूरा हो जाएगा, तो तालिका स्वचालित रूप से हटा दी जाएगी।

गैरप्रतिकृति

क्योंकि वे केवल एक विशिष्ट कनेक्शन से संबंधित हैं, अस्थायी तालिकाओं की नकल नहीं की जाती है। लेकिन इससे डेटा की दोहरी रिकॉर्डिंग की आवश्यकता समाप्त हो जाती है हीप + वाल में, इसलिए इसमें INSERT/UPDATE/DELETE बहुत तेज है।

लेकिन चूंकि एक अस्थायी तालिका अभी भी एक "लगभग सामान्य" तालिका है, इसलिए इसे प्रतिकृति पर भी नहीं बनाया जा सकता है। कम से कम अभी के लिए, हालांकि संबंधित पैच लंबे समय से प्रसारित हो रहा है।

1.2. अनलॉग्ड टेबल

लेकिन आपको क्या करना चाहिए, उदाहरण के लिए, यदि आपके पास किसी प्रकार की बोझिल ईटीएल प्रक्रिया है जिसे एक लेनदेन के भीतर लागू नहीं किया जा सकता है, लेकिन आपके पास अभी भी है लेनदेन मोड में pgbouncer? ..

या डेटा प्रवाह इतना बड़ा है कि एक कनेक्शन पर पर्याप्त बैंडविड्थ नहीं है एक डेटाबेस से (पढ़ें, प्रति सीपीयू एक प्रक्रिया)?..

या फिर कोई ऑपरेशन चल रहा है अतुल्यकालिक रूप से अलग-अलग कनेक्शन में?..

यहाँ केवल एक ही विकल्प है - अस्थायी रूप से एक गैर-अस्थायी तालिका बनाएं. पुन, हाँ. वह है:

• अधिकतम यादृच्छिक नामों के साथ "मेरी अपनी" तालिकाएँ बनाईं ताकि किसी के साथ छेड़छाड़ न हो
• उद्धरण: उन्हें बाहरी स्रोत से डेटा से भर दिया
• बदालना: परिवर्तित, कुंजी लिंकिंग फ़ील्ड भरे गए
• भार: तैयार डेटा को लक्ष्य तालिकाओं में डाला गया
• "मेरी" तालिकाएँ हटा दी गईं

और अब - मरहम में एक मक्खी. वास्तव में, PostgreSQL में सभी लेखन दो बार होते हैं - वाल में प्रथम, फिर तालिका/सूचकांक निकायों में। यह सब ACID का समर्थन करने और डेटा दृश्यता को सही करने के लिए किया जाता है COMMIT'अखरोट और ROLLBACK'शून्य लेनदेन.

लेकिन हमें इसकी आवश्यकता नहीं है! हमारे पास पूरी प्रक्रिया है या तो यह पूरी तरह सफल रहा या नहीं।. इससे कोई फर्क नहीं पड़ता कि कितने मध्यवर्ती लेनदेन होंगे - हमें "प्रक्रिया को बीच से जारी रखने" में कोई दिलचस्पी नहीं है, खासकर जब यह स्पष्ट नहीं है कि यह कहां थी।

ऐसा करने के लिए, PostgreSQL डेवलपर्स ने, संस्करण 9.1 में, ऐसी चीज़ पेश की अनलॉग्ड टेबल:

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

संक्षेप में, यह बहुत तेज़ होगा, लेकिन यदि डेटाबेस सर्वर "गिर जाता है", तो यह अप्रिय होगा। लेकिन ऐसा कितनी बार होता है, और क्या आपकी ईटीएल प्रक्रिया जानती है कि डेटाबेस को "पुनर्जीवित" करने के बाद इसे "बीच से" सही ढंग से कैसे ठीक किया जाए?

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

1.3. कमिट पर {पंक्तियाँ हटाएँ | बूँद}

यह निर्माण आपको तालिका बनाते समय लेनदेन पूरा होने पर स्वचालित व्यवहार निर्दिष्ट करने की अनुमति देता है।

पर ON COMMIT DROP मैंने पहले ही ऊपर लिखा है, यह उत्पन्न करता है DROP TABLE, लेकिन इसके साथ ON COMMIT DELETE ROWS स्थिति अधिक दिलचस्प है - यह यहाँ उत्पन्न होती है TRUNCATE TABLE.

चूंकि एक अस्थायी तालिका के मेटा-विवरण को संग्रहीत करने के लिए संपूर्ण बुनियादी ढांचा बिल्कुल एक नियमित तालिका के समान ही है, तो अस्थायी तालिकाओं को लगातार बनाने और हटाने से सिस्टम तालिकाओं में गंभीर "सूजन" हो जाती है pg_class, pg_attribute, pg_attrdef, pg_depend,…

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

सामान्य तौर पर, ऐसा मत करो! ऐसे में यह कहीं अधिक प्रभावी है CREATE TEMPORARY TABLE x ... ON COMMIT DELETE ROWS इसे लेन-देन चक्र से बाहर निकालें - फिर प्रत्येक नए लेन-देन की शुरुआत तक तालिकाएँ पहले से ही होंगी अस्तित्व में रहेगा (कॉल सहेजें CREATE), परंतु खाली हो जाएगा, कोलंबो TRUNCATE (हमने पिछला लेनदेन पूरा करते समय इसकी कॉल भी सहेजी थी)।

1.4. जैसे...सहित...

मैंने शुरुआत में उल्लेख किया था कि अस्थायी तालिकाओं के लिए विशिष्ट उपयोग के मामलों में से एक विभिन्न प्रकार के आयात हैं - और डेवलपर लक्ष्य तालिका के फ़ील्ड की सूची को अपने अस्थायी की घोषणा में कॉपी-पेस्ट करता है ...

लेकिन आलस्य प्रगति का इंजन है! इसीलिए "नमूने के आधार पर" एक नई तालिका बनाएं यह बहुत आसान हो सकता है:

CREATE TEMPORARY TABLE import_table(
  LIKE target_table
);

चूँकि आप इस तालिका में बहुत सारा डेटा उत्पन्न कर सकते हैं, इसलिए इसमें खोज करना कभी भी तेज़ नहीं होगा। लेकिन इसका एक पारंपरिक समाधान है - अनुक्रमणिका! और हां, एक अस्थायी तालिका में अनुक्रमणिकाएँ भी हो सकती हैं.

चूँकि, अक्सर, आवश्यक सूचकांक लक्ष्य तालिका के सूचकांक से मेल खाते हैं, आप बस लिख सकते हैं LIKE target_table INCLUDING INDEXES.

अगर आपको भी चाहिए DEFAULT-मान (उदाहरण के लिए, प्राथमिक कुंजी मान भरने के लिए), आप उपयोग कर सकते हैं LIKE target_table INCLUDING DEFAULTS. या केवल - LIKE target_table INCLUDING ALL - प्रतिलिपियाँ डिफ़ॉल्ट, अनुक्रमणिका, बाधाएँ,...

लेकिन यहां आपको ये समझने की जरूरत है कि अगर आपने बनाया है इंडेक्स के साथ तुरंत तालिका आयात करें, तो डेटा लोड होने में अधिक समय लगेगायदि आप पहले सब कुछ भरते हैं, और उसके बाद ही अनुक्रमणिका को रोल करते हैं - उदाहरण के तौर पर देखें कि यह ऐसा कैसे करता है पीजी_डंप.

कुल मिलाकर, RTFM!

2. कैसे लिखें?

मुझे बस इतना कहना है - इसका प्रयोग करें COPY- "पैक" के बजाय प्रवाह INSERT, कभी-कभी त्वरण. आप सीधे पूर्व-निर्मित फ़ाइल से भी कर सकते हैं।

3. कैसे प्रोसेस करें?

तो, चलिए अपना परिचय कुछ इस तरह दिखाते हैं:

• आपके पास अपने डेटाबेस में संग्रहीत क्लाइंट डेटा वाली एक तालिका है 1M रिकॉर्ड
• हर दिन एक ग्राहक आपको एक नया भेजता है पूर्ण "छवि"
• अनुभव से आप समय-समय पर यह जानते हैं 10K से अधिक रिकॉर्ड नहीं बदले गए

ऐसी स्थिति का एक उत्कृष्ट उदाहरण है KLADR आधार - कुल मिलाकर बहुत सारे पते हैं, लेकिन प्रत्येक साप्ताहिक अपलोड में राष्ट्रीय स्तर पर भी बहुत कम बदलाव होते हैं (बस्तियों का नाम बदलना, सड़कों का संयोजन, नए घरों की उपस्थिति)।

3.1. पूर्ण तुल्यकालन एल्गोरिदम

सरलता के लिए, मान लें कि आपको डेटा को पुनर्गठित करने की भी आवश्यकता नहीं है - बस तालिका को वांछित रूप में लाएं, यानी:

• हटाना वह सब कुछ जो अब अस्तित्व में नहीं है
• अद्यतन वह सब कुछ जो पहले से मौजूद है और जिसे अद्यतन करने की आवश्यकता है
• सम्मिलित वह सब कुछ जो अभी तक नहीं हुआ है

संचालन इस क्रम में क्यों किया जाना चाहिए? क्योंकि इस तरह से टेबल का आकार न्यूनतम रूप से बढ़ेगा (एमवीसीसी याद रखें!).

डीएसटी से हटाएँ

नहीं, निःसंदेह आप केवल दो ऑपरेशनों से काम चला सकते हैं:

• हटाना (DELETE) सामान्य तौर पर सब कुछ
• सम्मिलित सभी नई छवि से

लेकिन साथ ही, एमवीसीसी को धन्यवाद, तालिका का आकार ठीक दोगुना बढ़ जाएगा! 1K अपडेट के कारण तालिका में रिकॉर्ड की +10M छवियां प्राप्त करना बहुत ही अतिरेक है...

ट्रंकेट डीएसटी

एक अधिक अनुभवी डेवलपर जानता है कि पूरे टैबलेट को काफी सस्ते में साफ किया जा सकता है:

• स्वच्छ (TRUNCATE) संपूर्ण तालिका
• सम्मिलित सभी नई छवि से

तरीका कारगर है, कभी-कभी काफी लागू होता है, लेकिन एक समस्या है... हम लंबे समय के लिए 1M रिकॉर्ड जोड़ रहे होंगे, इसलिए हम इस पूरे समय के लिए तालिका को खाली नहीं छोड़ सकते (जैसा कि इसे एक ही लेनदेन में लपेटे बिना होगा)।

जिसका अर्थ है:

• हम शुरू कर रहे हैं लंबे समय तक चलने वाला लेन-देन
• TRUNCATE लगाता एक्सेस एक्सक्लूसिव-अवरुद्ध करना
• हम लंबे समय तक सम्मिलन करते हैं, और इस समय बाकी सभी लोग भी नहीं कर सकते SELECT

कुछ ठीक नहीं चल रहा है...

तालिका बदलें... नाम बदलें... / तालिका हटाएं...

एक विकल्प यह है कि सब कुछ एक अलग नई तालिका में भर दिया जाए, और फिर पुराने के स्थान पर इसका नाम बदल दिया जाए। कुछ छोटी-छोटी गंदी बातें:

• अभी भी एक्सेस एक्सक्लूसिव, हालाँकि काफी कम समय
• इस तालिका के लिए सभी क्वेरी योजनाएँ/आँकड़े रीसेट कर दिए गए हैं, ANALYZE चलाने की आवश्यकता है
• सभी विदेशी कुंजियाँ टूट गई हैं (एफके) मेज पर

साइमन रिग्स का एक WIP पैच था जिसने बनाने का सुझाव दिया था ALTER-आंकड़ों और एफके को छुए बिना, फ़ाइल स्तर पर टेबल बॉडी को बदलने के लिए एक ऑपरेशन, लेकिन कोरम एकत्र नहीं किया गया।

हटाएँ, अद्यतन करें, सम्मिलित करें

इसलिए, हम तीन परिचालनों के गैर-अवरुद्ध विकल्प पर निर्णय लेते हैं। लगभग तीन... इसे सबसे प्रभावी ढंग से कैसे करें?

-- все делаем в рамках транзакции, чтобы никто не видел "промежуточных" состояний
BEGIN;

-- создаем временную таблицу с импортируемыми данными
CREATE TEMPORARY TABLE tmp(
  LIKE dst INCLUDING INDEXES -- по образу и подобию, вместе с индексами
) ON COMMIT DROP; -- за рамками транзакции она нам не нужна

-- быстро-быстро вливаем новый образ через COPY
COPY tmp FROM STDIN;
-- ...
-- .

-- удаляем отсутствующие
DELETE FROM
  dst D
USING
  dst X
LEFT JOIN
  tmp Y
    USING(pk1, pk2) -- поля первичного ключа
WHERE
  (D.pk1, D.pk2) = (X.pk1, X.pk2) AND
  Y IS NOT DISTINCT FROM NULL; -- "антиджойн"

-- обновляем оставшиеся
UPDATE
  dst D
SET
  (f1, f2, f3) = (T.f1, T.f2, T.f3)
FROM
  tmp T
WHERE
  (D.pk1, D.pk2) = (T.pk1, T.pk2) AND
  (D.f1, D.f2, D.f3) IS DISTINCT FROM (T.f1, T.f2, T.f3); -- незачем обновлять совпадающие

-- вставляем отсутствующие
INSERT INTO
  dst
SELECT
  T.*
FROM
  tmp T
LEFT JOIN
  dst D
    USING(pk1, pk2)
WHERE
  D IS NOT DISTINCT FROM NULL;

COMMIT;

3.2. प्रसंस्करण के बाद आयात करें

उसी KLADR में, सभी परिवर्तित रिकॉर्ड को पोस्ट-प्रोसेसिंग के माध्यम से अतिरिक्त रूप से चलाया जाना चाहिए - सामान्यीकृत, कीवर्ड हाइलाइट किए गए, और आवश्यक संरचनाओं में कम किए गए। लेकिन आप कैसे जानते हैं - वास्तव में क्या बदलासिंक्रोनाइज़ेशन कोड को जटिल बनाए बिना, आदर्श रूप से इसे बिल्कुल भी छुए बिना?

यदि केवल आपकी प्रक्रिया में सिंक्रनाइज़ेशन के समय लिखने की पहुंच है, तो आप एक ट्रिगर का उपयोग कर सकते हैं जो हमारे लिए सभी परिवर्तन एकत्र करेगा:

-- целевые таблицы
CREATE TABLE kladr(...);
CREATE TABLE kladr_house(...);

-- таблицы с историей изменений
CREATE TABLE kladr$log(
  ro kladr, -- тут лежат целые образы записей старой/новой
  rn kladr
);

CREATE TABLE kladr_house$log(
  ro kladr_house,
  rn kladr_house
);

-- общая функция логирования изменений
CREATE OR REPLACE FUNCTION diff$log() RETURNS trigger AS $$
DECLARE
  dst varchar = TG_TABLE_NAME || '$log';
  stmt text = '';
BEGIN
  -- проверяем необходимость логгирования при обновлении записи
  IF TG_OP = 'UPDATE' THEN
    IF NEW IS NOT DISTINCT FROM OLD THEN
      RETURN NEW;
    END IF;
  END IF;
  -- создаем запись лога
  stmt = 'INSERT INTO ' || dst::text || '(ro,rn)VALUES(';
  CASE TG_OP
    WHEN 'INSERT' THEN
      EXECUTE stmt || 'NULL,$1)' USING NEW;
    WHEN 'UPDATE' THEN
      EXECUTE stmt || '$1,$2)' USING OLD, NEW;
    WHEN 'DELETE' THEN
      EXECUTE stmt || '$1,NULL)' USING OLD;
  END CASE;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

अब हम सिंक्रोनाइज़ेशन शुरू करने से पहले ट्रिगर्स लागू कर सकते हैं (या उन्हें सक्षम कर सकते हैं ALTER TABLE ... ENABLE TRIGGER ...):

CREATE TRIGGER log
  AFTER INSERT OR UPDATE OR DELETE
  ON kladr
    FOR EACH ROW
      EXECUTE PROCEDURE diff$log();

CREATE TRIGGER log
  AFTER INSERT OR UPDATE OR DELETE
  ON kladr_house
    FOR EACH ROW
      EXECUTE PROCEDURE diff$log();

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

3.3. लिंक किए गए सेट आयात करना

ऊपर हमने उन मामलों पर विचार किया जब स्रोत और गंतव्य की डेटा संरचनाएं समान हैं। लेकिन क्या होगा यदि किसी बाहरी सिस्टम से अपलोड का प्रारूप हमारे डेटाबेस में भंडारण संरचना से भिन्न हो?

आइए एक उदाहरण के रूप में ग्राहकों और उनके खातों के भंडारण को लें, क्लासिक "मैनी-टू-वन" विकल्प:

CREATE TABLE client(
  client_id
    serial
      PRIMARY KEY
, inn
    varchar
      UNIQUE
, name
    varchar
);

CREATE TABLE invoice(
  invoice_id
    serial
      PRIMARY KEY
, client_id
    integer
      REFERENCES client(client_id)
, number
    varchar
, dt
    date
, sum
    numeric(32,2)
);

लेकिन बाहरी स्रोत से डाउनलोड "ऑल इन वन" के रूप में हमारे पास आता है:

CREATE TEMPORARY TABLE invoice_import(
  client_inn
    varchar
, client_name
    varchar
, invoice_number
    varchar
, invoice_dt
    date
, invoice_sum
    numeric(32,2)
);

जाहिर है, इस संस्करण में ग्राहक डेटा को डुप्लिकेट किया जा सकता है, और मुख्य रिकॉर्ड "खाता" है:

0123456789;Вася;A-01;2020-03-16;1000.00
9876543210;Петя;A-02;2020-03-16;666.00
0123456789;Вася;B-03;2020-03-16;9999.00

मॉडल के लिए, हम बस अपना परीक्षण डेटा डालेंगे, लेकिन याद रखें - COPY अधिक कुशल!

INSERT INTO invoice_import
VALUES
  ('0123456789', 'Вася', 'A-01', '2020-03-16', 1000.00)
, ('9876543210', 'Петя', 'A-02', '2020-03-16', 666.00)
, ('0123456789', 'Вася', 'B-03', '2020-03-16', 9999.00);

सबसे पहले, आइए उन "कटौती" पर प्रकाश डालें जिनका उल्लेख हमारे "तथ्यों" से होता है। हमारे मामले में, चालान ग्राहकों को संदर्भित करते हैं:

CREATE TEMPORARY TABLE client_import AS
SELECT DISTINCT ON(client_inn)
-- можно просто SELECT DISTINCT, если данные заведомо непротиворечивы
  client_inn inn
, client_name "name"
FROM
  invoice_import;

खातों को ग्राहक आईडी के साथ सही ढंग से जोड़ने के लिए, हमें सबसे पहले इन पहचानकर्ताओं को ढूंढना या उत्पन्न करना होगा। आइए उनके अंतर्गत फ़ील्ड जोड़ें:

ALTER TABLE invoice_import ADD COLUMN client_id integer;
ALTER TABLE client_import ADD COLUMN client_id integer;

आइए एक छोटे से संशोधन के साथ ऊपर वर्णित तालिका सिंक्रनाइज़ेशन विधि का उपयोग करें - हम लक्ष्य तालिका में कुछ भी अपडेट या हटा नहीं देंगे, क्योंकि हम ग्राहकों को "केवल-संलग्न" आयात करते हैं:

-- проставляем в таблице импорта ID уже существующих записей
UPDATE
  client_import T
SET
  client_id = D.client_id
FROM
  client D
WHERE
  T.inn = D.inn; -- unique key

-- вставляем отсутствовавшие записи и проставляем их ID
WITH ins AS (
  INSERT INTO client(
    inn
  , name
  )
  SELECT
    inn
  , name
  FROM
    client_import
  WHERE
    client_id IS NULL -- если ID не проставился
  RETURNING *
)
UPDATE
  client_import T
SET
  client_id = D.client_id
FROM
  ins D
WHERE
  T.inn = D.inn; -- unique key

-- проставляем ID клиентов у записей счетов
UPDATE
  invoice_import T
SET
  client_id = D.client_id
FROM
  client_import D
WHERE
  T.client_inn = D.inn; -- прикладной ключ

दरअसल, सब कुछ अंदर है invoice_import अब हमारे पास संपर्क फ़ील्ड भर गया है client_id, जिसके साथ हम चालान डालेंगे।

स्रोत: www.habr.com