វិធីសាស្រ្តសម្រាប់បង្កើនប្រសិទ្ធភាពសំណួរ LINQ នៅក្នុង C#.NET

សេចក្តីណែនាំ

В អត្ថបទនេះ វិធីសាស្រ្តបង្កើនប្រសិទ្ធភាពមួយចំនួនត្រូវបានពិចារណា សំណួរ LINQ.
នៅទីនេះយើងក៏បង្ហាញវិធីសាស្រ្តមួយចំនួនបន្ថែមទៀតសម្រាប់ការបង្កើនប្រសិទ្ធភាពកូដដែលទាក់ទងនឹង សំណួរ LINQ.

វាត្រូវបានគេស្គាល់ថា លីន(Language-Integrated Query) គឺជាភាសាសាមញ្ញ និងងាយស្រួលសម្រាប់សួរប្រភពទិន្នន័យ។

А LINQ ទៅ SQL គឺជាបច្ចេកវិទ្យាសម្រាប់ចូលប្រើទិន្នន័យក្នុង DBMS ។ នេះគឺជាឧបករណ៍ដ៏មានឥទ្ធិពលសម្រាប់ធ្វើការជាមួយទិន្នន័យ ដែលសំណួរត្រូវបានបង្កើតតាមរយៈភាសាប្រកាស ដែលបន្ទាប់មកនឹងត្រូវបានបំប្លែងទៅជា សំណួរ SQL platform និងផ្ញើទៅកាន់ម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យសម្រាប់ការប្រតិបត្តិ។ ក្នុងករណីរបស់យើងដោយ DBMS យើងមានន័យថា ម៉ាស៊ីនបម្រើ MS SQL.

ទោះជាយ៉ាងណា, សំណួរ LINQ មិន​ត្រូវ​បាន​បំប្លែង​ទៅ​ជា​ការ​សរសេរ​ដែល​ល្អ​បំផុត​ទេ។ សំណួរ SQLដែល DBA ដែលមានបទពិសោធន៍អាចសរសេរជាមួយនឹងភាពប្រសើរឡើងទាំងអស់នៃការបង្កើនប្រសិទ្ធភាព សំណួរ SQL:

1. ការតភ្ជាប់ល្អបំផុត (ចូលរួម) និងត្រងលទ្ធផល (ទីកន្លែង)
2. nuances ជាច្រើនក្នុងការប្រើប្រាស់ការតភ្ជាប់ និងលក្ខខណ្ឌក្រុម
3. ការប្រែប្រួលជាច្រើនក្នុងការជំនួសលក្ខខណ្ឌ IN នៅលើ និក្ខេបបទи មិន​នៅក្នុង, <> លើ និក្ខេបបទ
4. ឃ្លាំងសម្ងាត់កម្រិតមធ្យមនៃលទ្ធផលតាមរយៈតារាងបណ្តោះអាសន្ន CTE អថេរតារាង
5. ការប្រើប្រាស់ប្រយោគ (ជម្រើស) ជាមួយនឹងការណែនាំនិងការណែនាំតារាង ជាមួយ (... )
6. ការប្រើប្រាស់ទិដ្ឋភាពដែលបានធ្វើលិបិក្រមជាមធ្យោបាយមួយដើម្បីកម្ចាត់ការអានទិន្នន័យដែលលែងត្រូវការតទៅទៀតអំឡុងពេលជ្រើសរើស

ការរាំងស្ទះនៃការអនុវត្តសំខាន់នៃលទ្ធផល សំណួរ SQL នៅពេលចងក្រង សំណួរ LINQ គឺ:

1. ការបង្រួបបង្រួមនៃយន្តការជ្រើសរើសទិន្នន័យទាំងមូលនៅក្នុងសំណើមួយ។
2. ស្ទួនប្លុកកូដដូចគ្នា ដែលនៅទីបំផុតនាំទៅដល់ការអានទិន្នន័យដែលមិនចាំបាច់ច្រើន។
3. ក្រុមនៃលក្ខខណ្ឌពហុសមាសភាគ (ឡូជីខល "និង" និង "ឬ") - និង и ORដោយរួមបញ្ចូលទៅក្នុងលក្ខខណ្ឌដ៏ស្មុគស្មាញ នាំឱ្យការពិតដែលថាកម្មវិធីបង្កើនប្រសិទ្ធភាពដែលមានសន្ទស្សន៍ដែលមិនមែនជាចង្កោមសមរម្យសម្រាប់វាលចាំបាច់ ទីបំផុតចាប់ផ្តើមស្កេនប្រឆាំងនឹងសន្ទស្សន៍ចង្កោម (INDEX ស្កេន) តាមក្រុមលក្ខខណ្ឌ
4. ការ​ដាក់​សំបុក​ជ្រៅ​នៃ​សំណួរ​រង​ធ្វើ​ឱ្យ​ការ​ញែក​មាន​បញ្ហា​ខ្លាំង​ណាស់។ សេចក្តីថ្លែងការណ៍ SQL និងការវិភាគនៃផែនការសំណួរនៅលើផ្នែកនៃអ្នកអភិវឌ្ឍន៍ និង ដាបា

វិធីសាស្ត្របង្កើនប្រសិទ្ធភាព

ឥឡូវនេះសូមផ្លាស់ទីដោយផ្ទាល់ទៅវិធីសាស្ត្របង្កើនប្រសិទ្ធភាព។

1) ការធ្វើលិបិក្រមបន្ថែម

វាជាការល្អបំផុតក្នុងការពិចារណាលើតម្រងនៅលើតារាងជ្រើសរើសមេ ព្រោះជាញឹកញាប់សំណួរទាំងមូលត្រូវបានបង្កើតឡើងជុំវិញតារាងសំខាន់មួយ ឬពីរ (កម្មវិធី-មនុស្ស-ប្រតិបត្តិការ) និងជាមួយសំណុំលក្ខខណ្ឌស្តង់ដារ (IsClosed, Canceled, Enabled, Status)។ វាមានសារៈសំខាន់ណាស់ក្នុងការបង្កើតសន្ទស្សន៍សមរម្យសម្រាប់គំរូដែលបានកំណត់។

ដំណោះស្រាយនេះសមហេតុផលនៅពេលជ្រើសរើសវាលទាំងនេះកំណត់យ៉ាងសំខាន់នូវសំណុំដែលបានត្រឡប់មកវិញចំពោះសំណួរ។

ឧទាហរណ៍ យើងមានកម្មវិធីចំនួន 500000។ ទោះយ៉ាងណាក៏ដោយមានកម្មវិធីសកម្មចំនួន 2000 ប៉ុណ្ណោះ។ បន្ទាប់មកលិបិក្រមដែលបានជ្រើសរើសត្រឹមត្រូវនឹងជួយសង្គ្រោះយើងពី INDEX ស្កេន នៅលើតារាងធំមួយ ហើយនឹងអនុញ្ញាតឱ្យអ្នកជ្រើសរើសទិន្នន័យបានយ៉ាងឆាប់រហ័សតាមរយៈលិបិក្រមដែលមិនមែនជាចង្កោម។

ផងដែរ កង្វះលិបិក្រមអាចត្រូវបានកំណត់អត្តសញ្ញាណតាមរយៈការជម្រុញសម្រាប់ការវិភាគផែនការសំណួរ ឬប្រមូលស្ថិតិមើលប្រព័ន្ធ ម៉ាស៊ីនបម្រើ MS SQL:

1. sys.dm_db_missing_index_groups
2. sys.dm_db_missing_index_group_stats
3. sys.dm_db_missing_index_details

ទិន្នន័យមើលទាំងអស់មានព័ត៌មានអំពីលិបិក្រមដែលបាត់ លើកលែងតែសន្ទស្សន៍លំហ។

ទោះជាយ៉ាងណាក៏ដោយ លិបិក្រម និងឃ្លាំងសម្ងាត់ ជារឿយៗជាវិធីសាស្រ្តក្នុងការប្រយុទ្ធប្រឆាំងនឹងផលវិបាកនៃការសរសេរមិនបានល្អ។ សំណួរ LINQ и សំណួរ SQL.

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

នេះសមហេតុផលមួយផ្នែក ដោយសារអ្នកប្រើប្រាស់មិនតែងតែត្រូវការទិន្នន័យចុងក្រោយបំផុត ហើយមានកម្រិតដែលអាចទទួលយកបាននៃការឆ្លើយតបនៃចំណុចប្រទាក់អ្នកប្រើប្រាស់។

វិធីសាស្រ្តនេះអនុញ្ញាតឱ្យដោះស្រាយតម្រូវការអាជីវកម្ម ប៉ុន្តែនៅទីបំផុតកាត់បន្ថយដំណើរការនៃប្រព័ន្ធព័ត៌មានដោយគ្រាន់តែពន្យារពេលដំណោះស្រាយចំពោះបញ្ហា។

វាក៏គួរឱ្យចងចាំផងដែរថានៅក្នុងដំណើរការនៃការស្វែងរកលិបិក្រមចាំបាច់ដើម្បីបន្ថែមការផ្ដល់យោបល់ MS SQL ការបង្កើនប្រសិទ្ធភាពអាចមិនត្រឹមត្រូវ រួមទាំងនៅក្រោមលក្ខខណ្ឌខាងក្រោម៖

1. ប្រសិនបើមានលិបិក្រមដែលមានសំណុំវាលស្រដៀងគ្នារួចហើយ
2. ប្រសិនបើ​វាល​ក្នុង​តារាង​មិន​អាច​ត្រូវ​បាន​ធ្វើ​លិបិក្រម​ដោយ​សារ​តែ​ការ​រឹតត្បិត​ការ​ធ្វើ​លិបិក្រម (ពិពណ៌នា​លម្អិត​បន្ថែម​ទៀត នៅទីនេះ).

2) ការបញ្ចូលគុណលក្ខណៈទៅជាគុណលក្ខណៈថ្មីមួយ

ពេលខ្លះវាលមួយចំនួនពីតារាងមួយ ដែលបម្រើជាមូលដ្ឋានសម្រាប់ក្រុមនៃលក្ខខណ្ឌ អាចត្រូវបានជំនួសដោយការណែនាំវាលថ្មីមួយ។

នេះជាការពិតជាពិសេសសម្រាប់វាលស្ថានភាព ដែលជាធម្មតាជាប្រភេទប៊ីត ឬចំនួនគត់។

ឧទាហរណ៍:

IsClosed = 0 និង Canceled = 0 និង Enabled = 0 ត្រូវបានជំនួសដោយ ស្ថានភាព = ២.

នេះគឺជាកន្លែងដែលគុណលក្ខណៈស្ថានភាពចំនួនគត់ត្រូវបានណែនាំ ដើម្បីធានាថាស្ថានភាពទាំងនេះត្រូវបានបញ្ចូលក្នុងតារាង។ បន្ទាប់ គុណលក្ខណៈថ្មីនេះត្រូវបានធ្វើលិបិក្រម។

នេះ​ជា​ដំណោះ​ស្រាយ​មូលដ្ឋាន​សម្រាប់​បញ្ហា​ការ​អនុវត្ត ព្រោះ​យើង​ចូល​ប្រើ​ទិន្នន័យ​ដោយ​មិន​ចាំបាច់​គណនា។

3) សម្ភារៈនៃទិដ្ឋភាព

ជាអកុសលនៅក្នុង សំណួរ LINQ តារាងបណ្តោះអាសន្ន CTE និងអថេរតារាងមិនអាចប្រើដោយផ្ទាល់បានទេ។

ទោះយ៉ាងណាក៏ដោយ មានវិធីមួយផ្សេងទៀតដើម្បីបង្កើនប្រសិទ្ធភាពសម្រាប់ករណីនេះ - ទិដ្ឋភាពដែលបានធ្វើលិបិក្រម។

ក្រុមលក្ខខណ្ឌ (ពីឧទាហរណ៍ខាងលើ) IsClosed = 0 និង Canceled = 0 និង Enabled = 0 (ឬសំណុំនៃលក្ខខណ្ឌស្រដៀងគ្នាផ្សេងទៀត) ក្លាយជាជម្រើសដ៏ល្អមួយក្នុងការប្រើប្រាស់ពួកវានៅក្នុងទិដ្ឋភាពដែលបានធ្វើលិបិក្រម ដោយរក្សាទុកទិន្នន័យតូចៗពីសំណុំធំមួយ។

ប៉ុន្តែមានការរឹតត្បិតមួយចំនួននៅពេលបង្កើតទិដ្ឋភាព៖

1. ការប្រើប្រាស់នៃ subqueries, clauses និក្ខេបបទ គួរតែត្រូវបានជំនួសដោយការប្រើប្រាស់ ចូលរួម
2. អ្នកមិនអាចប្រើប្រយោគបានទេ។ សហជីព, សហជីពទាំងអស់, ករណី​លើកលែង, អ៊ិនធឺណិត
3. អ្នកមិនអាចប្រើការណែនាំ និងឃ្លាតារាងបានទេ។ ជម្រើស
4. មិនមានលទ្ធភាពធ្វើការជាមួយវដ្តទេ។
5. វាមិនអាចទៅរួចទេក្នុងការបង្ហាញទិន្នន័យក្នុងទិដ្ឋភាពមួយពីតារាងផ្សេងៗគ្នា

វាជាការសំខាន់ក្នុងការចងចាំថាអត្ថប្រយោជន៍ពិតប្រាកដនៃការប្រើប្រាស់ទិដ្ឋភាពដែលបានធ្វើលិបិក្រមអាចសម្រេចបានតែតាមរយៈការធ្វើលិបិក្រមវាប៉ុណ្ណោះ។

ប៉ុន្តែនៅពេលហៅទិដ្ឋភាព លិបិក្រមទាំងនេះអាចនឹងមិនត្រូវបានប្រើ ហើយដើម្បីប្រើពួកវាឱ្យច្បាស់លាស់ អ្នកត្រូវតែបញ្ជាក់ ជាមួយ (NOEXPAND).

ចាប់តាំងពីនៅក្នុង សំណួរ LINQ វាមិនអាចទៅរួចទេក្នុងការកំណត់ព័ត៌មានជំនួយក្នុងតារាង ដូច្នេះអ្នកត្រូវបង្កើតតំណាងមួយផ្សេងទៀត - "រុំ" នៃទម្រង់ខាងក្រោម៖

CREATE VIEW ИМЯ_представления AS SELECT * FROM MAT_VIEW WITH (NOEXPAND);

4) ការប្រើប្រាស់មុខងារតារាង

ជាញឹកញាប់នៅក្នុង សំណួរ LINQ ប្លុកធំនៃសំណួររង ឬប្លុកដោយប្រើទិដ្ឋភាពដែលមានរចនាសម្ព័ន្ធស្មុគស្មាញបង្កើតជាសំណួរចុងក្រោយជាមួយនឹងរចនាសម្ព័ន្ធប្រតិបត្តិដ៏ស្មុគស្មាញ និងសមស្របបំផុត។

អត្ថប្រយោជន៍សំខាន់ៗនៃការប្រើប្រាស់មុខងារតារាងក្នុង សំណួរ LINQ:

1. សមត្ថភាព ដូចជានៅក្នុងករណីនៃទិដ្ឋភាព ដែលត្រូវប្រើ និងបញ្ជាក់ជាវត្ថុមួយ ប៉ុន្តែអ្នកអាចឆ្លងកាត់សំណុំនៃប៉ារ៉ាម៉ែត្របញ្ចូល៖
   ពីមុខងារ (@param1, @param2 ... )
   ជាលទ្ធផល គំរូទិន្នន័យដែលអាចបត់បែនបានអាចសម្រេចបាន។
2. នៅក្នុងករណីនៃការប្រើប្រាស់មុខងារតារាង មិនមានការរឹតបន្តឹងខ្លាំងដូចនៅក្នុងករណីនៃទិដ្ឋភាពលិបិក្រមដែលបានពិពណ៌នាខាងលើទេ៖
   1. ការណែនាំតារាង៖
      តាមរយៈការ លីន អ្នក​មិន​អាច​បញ្ជាក់​លិបិក្រម​ណា​ដែល​គួរ​ត្រូវ​បាន​ប្រើ និង​កំណត់​កម្រិត​ឯកោ​ទិន្នន័យ​ពេល​សួរ។
      ប៉ុន្តែមុខងារមានសមត្ថភាពទាំងនេះ។
      ជាមួយនឹងមុខងារ អ្នកអាចសម្រេចបាននូវផែនការសំណួរប្រតិបត្តិថេរដោយស្មើភាព ដែលច្បាប់សម្រាប់ធ្វើការជាមួយសន្ទស្សន៍ និងកម្រិតភាពឯកោទិន្នន័យត្រូវបានកំណត់។
   2. ការប្រើប្រាស់មុខងារអនុញ្ញាតឱ្យ នៅក្នុងការប្រៀបធៀបជាមួយនឹងទិដ្ឋភាពដែលបានធ្វើលិបិក្រម ដើម្បីទទួលបាន៖
      • តក្កវិជ្ជាគំរូទិន្នន័យស្មុគស្មាញ (សូម្បីតែប្រើរង្វិលជុំ)
      • ទាញយកទិន្នន័យពីតារាងផ្សេងៗគ្នាជាច្រើន។
      • ការប្រើប្រាស់ សហជីព и និក្ខេបបទ

3. ការផ្តល់ជូន ជម្រើស មាន​ប្រយោជន៍​ខ្លាំង​ណាស់​នៅ​ពេល​ដែល​យើង​ត្រូវ​ការ​ដើម្បី​ផ្តល់​ឱ្យ​នូវ​ការ​ត្រួត​ពិនិត្យ​ស្រប​គ្នា។ OPTION(MAXDOP N)លំដាប់នៃផែនការប្រតិបត្តិសំណួរ។ ឧទាហរណ៍:
   • អ្នកអាចបញ្ជាក់ការបង្កើតឡើងវិញដោយបង្ខំនៃផែនការសំណួរ ជម្រើស (បំពេញឡើងវិញ)
   • អ្នកអាចបញ្ជាក់ថាតើត្រូវបង្ខំផែនការសំណួរឱ្យប្រើលំដាប់ចូលរួមដែលបានបញ្ជាក់នៅក្នុងសំណួរ ជម្រើស (បង្ខំការបញ្ជាទិញ)

   ព័ត៌មានលម្អិតបន្ថែមអំពី ជម្រើស បានពិពណ៌នា នៅទីនេះ.

4. ការប្រើប្រាស់ផ្នែកទិន្នន័យតូចចង្អៀត និងចាំបាច់បំផុត៖
   មិនចាំបាច់រក្សាទុកសំណុំទិន្នន័យធំនៅក្នុងឃ្លាំងសម្ងាត់ទេ (ដូចករណីដែលបានធ្វើលិបិក្រម) ដែលអ្នកនៅតែត្រូវត្រងទិន្នន័យតាមប៉ារ៉ាម៉ែត្រ។
   ឧទាហរណ៍មានតារាងដែលតម្រង ទីកន្លែង វាលបីត្រូវបានប្រើ (a, ខ, គ).

   តាមធម្មតា សំណើទាំងអស់មានលក្ខខណ្ឌថេរ a = 0 និង b = 0.

   ទោះ​យ៉ាង​ណា​ការ​ស្នើ​សុំ​សម្រាប់​វាល​នេះ​ c អថេរច្រើនទៀត។

   អនុញ្ញាតឱ្យលក្ខខណ្ឌ a = 0 និង b = 0 វាពិតជាជួយយើងក្នុងការកំណត់លទ្ធផលដែលបានកំណត់ទៅជាកំណត់ត្រារាប់ពាន់ ប៉ុន្តែលក្ខខណ្ឌនៅលើ с បង្រួម​ការ​ជ្រើសរើស​ចុះ​ដល់​មួយ​រយ​កំណត់ត្រា។

   នៅទីនេះមុខងារតារាងអាចជាជម្រើសល្អជាង។

   ដូចគ្នានេះផងដែរ មុខងារតារាងគឺអាចទស្សន៍ទាយបានច្រើនជាងមុន និងស្របគ្នាក្នុងពេលវេលាប្រតិបត្តិ។

ឧទហរណ៍

សូមក្រឡេកមើលការអនុវត្តឧទាហរណ៍ដោយប្រើមូលដ្ឋានទិន្នន័យសំណួរជាឧទាហរណ៍។

មានសំណើមួយ។ ជ្រើសរើសដែលរួមបញ្ចូលគ្នានូវតារាងជាច្រើន និងប្រើទិដ្ឋភាពតែមួយ (OperativeQuestions) ដែលក្នុងនោះទំនាក់ទំនងត្រូវបានត្រួតពិនិត្យតាមអ៊ីមែល (តាមរយៈ និក្ខេបបទ) ទៅ "សំណួរប្រតិបត្តិការ"៖

សំណើលេខ 1

(@p__linq__0 nvarchar(4000))SELECT
1 AS [C1],
[Extent1].[Id] AS [Id],
[Join2].[Object_Id] AS [Object_Id],
[Join2].[ObjectType_Id] AS [ObjectType_Id],
[Join2].[Name] AS [Name],
[Join2].[ExternalId] AS [ExternalId]
FROM [dbo].[Questions] AS [Extent1]
INNER JOIN (SELECT [Extent2].[Object_Id] AS [Object_Id],
[Extent2].[Question_Id] AS [Question_Id], [Extent3].[ExternalId] AS [ExternalId],
[Extent3].[ObjectType_Id] AS [ObjectType_Id], [Extent4].[Name] AS [Name]
FROM [dbo].[ObjectQuestions] AS [Extent2]
INNER JOIN [dbo].[Objects] AS [Extent3] ON [Extent2].[Object_Id] = [Extent3].[Id]
LEFT OUTER JOIN [dbo].[ObjectTypes] AS [Extent4] 
ON [Extent3].[ObjectType_Id] = [Extent4].[Id] ) AS [Join2] 
ON [Extent1].[Id] = [Join2].[Question_Id]
WHERE ([Extent1].[AnswerId] IS NULL) AND (0 = [Extent1].[Exp]) AND ( EXISTS (SELECT
1 AS [C1]
FROM [dbo].[OperativeQuestions] AS [Extent5]
WHERE (([Extent5].[Email] = @p__linq__0) OR (([Extent5].[Email] IS NULL) 
AND (@p__linq__0 IS NULL))) AND ([Extent5].[Id] = [Extent1].[Id])
));

ទិដ្ឋភាព​មាន​រចនាសម្ព័ន្ធ​ស្មុគស្មាញ៖ វា​មាន​ការ​ភ្ជាប់​សំណួរ​រង និង​ប្រើ​ការ​តម្រៀប DISTINCTដែលជាទូទៅគឺជាប្រតិបត្តិការដែលពឹងផ្អែកលើធនធានដោយយុត្តិធម៌។

គំរូមួយពីសំណួរប្រតិបត្តិការគឺប្រហែលមួយម៉ឺនកំណត់ត្រា។

បញ្ហាចម្បងជាមួយសំណួរនេះគឺថាសម្រាប់កំណត់ត្រាពីសំណួរខាងក្រៅ សំណួររងខាងក្នុងត្រូវបានប្រតិបត្តិលើទិដ្ឋភាព [OperativeQuestions] ដែលគួរតែសម្រាប់ [Email] = @p__linq__0 អនុញ្ញាតឱ្យយើងកំណត់ការជ្រើសរើសលទ្ធផល (តាមរយៈ និក្ខេបបទ) រហូតដល់រាប់រយកំណត់ត្រា។

ហើយវាហាក់ដូចជាថា សំណួររងគួរតែគណនាកំណត់ត្រាម្តងដោយ [Email] = @p__linq__0 ហើយបន្ទាប់មកកំណត់ត្រាពីរបីរយទាំងនេះគួរតែត្រូវបានភ្ជាប់ដោយ Id ជាមួយសំណួរ ហើយសំណួរនឹងលឿន។

តាមពិត មានការតភ្ជាប់តាមលំដាប់លំដោយនៃតារាងទាំងអស់៖ ពិនិត្យមើលការឆ្លើយឆ្លងនៃសំណួរលេខសម្គាល់ជាមួយ Id ពី OperativeQuestions និងការត្រងតាមអ៊ីមែល។

តាមការពិត សំណើនេះដំណើរការជាមួយកំណត់ត្រា OperativeQuestions រាប់ម៉ឺនទាំងអស់ ប៉ុន្តែមានតែទិន្នន័យចំណាប់អារម្មណ៍ប៉ុណ្ណោះដែលត្រូវការតាមរយៈអ៊ីម៉ែល។

សំណួរប្រតិបត្តិការមើលអត្ថបទ៖

សំណើលេខ 2

 
CREATE VIEW [dbo].[OperativeQuestions]
AS
SELECT DISTINCT Q.Id, USR.email AS Email
FROM            [dbo].Questions AS Q INNER JOIN
                         [dbo].ProcessUserAccesses AS BPU ON BPU.ProcessId = CQ.Process_Id 
OUTER APPLY
                     (SELECT   1 AS HasNoObjects
                      WHERE   NOT EXISTS
                                    (SELECT   1
                                     FROM     [dbo].ObjectUserAccesses AS BOU
                                     WHERE   BOU.ProcessUserAccessId = BPU.[Id] AND BOU.[To] IS NULL)
) AS BO INNER JOIN
                         [dbo].Users AS USR ON USR.Id = BPU.UserId
WHERE        CQ.[Exp] = 0 AND CQ.AnswerId IS NULL AND BPU.[To] IS NULL 
AND (BO.HasNoObjects = 1 OR
              EXISTS (SELECT   1
                           FROM   [dbo].ObjectUserAccesses AS BOU INNER JOIN
                                      [dbo].ObjectQuestions AS QBO 
                                                  ON QBO.[Object_Id] =BOU.ObjectId
                               WHERE  BOU.ProcessUserAccessId = BPU.Id 
                               AND BOU.[To] IS NULL AND QBO.Question_Id = CQ.Id));

ការគូសផែនទីទិដ្ឋភាពដំបូងនៅក្នុង DbContext (EF Core 2)

public class QuestionsDbContext : DbContext
{
    //...
    public DbQuery<OperativeQuestion> OperativeQuestions { get; set; }
    //...
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Query<OperativeQuestion>().ToView("OperativeQuestions");
    }
}

សំណួរ LINQ ដំបូង

var businessObjectsData = await context
    .OperativeQuestions
    .Where(x => x.Email == Email)
    .Include(x => x.Question)
    .Select(x => x.Question)
    .SelectMany(x => x.ObjectQuestions,
                (x, bo) => new
                {
                    Id = x.Id,
                    ObjectId = bo.Object.Id,
                    ObjectTypeId = bo.Object.ObjectType.Id,
                    ObjectTypeName = bo.Object.ObjectType.Name,
                    ObjectExternalId = bo.Object.ExternalId
                })
    .ToListAsync();

ក្នុងករណីពិសេសនេះ យើងកំពុងពិចារណាដំណោះស្រាយចំពោះបញ្ហានេះដោយគ្មានការផ្លាស់ប្តូររចនាសម្ព័ន្ធ ដោយមិនបង្ហាញតារាងដាច់ដោយឡែកជាមួយនឹងលទ្ធផលដែលត្រៀមរួចជាស្រេច ("សំណួរសកម្ម") ដែលនឹងតម្រូវឱ្យមានយន្តការសម្រាប់បំពេញវាជាមួយនឹងទិន្នន័យ និងរក្សាវាឱ្យទាន់សម័យ។ .

ទោះបីជានេះជាដំណោះស្រាយដ៏ល្អក៏ដោយ មានជម្រើសមួយផ្សេងទៀតដើម្បីបង្កើនប្រសិទ្ធភាពបញ្ហានេះ។

គោល​បំណង​ចម្បង​គឺ​ដើម្បី​រក្សា​ទុក​ធាតុ​ដោយ [Email] = @p__linq__0 ពី​ទិដ្ឋភាព OperativeQuestions ។

ណែនាំមុខងារតារាង [dbo].[OperativeQuestionsUserMail] ទៅក្នុងមូលដ្ឋានទិន្នន័យ។

តាមរយៈការផ្ញើអ៊ីមែលជាប៉ារ៉ាម៉ែត្របញ្ចូល យើងទទួលបានតារាងតម្លៃមកវិញ៖

សំណើលេខ 3

CREATE FUNCTION [dbo].[OperativeQuestionsUserMail]
(
    @Email  nvarchar(4000)
)
RETURNS
@tbl TABLE
(
    [Id]           uniqueidentifier,
    [Email]      nvarchar(4000)
)
AS
BEGIN
        INSERT INTO @tbl ([Id], [Email])
        SELECT Id, @Email
        FROM [OperativeQuestions]  AS [x] WHERE [x].[Email] = @Email;
     
    RETURN;
END

វាត្រឡប់តារាងតម្លៃជាមួយនឹងរចនាសម្ព័ន្ធទិន្នន័យដែលបានកំណត់ជាមុន។

ដើម្បីឱ្យសំណួរទៅកាន់ OperativeQuestionsUserMail មានភាពល្អប្រសើរ និងមានផែនការសំណួរដ៏ល្អប្រសើរ រចនាសម្ព័ន្ធដ៏តឹងរឹងគឺត្រូវបានទាមទារ និងមិន តារាងត្រឡប់ជាការត្រឡប់មកវិញ...

ក្នុងករណីនេះ សំណួរទី 1 ដែលត្រូវការត្រូវបានបំប្លែងទៅជាសំណួរទី 4៖

សំណើលេខ 4

(@p__linq__0 nvarchar(4000))SELECT
1 AS [C1],
[Extent1].[Id] AS [Id],
[Join2].[Object_Id] AS [Object_Id],
[Join2].[ObjectType_Id] AS [ObjectType_Id],
[Join2].[Name] AS [Name],
[Join2].[ExternalId] AS [ExternalId]
FROM (
    SELECT Id, Email FROM [dbo].[OperativeQuestionsUserMail] (@p__linq__0)
) AS [Extent0]
INNER JOIN [dbo].[Questions] AS [Extent1] ON([Extent0].Id=[Extent1].Id)
INNER JOIN (SELECT [Extent2].[Object_Id] AS [Object_Id], [Extent2].[Question_Id] AS [Question_Id], [Extent3].[ExternalId] AS [ExternalId], [Extent3].[ObjectType_Id] AS [ObjectType_Id], [Extent4].[Name] AS [Name]
FROM [dbo].[ObjectQuestions] AS [Extent2]
INNER JOIN [dbo].[Objects] AS [Extent3] ON [Extent2].[Object_Id] = [Extent3].[Id]
LEFT OUTER JOIN [dbo].[ObjectTypes] AS [Extent4] 
ON [Extent3].[ObjectType_Id] = [Extent4].[Id] ) AS [Join2] 
ON [Extent1].[Id] = [Join2].[Question_Id]
WHERE ([Extent1].[AnswerId] IS NULL) AND (0 = [Extent1].[Exp]);

ទិដ្ឋភាពផែនទី និងមុខងារនៅក្នុង DbContext (EF Core 2)

public class QuestionsDbContext : DbContext
{
    //...
    public DbQuery<OperativeQuestion> OperativeQuestions { get; set; }
    //...
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Query<OperativeQuestion>().ToView("OperativeQuestions");
    }
}
 
public static class FromSqlQueries
{
    public static IQueryable<OperativeQuestion> GetByUserEmail(this DbQuery<OperativeQuestion> source, string Email)
        => source.FromSql($"SELECT Id, Email FROM [dbo].[OperativeQuestionsUserMail] ({Email})");
}

សំណួរ LINQ ចុងក្រោយ

var businessObjectsData = await context
    .OperativeQuestions
    .GetByUserEmail(Email)
    .Include(x => x.Question)
    .Select(x => x.Question)
    .SelectMany(x => x.ObjectQuestions,
                (x, bo) => new
                {
                    Id = x.Id,
                    ObjectId = bo.Object.Id,
                    ObjectTypeId = bo.Object.ObjectType.Id,
                    ObjectTypeName = bo.Object.ObjectType.Name,
                    ObjectExternalId = bo.Object.ExternalId
                })
    .ToListAsync();

លំដាប់នៃពេលវេលាប្រតិបត្តិបានធ្លាក់ចុះពី 200-800 ms ទៅ 2-20 ms ។ល។ ពោលគឺលឿនជាងដប់ដង។

ប្រសិនបើយើងយកវាជាមធ្យម នោះជំនួសឱ្យ 350 ms យើងទទួលបាន 8 ms ។

ពីអត្ថប្រយោជន៍ជាក់ស្តែង យើងក៏ទទួលបាន៖

1. ការថយចុះជាទូទៅនៃបន្ទុកអាន
2. ការថយចុះយ៉ាងខ្លាំងនៃលទ្ធភាពនៃការទប់ស្កាត់
3. កាត់បន្ថយពេលវេលាទប់ស្កាត់ជាមធ្យមទៅជាតម្លៃដែលអាចទទួលយកបាន។

សេចក្តីសន្និដ្ឋាន

ការបង្កើនប្រសិទ្ធភាព និងការកែតម្រូវការហៅទូរសព្ទមូលដ្ឋានទិន្នន័យ MS SQL តាមរយៈការ លីន គឺជាបញ្ហាដែលអាចដោះស្រាយបាន។

ការយកចិត្តទុកដាក់ និងភាពស៊ីសង្វាក់គ្នាមានសារៈសំខាន់ណាស់ក្នុងការងារនេះ។

នៅដើមដំណើរការ៖

1. វាចាំបាច់ដើម្បីពិនិត្យមើលទិន្នន័យដែលសំណើដំណើរការ (តម្លៃ ប្រភេទទិន្នន័យដែលបានជ្រើសរើស)
2. អនុវត្តការធ្វើលិបិក្រមត្រឹមត្រូវនៃទិន្នន័យនេះ។
3. ពិនិត្យភាពត្រឹមត្រូវនៃលក្ខខណ្ឌចូលរួមរវាងតារាង

ការធ្វើឱ្យប្រសើរឡើងវិញបន្ទាប់បង្ហាញឱ្យឃើញ:

1. មូលដ្ឋាននៃសំណើ និងកំណត់តម្រងសំណើសំខាន់
2. ការធ្វើឡើងវិញនូវប្លុកសំណួរស្រដៀងគ្នា និងការវិភាគចំណុចប្រសព្វនៃលក្ខខណ្ឌ
3. នៅក្នុង SSMS ឬ GUI ផ្សេងទៀតសម្រាប់ ម៉ាស៊ីនបម្រើ SQL ធ្វើឱ្យខ្លួនវាប្រសើរឡើង សំណួរ SQL (បែងចែកការផ្ទុកទិន្នន័យកម្រិតមធ្យម បង្កើតសំណួរលទ្ធផលដោយប្រើការផ្ទុកនេះ (អាចមានច្រើន))
4. នៅដំណាក់កាលចុងក្រោយ ដោយយកជាមូលដ្ឋាននៃលទ្ធផល សំណួរ SQL, រចនាសម្ព័ន្ធកំពុងត្រូវបានសាងសង់ឡើងវិញ សំណួរ LINQ

លទ្ធផល សំណួរ LINQ គួរតែមានលក្ខណៈដូចគ្នាបេះបិទនៅក្នុងរចនាសម្ព័ន្ធទៅនឹងការល្អបំផុតដែលបានកំណត់ សំណួរ SQL ពីចំណុច 3 ។

ការដឹងគុណ

អរគុណច្រើនចំពោះមិត្តរួមការងារ ការងារ и alex_ozr ពីក្រុមហ៊ុន Fortis សម្រាប់ជំនួយក្នុងការរៀបចំសម្ភារៈនេះ។

ប្រភព: www.habr.com