DBA៖ មានសមត្ថកិច្ចរៀបចំការធ្វើសមកាលកម្ម និងការនាំចូល

សម្រាប់ដំណើរការស្មុគស្មាញនៃសំណុំទិន្នន័យធំ (ផ្សេងគ្នា ដំណើរការ ETL៖ ការនាំចូល ការបំប្លែង និងការធ្វើសមកាលកម្មជាមួយប្រភពខាងក្រៅ) ជាញឹកញាប់មានតម្រូវការ "ចងចាំ" ជាបណ្តោះអាសន្ន ហើយដំណើរការភ្លាមៗ អ្វីមួយដែលមានពន្លឺ។

កិច្ចការធម្មតានៃប្រភេទនេះ ជាធម្មតាស្តាប់ទៅដូចជា៖ "នៅ​ទី​នេះ នាយកដ្ឋានគណនេយ្យត្រូវបានដកចេញពីធនាគារអតិថិជន ការបង់ប្រាក់ដែលទទួលបានចុងក្រោយ អ្នកត្រូវបញ្ចូលវាយ៉ាងលឿនទៅកាន់គេហទំព័រ ហើយភ្ជាប់វាទៅគណនីរបស់អ្នក។"

ប៉ុន្តែនៅពេលដែលបរិមាណនៃ "អ្វីមួយ" នេះចាប់ផ្តើមវាស់វែងជារាប់រយមេកាបៃ ហើយសេវាកម្មត្រូវតែបន្តធ្វើការជាមួយមូលដ្ឋានទិន្នន័យ 24x7 ផលប៉ះពាល់ជាច្រើនកើតឡើងដែលនឹងបំផ្លាញជីវិតរបស់អ្នក។

ដើម្បីដោះស្រាយជាមួយពួកគេនៅក្នុង PostgreSQL (ហើយមិនត្រឹមតែនៅក្នុងវាប៉ុណ្ណោះទេ) អ្នកអាចប្រើការបង្កើនប្រសិទ្ធភាពមួយចំនួនដែលនឹងអនុញ្ញាតឱ្យអ្នកដំណើរការអ្វីៗបានលឿនជាងមុន និងមានការប្រើប្រាស់ធនធានតិច។

1. កន្លែងដែលត្រូវដឹកជញ្ជូន?

ជាដំបូង ចូរយើងសម្រេចចិត្តថាតើយើងអាចផ្ទុកទិន្នន័យដែលយើងចង់ "ដំណើរការ" នៅកន្លែងណា។

១.១. តារាងបណ្តោះអាសន្ន (តារាងបណ្តោះអាសន្ន)

ជាគោលការណ៍សម្រាប់តារាងបណ្តោះអាសន្ន PostgreSQL គឺដូចគ្នានឹងតារាងផ្សេងទៀត។ ដូច្នេះជំនឿឆ្វេងចូលចិត្ត "អ្វីៗទាំងអស់ត្រូវបានរក្សាទុកក្នុងការចងចាំប៉ុណ្ណោះ ហើយវាអាចបញ្ចប់បាន". ប៉ុន្តែក៏មានភាពខុសគ្នាសំខាន់ៗមួយចំនួនផងដែរ។

"namespace" ផ្ទាល់ខ្លួនរបស់អ្នកសម្រាប់ការតភ្ជាប់នីមួយៗទៅកាន់មូលដ្ឋានទិន្នន័យ

ប្រសិនបើការតភ្ជាប់ពីរព្យាយាមភ្ជាប់ក្នុងពេលតែមួយ CREATE TABLE xបន្ទាប់មកនរណាម្នាក់នឹងទទួលបាន កំហុសមិនឯកោ វត្ថុមូលដ្ឋានទិន្នន័យ។

ប៉ុន្តែប្រសិនបើទាំងពីរព្យាយាមប្រតិបត្តិ CREATE TEMPORARY TABLE xបន្ទាប់មកទាំងពីរនឹងធ្វើវាជាធម្មតា ហើយគ្រប់គ្នានឹងទទួលបាន ច្បាប់ចម្លងរបស់អ្នក។ តុ។ ហើយ​នឹង​មិន​មាន​អ្វី​ដូចគ្នា​រវាង​ពួកគេ​ទេ។

"បំផ្លាញខ្លួនឯង" នៅពេលផ្តាច់

នៅពេលដែលការតភ្ជាប់ត្រូវបានបិទ តារាងបណ្តោះអាសន្នទាំងអស់ត្រូវបានលុបដោយស្វ័យប្រវត្តិ ដូច្នេះដោយដៃ DROP TABLE x គ្មានចំណុចអ្វីក្រៅពី...

ប្រសិនបើអ្នកកំពុងធ្វើការតាមរយៈ pgbouncer នៅក្នុងរបៀបប្រតិបត្តិការបន្ទាប់មកមូលដ្ឋានទិន្នន័យបន្តជឿថាការតភ្ជាប់នេះនៅតែសកម្ម ហើយនៅក្នុងនោះតារាងបណ្តោះអាសន្ននេះនៅតែមាន។

ដូច្នេះ ការព្យាយាមបង្កើតវាម្តងទៀត ពីការតភ្ជាប់ផ្សេងទៅ pgbouncer នឹងបណ្តាលឱ្យមានកំហុស។ ប៉ុន្តែនេះអាចត្រូវបានជៀសវាងដោយប្រើ CREATE TEMPORARY TABLE IF NOT EXISTS x.

ជាការប្រសើរណាស់ វាជាការប្រសើរជាងកុំធ្វើដូចនេះ ពីព្រោះបន្ទាប់មកអ្នកអាច "ភ្លាមៗ" រកឃើញទិន្នន័យដែលនៅសល់ពី "ម្ចាស់មុន" នៅទីនោះ។ ជំនួសមកវិញ វាជាការប្រសើរជាងក្នុងការអានសៀវភៅណែនាំ ហើយឃើញថានៅពេលបង្កើតតារាងវាអាចបន្ថែមបាន។ ON COMMIT DROP - នោះគឺនៅពេលដែលប្រតិបត្តិការបានបញ្ចប់ តារាងនឹងត្រូវបានលុបដោយស្វ័យប្រវត្តិ។

មិនចម្លង

ដោយសារពួកវាជាកម្មសិទ្ធិរបស់ការតភ្ជាប់ជាក់លាក់ តារាងបណ្តោះអាសន្នមិនត្រូវបានចម្លងទេ។ ប៉ុន្តែ នេះលុបបំបាត់តម្រូវការសម្រាប់ការកត់ត្រាទិន្នន័យពីរដង នៅក្នុង heap + WAL ដូច្នេះ INSERT/UPDATE/DELETE ទៅក្នុងវាលឿនជាងយ៉ាងខ្លាំង។

ប៉ុន្តែដោយសារតារាងបណ្តោះអាសន្ននៅតែជាតារាង "ស្ទើរតែធម្មតា" វាមិនអាចបង្កើតនៅលើការចម្លងបានទេ។ យ៉ាងហោចណាស់សម្រាប់ពេលនេះ បើទោះបីជាបំណះដែលត្រូវគ្នាត្រូវបានផ្សព្វផ្សាយអស់រយៈពេលជាយូរក៏ដោយ។

១.២. តារាងដែលមិនបានចុះឈ្មោះ

ប៉ុន្តែអ្វីដែលអ្នកគួរធ្វើ ជាឧទាហរណ៍ ប្រសិនបើអ្នកមានដំណើរការ ETL ដ៏ស្មុគស្មាញមួយចំនួន ដែលមិនអាចត្រូវបានអនុវត្តនៅក្នុងប្រតិបត្តិការមួយ ប៉ុន្តែអ្នកនៅតែមាន pgbouncer នៅក្នុងរបៀបប្រតិបត្តិការ? ..

ឬលំហូរទិន្នន័យមានទំហំធំ មិនមានកម្រិតបញ្ជូនគ្រប់គ្រាន់នៅលើការតភ្ជាប់តែមួយទេ។ ពីមូលដ្ឋានទិន្នន័យ (អានដំណើរការមួយក្នុងមួយស៊ីភីយូ)?..

ឬប្រតិបត្តិការខ្លះកំពុងដំណើរការ អសមកាល នៅក្នុងការតភ្ជាប់ផ្សេងគ្នា? ..

មានជម្រើសតែមួយគត់នៅទីនេះ - បង្កើតតារាងដែលមិនមែនជាបណ្តោះអាសន្ន. Pun បាទ។ នោះគឺ៖

• បានបង្កើតតារាង "របស់ខ្ញុំ" ដែលមានឈ្មោះចៃដន្យជាអតិបរមា ដើម្បីកុំឱ្យប្រសព្វជាមួយនរណាម្នាក់
• ការដកស្រង់៖ បំពេញពួកវាដោយទិន្នន័យពីប្រភពខាងក្រៅ
• ផ្លាស់ប្តូរ៖ បានបំប្លែង បំពេញក្នុងវាលភ្ជាប់គន្លឹះ
• ផ្ទុក៖ ចាក់ទិន្នន័យរួចរាល់ទៅក្នុងតារាងគោលដៅ
• បានលុបតារាង "របស់ខ្ញុំ"

ហើយឥឡូវនេះ - រុយនៅក្នុងមួន។ តាមពិតទៅ ការសរសេរទាំងអស់នៅក្នុង PostgreSQL កើតឡើងពីរដង - ទីមួយនៅក្នុង WALបន្ទាប់មកចូលទៅក្នុងតារាង/សន្ទស្សន៍។ ទាំងអស់នេះត្រូវបានធ្វើដើម្បីគាំទ្រ ACID និងការមើលឃើញទិន្នន័យត្រឹមត្រូវរវាង COMMIT' nutty និង ROLLBACK'ប្រតិបត្តិការគ្មាន។

ប៉ុន្តែយើងមិនត្រូវការនេះទេ! យើងមានដំណើរការទាំងមូល ទោះ​បី​ជា​វា​ទទួល​បាន​ជោគជ័យ​ទាំង​ស្រុង ឬ​មិន​បាន​សម្រេច។. វាមិនមានបញ្ហាថាតើប្រតិបត្តិការកម្រិតមធ្យមនឹងមានប៉ុន្មាននោះទេ - យើងមិនចាប់អារម្មណ៍នឹង "បន្តដំណើរការពីពាក់កណ្តាល" ជាពិសេសនៅពេលដែលវាមិនច្បាស់ថាវានៅឯណា។

ដើម្បីធ្វើដូចនេះអ្នកអភិវឌ្ឍន៍ PostgreSQL ត្រឡប់មកវិញនៅក្នុងកំណែ 9.1 បានណែនាំរឿងដូចជា តារាងដែលមិនបានចុះឈ្មោះ:

ជាមួយនឹងការចង្អុលបង្ហាញនេះ តារាងត្រូវបានបង្កើតជា unlogged ។ ទិន្នន័យ​ដែល​សរសេរ​ទៅ​តារាង​ដែល​មិន​បាន​ចូល​មិន​បាន​ចូល​ទៅ​ក្នុង​ការ​សរសេរ​ទុក​មុន​ទេ (សូម​មើល​ជំពូក​ទី 29) ដែល​ធ្វើ​ឱ្យ​តារាង​ដូច​ជា ធ្វើការលឿនជាងធម្មតា។. ទោះជាយ៉ាងណា, ពួកគេមិនមានភាពស៊ាំទៅនឹងការបរាជ័យ; ក្នុងករណីម៉ាស៊ីនមេបរាជ័យ ឬការបិទជាបន្ទាន់ តារាងដែលមិនបានចូល កាត់បន្ថយដោយស្វ័យប្រវត្តិ. លើសពីនេះ ខ្លឹមសារនៃតារាងដែលមិនបានចូល មិនបានចម្លង ដើម្បីបម្រើសេវាបម្រើ។ លិបិក្រមណាមួយដែលបានបង្កើតនៅលើតារាងដែលមិនបានចូលត្រូវបានលុបចោលដោយស្វ័យប្រវត្តិ។

និយាយឱ្យខ្លី វានឹងលឿនជាងមុនប៉ុន្តែប្រសិនបើម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យ "ធ្លាក់" វានឹងមិនល្អទេ។ ប៉ុន្តែតើវាកើតឡើងញឹកញាប់ប៉ុណ្ណា ហើយតើដំណើរការ ETL របស់អ្នកដឹងពីរបៀបកែវាឱ្យបានត្រឹមត្រូវ "ពីកណ្តាល" បន្ទាប់ពី "ធ្វើឱ្យឡើងវិញ" មូលដ្ឋានទិន្នន័យដែរឬទេ?..

ប្រសិនបើមិនមានទេ ហើយករណីខាងលើគឺស្រដៀងនឹងរបស់អ្នក សូមប្រើ UNLOGGEDប៉ុន្តែមិនដែល កុំបើកគុណលក្ខណៈនេះនៅលើតារាងពិត, ទិន្នន័យដែលជាទីស្រឡាញ់សម្រាប់អ្នក។

១.៣. ON COMMIT { Delete ROWS | ទម្លាក់}

ការស្ថាបនានេះអនុញ្ញាតឱ្យអ្នកបញ្ជាក់ឥរិយាបថដោយស្វ័យប្រវត្តិនៅពេលប្រតិបត្តិការត្រូវបានបញ្ចប់នៅពេលបង្កើតតារាង។

នៅលើ 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 (យើងក៏បានរក្សាទុកការហៅរបស់វាផងដែរ) នៅពេលបញ្ចប់ប្រតិបត្តិការមុន។

១.៤. ដូចជា... រួមទាំង...

ខ្ញុំបានរៀបរាប់នៅដើមដំបូងថា ករណីប្រើប្រាស់ធម្មតាមួយសម្រាប់តារាងបណ្តោះអាសន្នគឺប្រភេទផ្សេងៗនៃការនាំចូល ហើយអ្នកអភិវឌ្ឍនឿយហត់ក្នុងការចម្លង-បិទភ្ជាប់បញ្ជីវាលនៃតារាងគោលដៅទៅក្នុងសេចក្តីប្រកាសបណ្តោះអាសន្នរបស់គាត់...

ប៉ុន្តែភាពខ្ជិលគឺជាក្បាលម៉ាស៊ីននៃវឌ្ឍនភាព! នោះ​ហើយ​ជា​មូល​ហេតុ​ដែល បង្កើតតារាងថ្មី "ផ្អែកលើគំរូ" វាអាចសាមញ្ញជាងនេះ៖

CREATE TEMPORARY TABLE import_table(
  LIKE target_table
);

ចាប់តាំងពីពេលនោះមក អ្នកអាចបង្កើតទិន្នន័យជាច្រើននៅក្នុងតារាងនេះ ការស្វែងរកតាមរយៈវានឹងមិនលឿនទេ។ ប៉ុន្តែមានដំណោះស្រាយបែបប្រពៃណីចំពោះបញ្ហានេះ - លិបិក្រម! ហើយបាទ តារាងបណ្តោះអាសន្នក៏អាចមានលិបិក្រមផងដែរ។.

ចាប់តាំងពី ជាញឹកញាប់ លិបិក្រមដែលត្រូវការស្របគ្នាជាមួយនឹងសន្ទស្សន៍នៃតារាងគោលដៅ អ្នកអាចសរសេរយ៉ាងសាមញ្ញ LIKE target_table INCLUDING INDEXES.

ប្រសិនបើអ្នកត្រូវការផងដែរ។ DEFAULT-values ​​(ឧទាហរណ៍ ដើម្បី​បំពេញ​តម្លៃ​គន្លឹះ​ចម្បង) អ្នក​អាច​ប្រើ LIKE target_table INCLUDING DEFAULTS. ឬសាមញ្ញ - LIKE target_table INCLUDING ALL - ចម្លងលំនាំដើម លិបិក្រម ឧបសគ្គ...

ប៉ុន្តែនៅទីនេះអ្នកត្រូវយល់ថាប្រសិនបើអ្នកបានបង្កើត តារាងនាំចូលភ្លាមៗជាមួយនឹងលិបិក្រម បន្ទាប់មកទិន្នន័យនឹងចំណាយពេលយូរដើម្បីផ្ទុកជាងប្រសិនបើអ្នកបំពេញអ្វីៗគ្រប់យ៉ាងជាមុនសិន ហើយគ្រាន់តែរមៀលឡើងសន្ទស្សន៍ - មើលពីរបៀបដែលវាធ្វើនេះជាឧទាហរណ៍ pg_dump.

ជាទូទៅ RTFM!

2. របៀបសរសេរ?

ខ្ញុំគ្រាន់តែនិយាយថា - ប្រើវា។ COPY- លំហូរជំនួសឱ្យ "កញ្ចប់" INSERT, ការបង្កើនល្បឿននៅពេលខ្លះ. អ្នកអាចសូម្បីតែដោយផ្ទាល់ពីឯកសារដែលបានបង្កើតជាមុន។

3. តើត្រូវដំណើរការដោយរបៀបណា?

ដូច្នេះ​សូម​ឱ្យ​ការ​ណែនាំ​របស់​យើង​មើល​ទៅ​ដូច​នេះ​:

• អ្នក​មាន​តារាង​ដែល​មាន​ទិន្នន័យ​អតិថិជន​ដែល​បាន​រក្សា​ទុក​ក្នុង​មូលដ្ឋាន​ទិន្នន័យ​របស់​អ្នក។ កំណត់ត្រា 1M
• រៀងរាល់ថ្ងៃ អតិថិជនផ្ញើអ្នកថ្មី។ "រូបភាព" ពេញលេញ
• តាមបទពិសោធន៍ អ្នកដឹងថាពីពេលមួយទៅពេលមួយ។ កំណត់ត្រាមិនលើសពី 10K ត្រូវបានផ្លាស់ប្តូរ

ឧទាហរណ៍បុរាណនៃស្ថានភាពបែបនេះគឺ មូលដ្ឋាន KLADR - មានអាស័យដ្ឋានសរុបជាច្រើន ប៉ុន្តែនៅក្នុងការបង្ហោះប្រចាំសប្តាហ៍នីមួយៗ មានការផ្លាស់ប្តូរតិចតួចណាស់ (ការប្តូរឈ្មោះការតាំងទីលំនៅ រួមបញ្ចូលគ្នានូវផ្លូវ រូបរាងផ្ទះថ្មី) សូម្បីតែនៅលើខ្នាតជាតិក៏ដោយ។

៣.១. ក្បួនដោះស្រាយការធ្វើសមកាលកម្មពេញលេញ

សម្រាប់ភាពសាមញ្ញ ចូរនិយាយថាអ្នកមិនចាំបាច់រៀបចំទិន្នន័យឡើងវិញទេ - គ្រាន់តែនាំយកតារាងទៅជាទម្រង់ដែលចង់បាន នោះគឺ៖

• ដកចេញ អ្វីគ្រប់យ៉ាងដែលលែងមាន
• ធ្វើឱ្យទាន់សម័យ អ្វីគ្រប់យ៉ាងដែលមានរួចហើយ និងចាំបាច់ត្រូវធ្វើបច្ចុប្បន្នភាព
• បញ្ចូល អ្វីគ្រប់យ៉ាងដែលមិនទាន់កើតឡើង

ហេតុអ្វីបានជាប្រតិបត្តិការគួរតែត្រូវបានធ្វើនៅក្នុងលំដាប់នេះ? ព្រោះនេះជារបៀបដែលទំហំតារាងនឹងកើនឡើងតិចតួចបំផុត (នៅចាំ MVCC ទេ!).

លុបចេញពី dst

ទេ ពិតណាស់អ្នកអាចទទួលបានដោយគ្រាន់តែប្រតិបត្តិការពីរ៖

• ដកចេញ (DELETE) អ្វីគ្រប់យ៉ាង
• បញ្ចូល ទាំងអស់ពីរូបភាពថ្មី។

ប៉ុន្តែទន្ទឹមនឹងនោះ សូមអរគុណដល់ MVCC ទំហំនៃតារាងនឹងកើនឡើងទ្វេដង! ការទទួលបានរូបភាព +1M នៃកំណត់ត្រានៅក្នុងតារាងដោយសារតែការអាប់ដេត 10K គឺហួសហេតុពេក...

កាត់ចេញ dst

អ្នកអភិវឌ្ឍន៍ដែលមានបទពិសោធន៍ច្រើនដឹងថាថេប្លេតទាំងមូលអាចសម្អាតបានដោយថោក៖

• ច្បាស់ (TRUNCATE) តារាងទាំងមូល
• បញ្ចូល ទាំងអស់ពីរូបភាពថ្មី។

វិធីសាស្ត្រមានប្រសិទ្ធភាព ពេលខ្លះអាចអនុវត្តបាន។ប៉ុន្តែមានបញ្ហា... យើងនឹងបន្ថែមកំណត់ត្រា 1M ក្នុងរយៈពេលយូរ ដូច្នេះយើងមិនអាចមានលទ្ធភាពទុកតុឱ្យនៅទទេបានគ្រប់ពេលនោះទេ (ដូចនឹងកើតឡើងដោយមិនរុំវាក្នុងប្រតិបត្តិការតែមួយ)។

ដែលមានន័យថា៖

• យើងកំពុងចាប់ផ្តើម ប្រតិបត្តិការរយៈពេលវែង
• TRUNCATE កំណត់ ចូលប្រើផ្តាច់មុខ- ការទប់ស្កាត់
• យើងធ្វើសិលាចារឹកជាយូរណាស់មកហើយ ហើយអ្នកផ្សេងទៀតនៅពេលនេះ មិនអាចសូម្បីតែ SELECT

មាន​អ្វី​មិន​ល្អ...

តារាងផ្លាស់ប្តូរ… ប្តូរឈ្មោះ… / ទម្លាក់តារាង…

ជម្រើសមួយគឺត្រូវបំពេញអ្វីគ្រប់យ៉ាងទៅក្នុងតារាងថ្មីដាច់ដោយឡែកមួយ ហើយបន្ទាប់មកគ្រាន់តែប្តូរឈ្មោះវាជំនួសកន្លែងចាស់។ រឿងតូចតាចមួយចំនួន៖

• នៅតែដដែល ចូលប្រើផ្តាច់មុខទោះបីជាពេលវេលាតិចជាងគួរឱ្យកត់សម្គាល់ក៏ដោយ។
• ផែនការសំណួរ/ស្ថិតិទាំងអស់សម្រាប់តារាងនេះត្រូវបានកំណត់ឡើងវិញ ត្រូវការដំណើរការ ANALYZE
• សោបរទេសទាំងអស់ត្រូវបានខូច (FK) ទៅតុ

មានបំណះ WIP ពី Simon Riggs ដែលស្នើឱ្យធ្វើ ALTER- ប្រតិបត្តិការដើម្បីជំនួសតួតារាងនៅកម្រិតឯកសារដោយមិនប៉ះស្ថិតិ និង FK ប៉ុន្តែមិនបានប្រមូលកូរ៉ុមទេ។

លុប ធ្វើបច្ចុប្បន្នភាព បញ្ចូល

ដូច្នេះ យើងដោះស្រាយលើជម្រើសមិនទប់ស្កាត់នៃប្រតិបត្តិការបី។ ស្ទើរតែបី... តើធ្វើដូចម្តេចទើបមានប្រសិទ្ធភាពបំផុត?

-- все делаем в рамках транзакции, чтобы никто не видел "промежуточных" состояний
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;

៣.២. នាំចូលក្រោយដំណើរការ

នៅក្នុង 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();

ហើយបន្ទាប់មកយើងទាញយកការផ្លាស់ប្តូរទាំងអស់ដែលយើងត្រូវការពីតារាងកំណត់ហេតុដោយស្ងប់ស្ងាត់ ហើយដំណើរការវាតាមរយៈឧបករណ៍ដោះស្រាយបន្ថែម។

៣.៣. កំពុង​នាំចូល​សំណុំ​ដែល​បាន​ភ្ជាប់

ខាងលើយើងបានពិចារណាករណីនៅពេលដែលរចនាសម្ព័ន្ធទិន្នន័យនៃប្រភព និងទិសដៅគឺដូចគ្នា។ ប៉ុន្តែចុះយ៉ាងណាបើការអាប់ឡូតពីប្រព័ន្ធខាងក្រៅមានទម្រង់ខុសពីរចនាសម្ព័ន្ធផ្ទុកក្នុងមូលដ្ឋានទិន្នន័យរបស់យើង?

ចូរយកជាឧទាហរណ៍ ការផ្ទុកអតិថិជន និងគណនីរបស់ពួកគេ ជម្រើស "ច្រើនទៅមួយ" បុរាណ៖

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)
);

ប៉ុន្តែការទាញយកពីប្រភពខាងក្រៅមករកយើងក្នុងទម្រង់ជា “all in one”៖

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