ရှာဖွေမှုရလဒ်များထွက်ရှိမှုနှင့် စွမ်းဆောင်ရည်ပြဿနာများ

ကျွန်ုပ်တို့နှင့်ရင်းနှီးသော အပလီကေးရှင်းများအားလုံးရှိ ပုံမှန်အခြေအနေများထဲမှတစ်ခုမှာ အချို့သောသတ်မှတ်ချက်များအတိုင်း ဒေတာကိုရှာဖွေပြီး ဖတ်ရလွယ်ကူသောပုံစံဖြင့် ပြသခြင်းဖြစ်သည်။ အမျိုးအစားခွဲခြင်း၊ အုပ်စုဖွဲ့ခြင်းနှင့် စာမျက်နှာတင်ခြင်းအတွက် နောက်ထပ်ရွေးချယ်စရာများလည်း ရှိနိုင်ပါသည်။ အလုပ်သည် သီအိုရီအရ အသေးအဖွဲဖြစ်သော်လည်း ၎င်းကိုဖြေရှင်းသောအခါတွင် developer အများအပြားသည် အမှားများစွာပြုလုပ်ကြပြီး နောက်ပိုင်းတွင် ကုန်ထုတ်စွမ်းအားကို ထိခိုက်စေသည်။ ဤပြဿနာကိုဖြေရှင်းရန် အမျိုးမျိုးသောရွေးချယ်စရာများကို စဉ်းစားပြီး အထိရောက်ဆုံးအကောင်အထည်ဖော်မှုကို ရွေးချယ်ရန်အတွက် အကြံပြုချက်များကို ရေးဆွဲကြပါစို့။

စာမျက်နှာရွေးချယ်မှု နံပါတ် ၁

အရိုးရှင်းဆုံးရွေးချယ်မှုမှာ ၎င်း၏ဂန္ထဝင်ပုံစံဖြင့် ရှာဖွေမှုရလဒ်များကို တစ်မျက်နှာချင်း တစ်မျက်နှာချင်းပြသခြင်းဖြစ်သည်။

သင့်အပလီကေးရှင်းသည် ဆက်စပ်ဒေတာဘေ့စ်ကို အသုံးပြုသည်ဆိုပါစို့။ ဤကိစ္စတွင်၊ ဤဖောင်တွင် အချက်အလက်ပြသရန်၊ သင်သည် SQL queries နှစ်ခုကို လုပ်ဆောင်ရန် လိုအပ်သည်-

• လက်ရှိစာမျက်နှာအတွက် အတန်းများရယူပါ။
• ရှာဖွေမှုစံနှုန်းများနှင့် သက်ဆိုင်သည့် စာကြောင်းစုစုပေါင်းကို တွက်ချက်ပါ - ၎င်းသည် စာမျက်နှာများကို ပြသရန် လိုအပ်သည်။

နမူနာအနေနဲ့ MS SQL ဒေတာဘေ့စ်ကို စမ်းသပ်အသုံးပြုထားတဲ့ ပထမဆုံးမေးခွန်းကို ကြည့်ရအောင် ကံကြမ္မာ 2016 ဆာဗာအတွက်။ ဤရည်ရွယ်ချက်အတွက် ကျွန်ုပ်တို့သည် Sales.SalesOrderHeader ဇယားကို အသုံးပြုပါမည်။

SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

အထက်ဖော်ပြပါ မေးမြန်းချက်သည် စာရင်းမှ ပထမဆုံး အမှာစာ 50 ကို ထပ်မံ၍ ကြီးစဉ်ငယ်လိုက် ရက်စွဲဖြင့် စီထားသည်၊ တစ်နည်းအားဖြင့်၊ လတ်တလော အမှာစာ 50 ကို ပြန်ပေးပါမည်။

၎င်းသည် စမ်းသပ်မှုအခြေခံတွင် လျင်မြန်စွာလည်ပတ်နေသော်လည်း အကောင်အထည်ဖော်မှုအစီအစဉ်နှင့် I/O ကိန်းဂဏန်းများကို ကြည့်ကြပါစို့။

Table 'SalesOrderHeader'. Scan count 1, logical reads 698, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

query runtime တွင် SET STATISTICS IO ON command ကို run ခြင်းဖြင့် query တစ်ခုစီအတွက် I/O ကိန်းဂဏန်းအချက်အလက်များကို သင် ရယူနိုင်ပါသည်။

အကောင်အထည်ဖော်မှု အစီအစဉ်မှ သင်တွေ့မြင်ရသည့်အတိုင်း၊ အရင်းအမြစ်-အများဆုံး ရွေးချယ်မှုမှာ ရင်းမြစ်ဇယား၏ အတန်းအားလုံးကို ထည့်သွင်းထားသော ရက်စွဲအလိုက် စီရန်ဖြစ်သည်။ ပြဿနာမှာ ဇယားတွင် အတန်းများများလေလေ၊ စီရန် "ပိုခက်" လာလေဖြစ်သည်။ လက်တွေ့တွင်၊ ထိုသို့သောအခြေအနေများကို ရှောင်ရှားသင့်သည်၊ ထို့ကြောင့် ထပ်လောင်းရက်စွဲတွင် အညွှန်းတစ်ခုထည့်ကာ အရင်းအမြစ်သုံးစွဲမှု ပြောင်းလဲသွားခြင်းရှိမရှိ ကြည့်ကြပါစို့။

Table 'SalesOrderHeader'. Scan count 1, logical reads 165, physical reads 0, read-ahead reads 5, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

ပိုကောင်းလာတာ သိသာပါတယ်။ ဒါပေမယ့် ပြဿနာအားလုံးကို ဖြေရှင်းပြီးပြီလား။ ကုန်ပစ္စည်းစုစုပေါင်း $100 ထက်ကျော်လွန်သော မှာယူမှုများကို ရှာဖွေရန် စုံစမ်းမေးမြန်းချက်ကို ပြောင်းလဲကြပါစို့။

SELECT * FROM Sales.SalesOrderHeader
WHERE SubTotal > 100
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

Table 'SalesOrderHeader'. Scan count 1, logical reads 1081, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

ကျွန်ုပ်တို့တွင် ရယ်စရာကောင်းသော အခြေအနေတစ်ခုရှိသည်- မေးမြန်းမှုအစီအစဉ်သည် ယခင်ပုံစံထက် များစွာဆိုးရွားခြင်းမရှိသော်လည်း အမှန်တကယ် ယုတ္တိဖတ်သည့်အရေအတွက်သည် စားပွဲအပြည့်စကင်ဖတ်ခြင်းထက် နှစ်ဆနီးပါး ကြီးမားပါသည်။ ထွက်လမ်းတစ်ခုရှိသည် - ကျွန်ုပ်တို့သည် ရှိပြီးသားအညွှန်းကိန်းတစ်ခုမှပေါင်းစပ်အညွှန်းတစ်ခုပြုလုပ်ပြီး ဒုတိယအကွက်အဖြစ် ကုန်ပစ္စည်းစုစုပေါင်းစျေးနှုန်းကို ပေါင်းထည့်ပါက၊ ကျွန်ုပ်တို့သည် ယုတ္တိနည်းစာဖတ်ခြင်း 165 ခုကို ထပ်မံရရှိမည်ဖြစ်ပါသည်။

CREATE INDEX IX_SalesOrderHeader_OrderDate_SubTotal on Sales.SalesOrderHeader(OrderDate, SubTotal);

ဤနမူနာများကို အချိန်အကြာကြီး ဆက်လက်လုပ်ဆောင်နိုင်သော်လည်း ဤနေရာတွင် ကျွန်ုပ်ဖော်ပြလိုသော အဓိက အတွေးနှစ်ခုမှာ-

• ရှာဖွေမှုတစ်ခုတွင် စံသတ်မှတ်ချက်အသစ် သို့မဟုတ် အမျိုးအစားခွဲသည့် အစီအစဉ်ကို ပေါင်းထည့်ခြင်းသည် ရှာဖွေမှု၏အမြန်နှုန်းအပေါ် သိသာထင်ရှားသောအကျိုးသက်ရောက်မှုရှိနိုင်သည်။
• သို့သော် ကျွန်ုပ်တို့သည် ဒေတာ၏ တစ်စိတ်တစ်ပိုင်းကိုသာ နုတ်ရန် လိုအပ်ပြီး ရှာဖွေမှု ဝေါဟာရများနှင့် ကိုက်ညီသော ရလဒ်များအားလုံးမဟုတ်ပါက၊ ထိုသို့သော မေးခွန်းကို အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်ရန် နည်းလမ်းများစွာ ရှိပါသည်။

ယခု အစတွင်ဖော်ပြထားသော ဒုတိယမေးခွန်းသို့ ဆက်သွားကြပါစို့ - ရှာဖွေမှုစံနှုန်းကို ကျေနပ်စေမည့် မှတ်တမ်းအရေအတွက်ကို ရေတွက်သည့်တစ်ခု။ တူညီသော ဥပမာကို ကြည့်ကြပါစို့ - $100 ထက်ပိုသော မှာယူမှုများကို ရှာဖွေခြင်း-

SELECT COUNT(1) FROM Sales.SalesOrderHeader
WHERE SubTotal > 100

အထက်တွင်ဖော်ပြထားသော ပေါင်းစပ်အညွှန်းကို ပေး၍ ကျွန်ုပ်တို့ ရရှိသည်-

Table 'SalesOrderHeader'. Scan count 1, logical reads 698, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SubTotal အကွက်သည် ပထမအနေအထားတွင်မရှိသောကြောင့် query သည် အညွှန်းတစ်ခုလုံးကိုဖြတ်သွားသည်ဟူသောအချက်မှာ အံ့သြစရာမဟုတ်ပေ။ SubTotal အကွက်တွင် အခြားသော အညွှန်းများကို ပေါင်းထည့်ခြင်းဖြင့် ပြဿနာကို ဖြေရှင်းနိုင်ပြီး ရလဒ်အနေဖြင့် ၎င်းသည် ယုတ္တိ ၄၈ ခုသာ ဖတ်ရှုနိုင်မည်ဖြစ်သည်။

ပမာဏရေတွက်ရန် တောင်းဆိုမှုများ၏ နောက်ထပ်ဥပမာအနည်းငယ်ကို သင်ပေးနိုင်သော်လည်း အနှစ်သာရမှာ အတူတူပင်ဖြစ်သည်- ဒေတာအပိုင်းအစကို လက်ခံရရှိခြင်းနှင့် စုစုပေါင်းပမာဏကို ရေတွက်ခြင်းမှာ အခြေခံအားဖြင့် မတူညီသော တောင်းဆိုမှုနှစ်ခုဖြစ်သည်။နှင့် တစ်ခုစီသည် ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ရန်အတွက် ၎င်း၏ကိုယ်ပိုင်အစီအမံများ လိုအပ်သည်။ ယေဘူယျအားဖြင့်၊ မေးခွန်းနှစ်ခုလုံးအတွက် အညီအမျှ ကောင်းစွာအလုပ်လုပ်နိုင်သော အညွှန်းကိန်းများ ပေါင်းစပ်မှုကို သင်ရှာတွေ့နိုင်မည်မဟုတ်ပါ။

ထို့ကြောင့်၊ ထိုသို့သောရှာဖွေမှုဖြေရှင်းချက်ကို ဖော်ထုတ်ရာတွင် ရှင်းလင်းသင့်သော အရေးကြီးသောလိုအပ်ချက်များထဲမှတစ်ခုမှာ တွေ့ရှိသည့်အရာဝတ္ထုအရေအတွက်ကို ကြည့်ရှုရန် လုပ်ငန်းတစ်ခုအတွက် အမှန်တကယ်အရေးကြီးသည်ရှိ၊ မဟုတ်တာ မကြာခဏ ဖြစ်တတ်ပါတယ်။ စာမျက်နှာနံပါတ်များအလိုက် လမ်းကြောင်းပြခြင်းသည် အလွန်ကျဉ်းမြောင်းသော နယ်ပယ်တစ်ခုဖြစ်သည့် ဖြေရှင်းချက်တစ်ခုဖြစ်ပြီး၊ စာမျက်နှာအများစုသည် “နောက်စာမျက်နှာသို့ သွားပါ” နှင့်တူသောကြောင့် ဖြစ်သည်။

စာမျက်နှာရွေးချယ်မှု နံပါတ် ၁

တွေ့ရှိသည့်အရာဝတ္ထုစုစုပေါင်းအရေအတွက်ကို သုံးစွဲသူများက ဂရုမစိုက်ကြောင်း ယူဆကြပါစို့။ ရှာဖွေမှုစာမျက်နှာကို ရိုးရှင်းအောင် ကြိုးစားကြပါစို့။

အမှန်မှာ၊ ပြောင်းလဲသွားသော တစ်ခုတည်းသောအရာမှာ သတ်မှတ်ထားသော စာမျက်နှာနံပါတ်များသို့ သွားလာရန် နည်းလမ်းမရှိတော့ဘဲ၊ ယခုဇယားသည် ၎င်းကိုပြသရန်အတွက် မည်မျှရှိနိုင်သည်ကို သိရှိရန်မလိုအပ်တော့ပါ။ သို့သော်မေးခွန်းပေါ်လာသည် - နောက်စာမျက်နှာအတွက်ဒေတာရှိမရှိ (“Next” link ကိုမှန်ကန်စွာပြသရန်အတွက်) ဇယားသည်မည်သို့သိသနည်း။

အဖြေသည် အလွန်ရိုးရှင်းပါသည်- ဖော်ပြရန်အတွက် လိုအပ်သည်ထက် ပိုမိုသော မှတ်တမ်းတစ်ခုကို ဒေတာဘေ့စ်မှ သင်ဖတ်ရှုနိုင်ပြီး၊ ဤ “အပိုဆောင်း” မှတ်တမ်း၏ ပါဝင်မှုသည် နောက်အပိုင်းတစ်ခုရှိမရှိကို ပြသမည်ဖြစ်သည်။ ဤနည်းအားဖြင့်၊ ဒေတာစာမျက်နှာတစ်မျက်နှာကို ရရှိရန် တောင်းဆိုချက်တစ်ခုသာ လုပ်ဆောင်ရန် လိုအပ်ပြီး ၎င်းသည် စွမ်းဆောင်ရည်ကို သိသိသာသာ တိုးတက်စေပြီး ယင်းကဲ့သို့သော လုပ်ဆောင်ချက်များကို ပံ့ပိုးရန် ပိုမိုလွယ်ကူစေသည်။ ကျွန်ုပ်၏လက်တွေ့တွင်၊ စုစုပေါင်းမှတ်တမ်းအရေအတွက်ကိုရေတွက်ရန်ငြင်းဆိုသောအခါရလဒ်များပေးပို့မှုကို 4-5 ကြိမ်မြန်ဆန်စေသည်။

ဤချဉ်းကပ်မှုအတွက် အသုံးပြုသူကြားခံရွေးချယ်စရာအများအပြားရှိသည်- အထက်နမူနာတွင်ကဲ့သို့ "back" နှင့် "forward" commands၊ ပြသထားသောရလဒ်များတွင် အပိုင်းအသစ်တစ်ခုကို ရိုးရိုးရှင်းရှင်းထည့်သွင်းပေးသည့် "load more" ခလုတ်တစ်ခု၊ အလုပ်လုပ်သော "အဆုံးမရှိ scroll"၊ "load more" "၏နိယာမတွင်၊ သို့သော်နောက်အပိုင်းကိုရရှိရန်အချက်ပြမှုသည်အသုံးပြုသူမှပြသထားသောရလဒ်အားလုံးကိုအဆုံးအထိရွှေ့ရန်ဖြစ်သည်။ အမြင်အာရုံဖြေရှင်းနည်း မည်သို့ပင်ဖြစ်စေ ဒေတာနမူနာယူခြင်းနိယာမသည် အတူတူပင်ဖြစ်သည်။

စာမျက်နှာအကောင်အထည်ဖော်ခြင်း၏ ကွဲပြားချက်များ

အထက်ဖော်ပြပါ စုံစမ်းမှုနမူနာများအားလုံးသည် ရလဒ်အတန်းများနှင့် အတန်းမည်မျှပြန်ရရန် လိုအပ်ကြောင်း စုံစမ်းမှုကိုယ်တိုင်က သတ်မှတ်သောအခါတွင် "အော့ဖ်ဆက် + ရေတွက်ခြင်း" ချဉ်းကပ်မှုကို အသုံးပြုသည်။ ပထမဦးစွာ၊ ဤကိစ္စတွင် parameter passing ကိုမည်ကဲ့သို့စုစည်းရန်အကောင်းဆုံးဖြစ်သည်ကိုကြည့်ကြပါစို့။ လက်တွေ့တွင်၊ ကျွန်ုပ်သည် နည်းလမ်းများစွာကို တွေ့ခဲ့ရပါသည်။

• တောင်းဆိုထားသောစာမျက်နှာ (pageIndex)၊ စာမျက်နှာအရွယ်အစား (pageSize) ၏ အမှတ်စဉ်နံပါတ်။
• ပြန်ပေးမည့် ပထမဆုံးမှတ်တမ်း၏ အမှတ်စဉ်နံပါတ် (startIndex)၊ ရလဒ် (ရေတွက်မှု) တွင် အများဆုံး မှတ်တမ်းအရေအတွက်။
• ပြန်ပေးမည့် ပထမမှတ်တမ်း၏ နံပါတ်စဉ် (startIndex)၊ ပြန်ပေးမည့် နောက်ဆုံးမှတ်တမ်း၏ နံပါတ်စဉ် (endIndex)။

ပထမတစ်ချက်တွင်၊ ဤအရာသည် မူလတန်းဖြစ်ပြီး ကွာခြားမှုမရှိဟု ထင်ရပေမည်။ ဒါပေမယ့် ဒါက မဟုတ်ပါဘူး - အဆင်ပြေဆုံးနဲ့ universal option က ဒုတိယ (startIndex၊ count) ဖြစ်ပါတယ်။ ဤအတွက် အကြောင်းရင်းများစွာ ရှိပါသည်။

• အထက်တွင်ဖော်ပြထားသော +1 ဝင်ခွင့်အထောက်အထားဖတ်ခြင်းနည်းလမ်းအတွက်၊ pageIndex နှင့် pageSize ပါသော ပထမရွေးချယ်မှုသည် အလွန်အဆင်မပြေပါ။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် စာမျက်နှာတစ်ခုလျှင် ပို့စ် ၅၀ ကို ပြသလိုပါသည်။ အထက်ဖော်ပြပါ algorithm အရ၊ လိုအပ်သည်ထက် မှတ်တမ်းတစ်ခု ထပ်မံဖတ်ရန် လိုအပ်သည်။ ဤ “+50” ကို ဆာဗာတွင် အကောင်အထည်မဖော်ပါက ပထမစာမျက်နှာအတွက် 1 မှ 1 မှ မှတ်တမ်းများကို ကျွန်ုပ်တို့ တောင်းဆိုရမည်ဖြစ်ပြီး ဒုတိယစာမျက်နှာ - 51 မှ 51 စသည်တို့အတွက် မှတ်တမ်းများကို တောင်းဆိုရမည်ဖြစ်သည်။ စာမျက်နှာ 101 ကို သတ်မှတ်ပြီး စာမျက်နှာအညွှန်းကို တိုးပါက ဒုတိယစာမျက်နှာ 51 မှ 52 သို့ ပြန်သွားပါမည်။ ထို့ကြောင့်၊ ပထမရွေးချယ်မှုတွင်၊ နောက်စာမျက်နှာသို့သွားရန် ခလုတ်တစ်ခုကို မှန်ကန်စွာအကောင်အထည်ဖော်ရန် တစ်ခုတည်းသောနည်းလမ်းမှာ ဆာဗာမှ “အပို” မျဉ်းကြောင်းကို စစ်ကြောရန်ဖြစ်သည်၊၊ အလွန်အကျုံးဝင်သော ကွဲပြားမှုဖြစ်လိမ့်မည်။
• ဒေတာဘေ့စ်အများစုတွင် စုံစမ်းမေးမြန်းမှုများကို လုပ်ဆောင်ရန် တတိယရွေးချယ်မှုမှာ အဓိပ္ပါယ်လုံးဝမရှိပါ၊ အဘယ်ကြောင့်ဆိုသော် သင်သည် နောက်ဆုံးမှတ်တမ်း၏ အညွှန်းကိန်းထက် အရေအတွက်ကို ကျော်သွားရန်လိုအပ်ပါသည်။ endIndex မှ startIndex ကို နုတ်ခြင်းသည် ရိုးရှင်းသော ဂဏန်းသင်္ချာ လုပ်ဆောင်ချက် ဖြစ်ကောင်းဖြစ်နိုင်သော်လည်း ၎င်းသည် ဤနေရာတွင် လွန်စွာ မလိုအပ်ပါ။

ယခုကျွန်ုပ်တို့သည် “offset + quantity” ဖြင့် pageaging ကိုအကောင်အထည်ဖော်ခြင်း၏အားနည်းချက်များကိုဖော်ပြသင့်သည်-

• နောက်ဆက်တွဲစာမျက်နှာတစ်ခုစီကို ပြန်လည်ရယူခြင်းသည် ယခင်စာမျက်နှာထက် ပိုမိုစျေးကြီးပြီး နှေးကွေးမည်ဖြစ်သောကြောင့် ဒေတာဘေ့စ်သည် ရှာဖွေခြင်းနှင့် စီခြင်းသတ်မှတ်ချက်များနှင့်အညီ "အစမှ" မှတ်တမ်းအားလုံးကို "အစမှ" ဖြတ်သန်းရန် လိုအပ်နေသေးသောကြောင့်၊ ထို့နောက် လိုချင်သောအပိုင်းအစတွင် ရပ်သွားမည်ဖြစ်သည်။
• DBMS အားလုံးသည် ဤနည်းလမ်းကို ပံ့ပိုးမပေးနိုင်ပါ။

အခြားရွေးချယ်စရာများ ရှိသော်လည်း ၎င်းတို့သည်လည်း မစုံလင်ပါ။ ဤချဉ်းကပ်နည်းများထဲမှ ပထမဆုံးနည်းလမ်းကို “keyset paging” သို့မဟုတ် “seek method” ဟုခေါ်ပြီး အောက်ပါအတိုင်းဖြစ်သည်- အပိုင်းတစ်ခုကို လက်ခံရရှိပြီးနောက်၊ စာမျက်နှာရှိ နောက်ဆုံးမှတ်တမ်းရှိ နယ်ပယ်တန်ဖိုးများကို သင်မှတ်မိနိုင်ပြီး ရယူရန် ၎င်းတို့ကို အသုံးပြုပါ။ နောက်အပိုင်း။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် အောက်ပါမေးခွန်းကို လုပ်ဆောင်ခဲ့သည်-

SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

နောက်ဆုံးမှတ်တမ်းတွင် ကျွန်ုပ်တို့သည် အမှာစာရက်စွဲတန်ဖိုး '2014-06-29' ကိုရရှိသည်။ ထို့နောက် နောက်စာမျက်နှာကိုရရန် သင်ဤသို့ကြိုးစားနိုင်သည်-

SELECT * FROM Sales.SalesOrderHeader
WHERE OrderDate < '2014-06-29'
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

ပြဿနာမှာ OrderDate သည် သီးသန့်မဟုတ်သော အကွက်ဖြစ်ပြီး အထက်ဖော်ပြပါအခြေအနေသည် လိုအပ်သောအတန်းများစွာကို လွတ်သွားဖွယ်ရှိသည်။ ဤမေးခွန်းအတွက် ရှင်းရှင်းလင်းလင်းမရှိအောင် ထည့်ရန်၊ အခြေအနေတွင် သီးသန့်အကွက်တစ်ခုကို သင်ထည့်ရန်လိုအပ်သည် (75074 သည် ပထမအပိုင်းမှ အဓိကသော့၏ နောက်ဆုံးတန်ဖိုးဖြစ်သည်ဟု ယူဆသည်)။

SELECT * FROM Sales.SalesOrderHeader
WHERE (OrderDate = '2014-06-29' AND SalesOrderID < 75074)
   OR (OrderDate < '2014-06-29')
ORDER BY OrderDate DESC, SalesOrderID DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

ဤရွေးချယ်မှုသည် မှန်ကန်စွာအလုပ်လုပ်နိုင်သော်လည်း အခြေအနေတွင် OR အော်ပရေတာတစ်ခုပါရှိသည်ဖြစ်သောကြောင့် ယေဘုယျအားဖြင့် ၎င်းသည် အကောင်းဆုံးဖြစ်အောင်ပြုလုပ်ရန် ခက်ခဲပါလိမ့်မည်။ OrderDate တိုးလာသည်နှင့်အမျှ ပင်မသော့တန်ဖိုး တိုးလာပါက၊ SalesOrderID မှ စစ်ထုတ်မှုတစ်ခုသာ ချန်ထားခြင်းဖြင့် အခြေအနေ ရိုးရှင်းနိုင်ပါသည်။ သို့သော် ရလဒ်ကို စီစဥ်ထားသည့် အကွက်များ၏ တန်ဖိုးများနှင့် ပင်မသော့တန်ဖိုးများကြား တင်းကျပ်သော ဆက်စပ်မှုမရှိပါက၊ ဤ OR ကို DBMS အများစုတွင် ရှောင်ရှား၍မရပါ။ ကျွန်တော်သိသော ခြွင်းချက်မှာ Tuple နှိုင်းယှဉ်မှုများကို အပြည့်အဝထောက်ခံသည့် PostgreSQL ဖြစ်ပြီး အထက်ပါအခြေအနေအား "WHERE (OrderDate, SalesOrderID) < ('2014-06-29', 75074)" ဟု ရေးသားနိုင်ပါသည်။ ဤအကွက်နှစ်ခုပါသော ပေါင်းစပ်သော့ကို ပေးထားသည့်အတွက်၊ ဤကဲ့သို့သော မေးမြန်းချက်သည် အတော်လေး လွယ်ကူသင့်သည်။

ဥပမာ၊ တွင်၊ ဒုတိယနည်းကို ရှာနိုင်သည်။ ElasticSearch scroll API သို့မဟုတ် Cosmos DB — တောင်းဆိုမှုတစ်ခုသည် ဒေတာအပြင် သင်ဒေတာ၏နောက်အပိုင်းကိုရနိုင်သည့် အထူးသတ်မှတ်သူအား ပြန်ပေးသည်။ အကယ်၍ ဤသတ်မှတ်သူသည် အကန့်အသတ်မရှိသော သက်တမ်းတစ်ခု (Comsos DB တွင်ကဲ့သို့) ရှိပါက၊ ၎င်းသည် စာမျက်နှာများအကြား ဆက်တိုက်အကူးအပြောင်းဖြင့် စာမျက်နှာများကို အကောင်အထည်ဖော်ရန် နည်းလမ်းကောင်းတစ်ခုဖြစ်သည် (အထက်ဖော်ပြပါ ရွေးချယ်မှု #2)။ ၎င်း၏ဖြစ်နိုင်သောအားနည်းချက်များ- DBMSs အားလုံးတွင် ပံ့ပိုးမထားပါ။ ထွက်ပေါ်လာသော နောက်အပိုင်းအမှတ်အသားသည် အကန့်အသတ်ရှိသော သက်တမ်းရှိနိုင်သည်၊ ၎င်းသည် ယေဘုယျအားဖြင့် အသုံးပြုသူ အပြန်အလှန်တုံ့ပြန်မှုအတွက် မသင့်လျော်ပါ (ElasticSearch scroll API ကဲ့သို့သော)။

ရှုပ်ထွေးသောစစ်ထုတ်ခြင်း။

လုပ်ငန်းကို ရှုပ်ထွေးအောင် လုပ်ကြရအောင်။ အွန်လိုင်းစတိုးများမှလူတိုင်းနှင့်အလွန်ရင်းနှီးသော faceted search ဟုခေါ်တွင်အကောင်အထည်ဖော်ရန်လိုအပ်သည်ဆိုပါစို့။ အမှာစာဇယားအပေါ်အခြေခံထားသော အထက်ဖော်ပြပါ ဥပမာများသည် ဤကိစ္စတွင် သရုပ်ဖော်ပုံသိပ်မလှပါ၊ ထို့ကြောင့် AdventureWorks ဒေတာဘေ့စ်မှ ထုတ်ကုန်ဇယားသို့ ပြောင်းကြည့်ကြပါစို့။

မျက်နှာချင်းဆိုင်ရှာဖွေမှုနောက်ကွယ်က အယူအဆကဘာလဲ။ အမှန်မှာ စစ်ထုတ်သည့်ဒြပ်စင်တစ်ခုစီအတွက် ဤစံသတ်မှတ်ချက်များနှင့် ကိုက်ညီသော မှတ်တမ်းအရေအတွက်ကို ပြသထားသည်။ အခြားအမျိုးအစားအားလုံးတွင် ရွေးချယ်ထားသော စစ်ထုတ်မှုများကို ထည့်သွင်းစဉ်းစားပါ။.

ဥပမာအားဖြင့်၊ ဤဥပမာရှိ စက်ဘီးအမျိုးအစားနှင့် အရောင်အနက်ရောင်ကို ရွေးချယ်ပါက၊ ဇယားသည် အနက်ရောင်စက်ဘီးများကိုသာ ပြသမည်ဖြစ်သော်လည်း၊

• အမျိုးအစားအုပ်စုရှိ စံသတ်မှတ်ချက်တစ်ခုစီအတွက်၊ ထိုအမျိုးအစားမှ ထုတ်ကုန်အရေအတွက်ကို အနက်ရောင်ဖြင့် ပြသပါမည်။
• "အရောင်များ" အဖွဲ့၏ စံသတ်မှတ်ချက်တစ်ခုစီအတွက်၊ ဤအရောင်၏ စက်ဘီးအရေအတွက်ကို ပြသပါမည်။

ဤသည်မှာ ထိုသို့သောအခြေအနေများအတွက် ရလဒ်ရလဒ်၏ ဥပမာတစ်ခုဖြစ်သည်။

“အဝတ်အစား” အမျိုးအစားကိုလည်း စစ်ဆေးပါက၊ စားပွဲတွင် လက်ကျန်ရှိနေသည့် အနက်ရောင်အဝတ်အစားများကိုလည်း ပြသမည်ဖြစ်သည်။ "အရောင်" ကဏ္ဍရှိ အနက်ရောင်ထုတ်ကုန်အရေအတွက်ကိုလည်း အခြေအနေအသစ်အရ ပြန်လည်တွက်ချက်မည်ဖြစ်ပြီး၊ "အမျိုးအစားများ" ကဏ္ဍတွင်သာ ပြောင်းလဲမည်မဟုတ်ပါ... ဤဥပမာများသည် ပုံမှန်မျက်နှာသွင်ပြင်ရှာဖွေမှု algorithm ကို နားလည်ရန် လုံလောက်မည်ဟု မျှော်လင့်ပါသည်။

အခု ဒီဟာကို ဆက်စပ်အခြေခံပေါ်မှာ ဘယ်လိုအကောင်အထည်ဖော်နိုင်မလဲဆိုတာ တွေးကြည့်ရအောင်။ အမျိုးအစားနှင့် အရောင်ကဲ့သို့သော စံအုပ်စုတစ်ခုစီသည် သီးခြားမေးမြန်းမှုတစ်ခု လိုအပ်ပါမည်-

SELECT pc.ProductCategoryID, pc.Name, COUNT(1) FROM Production.Product p
  INNER JOIN Production.ProductSubcategory ps ON p.ProductSubcategoryID = ps.ProductSubcategoryID
  INNER JOIN Production.ProductCategory pc ON ps.ProductCategoryID = pc.ProductCategoryID
WHERE p.Color = 'Black'
GROUP BY pc.ProductCategoryID, pc.Name
ORDER BY COUNT(1) DESC

SELECT Color, COUNT(1) FROM Production.Product p
  INNER JOIN Production.ProductSubcategory ps ON p.ProductSubcategoryID = ps.ProductSubcategoryID
WHERE ps.ProductCategoryID = 1 --Bikes
GROUP BY Color
ORDER BY COUNT(1) DESC

ဒီဖြေရှင်းချက်က ဘာမှားနေလဲ။ အလွန်ရိုးရှင်းပါသည် - ကောင်းစွာမတိုင်းတာပါ။ စစ်ထုတ်မှုအပိုင်းတစ်ခုစီတိုင်းသည် ပမာဏများကိုတွက်ချက်ရန် သီးခြားမေးမြန်းချက်တစ်ခု လိုအပ်ပြီး ဤမေးခွန်းများသည် အလွယ်ကူဆုံးမဟုတ်ပါ။ အွန်လိုင်းစတိုးများတွင်၊ အချို့သောအမျိုးအစားများသည် ပြင်းထန်သောစွမ်းဆောင်ရည်ပြဿနာတစ်ခုဖြစ်နိုင်သည့် ဒါဇင်များစွာသော စစ်ထုတ်မှုအပိုင်းများပါရှိသည်။

အများအားဖြင့် ဤဖော်ပြချက်များပြီးနောက် ကျွန်ုပ်အား ဖြေရှင်းချက်အချို့ကို ကမ်းလှမ်းခဲ့သည်၊ ဆိုလိုသည်မှာ-

• အရေအတွက်အားလုံးကို query တစ်ခုတွင် ပေါင်းစပ်ပါ။ နည်းပညာအရ ၎င်းသည် UNION သော့ချက်စာလုံးကို အသုံးပြု၍ ဖြစ်နိုင်သော်လည်း ၎င်းသည် စွမ်းဆောင်နိုင်မှုကို များစွာအထောက်အကူမပြုနိုင် - ဒေတာဘေ့စ်သည် အပိုင်းအစတစ်ခုစီကို အစမှအဆုံးအထိ လုပ်ဆောင်ရန် ကျန်ရှိနေမည်ဖြစ်သည်။
• Cache ပမာဏများ။ ပြဿနာတစ်ခုကို ဖော်ပြတိုင်းလိုလို ဒါကို အကြံပြုထားပါတယ်။ သတိပေးချက်ကတော့ ဒါက ယေဘုယျအားဖြင့် မဖြစ်နိုင်ပါဘူး။ ကျွန်ုပ်တို့တွင် 10 "မျက်နှာ" ရှိသည်ဆိုပါစို့၊ တစ်ခုစီတွင် တန်ဖိုး 5 ခုရှိသည်။ ဤသည်မှာ တူညီသောအွန်လိုင်းစတိုးများတွင် မြင်တွေ့နိုင်သည့်အရာများနှင့် နှိုင်းယှဉ်ပါက အလွန် "ကျိုးနွံသော" အခြေအနေဖြစ်သည်။ အသွင်အပြင်တစ်ခုစီ၏ ရွေးချယ်မှုသည် အခြား ၉ ပါးရှိ ပမာဏများအပေါ် သက်ရောက်သည်၊ တစ်နည်းအားဖြင့် သတ်မှတ်ချက်တစ်ခုစီအတွက် ပမာဏသည် ကွဲပြားနိုင်သည်။ ကျွန်ုပ်တို့၏နမူနာတွင်၊ အသုံးပြုသူရွေးချယ်နိုင်သော စံသတ်မှတ်ချက် စုစုပေါင်း 9 ရှိပြီး၊ ထို့ကြောင့် ဖြစ်နိုင်ချေ ပေါင်းစပ်မှုများ 50 ရှိပါမည်။ ထိုကဲ့သို့သော ဒေတာခင်းကျင်းမှုကို ဖြည့်ရန် လုံလောက်သော memory သို့မဟုတ် အချိန်မရှိပါ။ ဤနေရာတွင် သင်ကန့်ကွက်နိုင်ပြီး ပေါင်းစပ်မှုအားလုံးသည် အစစ်အမှန်မဟုတ်ကြောင်းနှင့် အသုံးပြုသူသည် စံသတ်မှတ်ချက် 250-5 ထက်ပို၍ ရွေးချယ်ခဲပါသည်။ ဟုတ်ကဲ့၊ ရွေးထားဖူးတဲ့ ပမာဏကိုသာ ပျင်းရိစွာ တင်ပြီး ကက်ရှ်လုပ်လို့ ရပါတယ်၊ ဒါပေမယ့် ရွေးချယ်မှုတွေ များလေလေ၊ ဒီလို ကက်ရှ်ဟာ ထိရောက်မှု နည်းလေလေ၊ တုံ့ပြန်မှု အချိန်ပြဿ နာတွေ ပိုသိသာလေလေ (အထူးသဖြင့် ဆိုရင်၊ ဒေတာအစုံကို ပုံမှန်ပြောင်းလဲခြင်း)။

ကံကောင်းထောက်မစွာ၊ ထိုပြဿနာသည် ဒေတာပမာဏအများအပြားတွင် ကြိုတင်မှန်းဆနိုင်သော ထိရောက်သော ဖြေရှင်းနည်းများ ရှိခဲ့သည်မှာ ကြာပါပြီ။ ဤရွေးချယ်စရာများထဲမှတစ်ခုအတွက်၊ မျက်နှာစာ၏ပြန်လည်တွက်ချက်မှုနှင့်ရလဒ်များကိုလက်ခံခြင်းစာမျက်နှာကိုဆာဗာသို့အပြိုင်ခေါ်ဆိုမှုနှစ်ခုအဖြစ်အသွင်ပြောင်းပြီး data များကို facets ဖြင့်တင်ခြင်းအား "အနှောင့်အယှက်မပေး" သည့်ပုံစံဖြင့်အသုံးပြုသူမျက်နှာပြင်ကိုစုစည်းရန်၎င်းသည်သဘောပေါက်သည်။ ရှာဖွေမှုရလဒ်များ။

• တတ်နိုင်သမျှ ရှားရှားပါးပါး "မျက်နှာ" ၏ ပြီးပြည့်စုံသော တွက်ချက်မှုကို ခေါ်ဆိုပါ။ ဥပမာအားဖြင့်၊ ရှာဖွေမှုစံနှုန်းများ ပြောင်းလဲသည့်အခါတိုင်း အရာအားလုံးကို ပြန်လည်တွက်ချက်ခြင်းမပြုပါနှင့်၊ သို့သော် လက်ရှိအခြေအနေများနှင့် ကိုက်ညီသည့် စုစုပေါင်းရလဒ်များကို ရှာဖွေပြီး ၎င်းတို့အား ပြသရန် သုံးစွဲသူအား နှိုးဆော်ခြင်း - "1425 မှတ်တမ်းများ တွေ့ရှိ၊ ပြမည်" အသုံးပြုသူသည် ရှာဖွေမှုအသုံးအနှုန်းများကို ဆက်လက်ပြောင်းလဲနိုင်သည် သို့မဟုတ် “ပြသရန်” ခလုတ်ကို နှိပ်နိုင်သည်။ ဒုတိယကိစ္စတွင်သာ ရလဒ်များရယူခြင်းနှင့် "မျက်နှာစာများ" အားလုံးရှိ ပမာဏများကို ပြန်လည်တွက်ချက်ခြင်းအတွက် တောင်းဆိုမှုအားလုံးကို လုပ်ဆောင်မည်ဖြစ်သည်။ ဤကိစ္စတွင်၊ သင်အလွယ်တကူမြင်နိုင်သကဲ့သို့၊ စုစုပေါင်းရလဒ်များနှင့်၎င်း၏အကောင်းဆုံးဖြစ်အောင်ပြုလုပ်ရန်တောင်းဆိုမှုတစ်ခုနှင့်သင်ဖြေရှင်းရလိမ့်မည်။ ဤနည်းလမ်းကို အွန်လိုင်းစတိုးငယ်များစွာတွင် တွေ့နိုင်သည်။ သိသာထင်ရှားသည်၊ ဤသည်ဤပြဿနာအတွက် panacea မဟုတ်ပါ၊ သို့သော်ရိုးရှင်းသောကိစ္စများတွင်၎င်းသည်ကောင်းမွန်သောအပေးအယူတစ်ခုဖြစ်သည်။
• Solr၊ ElasticSearch၊ Sphinx နှင့် အခြားအရာများကဲ့သို့သော မျက်နှာစာများကို ရေတွက်ရန် ရှာဖွေရေးအင်ဂျင်များကို အသုံးပြုပါ။ ၎င်းတို့အားလုံးသည် "အသွင်အပြင်များ" ကိုတည်ဆောက်ရန် ဒီဇိုင်းထုတ်ထားပြီး ပြောင်းပြန်အညွှန်းကိန်းကြောင့် ၎င်းကို ထိရောက်စွာလုပ်ဆောင်သည်။ ရှာဖွေရေးအင်ဂျင်များ အလုပ်လုပ်ပုံ၊ ထိုသို့သောကိစ္စများတွင် ၎င်းတို့သည် ယေဘူယျရည်ရွယ်ချက် ဒေတာဘေ့စ်များထက် အဘယ်ကြောင့် ပိုမိုထိရောက်သနည်း၊ မည်သို့သော အလေ့အကျင့်များနှင့် ချွတ်ယွင်းချက်များ ရှိနေသနည်း - ဤသည် သီးခြားဆောင်းပါးအတွက် ခေါင်းစဉ်ဖြစ်သည်။ ဤနေရာတွင် ကျွန်ုပ်သည် ရှာဖွေရေးအင်ဂျင်သည် ပင်မဒေတာသိုလှောင်မှုအတွက် အစားထိုးမရနိုင်သည့်အချက်ကို အာရုံစိုက်စေလိုသည်၊ ၎င်းကို ထပ်လောင်းအဖြစ်အသုံးပြုသည်- ရှာဖွေမှုအတွက်သက်ဆိုင်သည့် ပင်မဒေတာဘေ့စ်ရှိ မည်သည့်ပြောင်းလဲမှုမဆို ရှာဖွေရေးအညွှန်းသို့ ထပ်တူပြုပါသည်။ ရှာဖွေရေးအင်ဂျင်သည် များသောအားဖြင့် ရှာဖွေရေးအင်ဂျင်နှင့်သာ အပြန်အလှန် အကျိုးသက်ရောက်ပြီး ပင်မဒေတာဘေ့စ်ကို မဝင်ရောက်နိုင်ပေ။ ဤနေရာတွင် အရေးကြီးဆုံးအချက်တစ်ခုမှာ ဤထပ်တူကူးမှုကို ယုံကြည်စိတ်ချစွာ စုစည်းပုံဖြစ်သည်။ ၎င်းသည် "တုံ့ပြန်မှုအချိန်" လိုအပ်ချက်များပေါ်တွင်မူတည်သည်။ ပင်မဒေတာဘေ့စ်တွင် အပြောင်းအလဲတစ်ခုနှင့် ရှာဖွေမှုတွင် ၎င်း၏ "ပေါ်လွင်ခြင်း" ကြားအချိန်သည် မစိုးရိမ်ရပါက၊ သင်သည် မကြာသေးမီက ပြောင်းလဲထားသောမှတ်တမ်းများကို မိနစ်အနည်းငယ်တိုင်း ရှာဖွေနိုင်ပြီး ၎င်းတို့ကို အညွှန်းပေးသည့် ဝန်ဆောင်မှုတစ်ခုကို ဖန်တီးနိုင်သည်။ ဖြစ်နိုင်ချေ အတိုဆုံး တုံ့ပြန်မှုအချိန်ကို လိုချင်ရင်၊ တစ်ခုခုကို အကောင်အထည်ဖော်နိုင်ပါတယ်။ အရောင်းအ၀ယ်ထွက်ပုံး ရှာဖွေရေးဝန်ဆောင်မှုသို့ အပ်ဒိတ်များ ပေးပို့ရန်။

တွေ့ရှိချက်များ

1. server-side pageaging ကို အကောင်အထည်ဖော်ခြင်းသည် သိသာထင်ရှားသော နောက်ဆက်တွဲပြဿနာဖြစ်ပြီး လျင်မြန်စွာ ကြီးထွားနေသော သို့မဟုတ် ရိုးရှင်းသော ကြီးမားသော ဒေတာအတွဲများအတွက်သာ အဓိပ္ပာယ်ရှိပါသည်။ "ကြီးမားသော" သို့မဟုတ် "ကြီးထွားမှုမြန်သည်" ကိုအကဲဖြတ်နည်းအတွက် တိကျသော စာရွက်မရှိသော်လည်း၊ ဤနည်းလမ်းကို ကျွန်ုပ်လိုက်နာပါမည်-
   • ဆာဗာအချိန်နှင့် ကွန်ရက်ထုတ်လွှင့်ခြင်းတို့ကို ထည့်သွင်းစဉ်းစားပြီး ဒေတာစုဆောင်းမှု အပြည့်အစုံကို လက်ခံရရှိပါက ပုံမှန်အတိုင်း စွမ်းဆောင်ရည်လိုအပ်ချက်များနှင့် ကိုက်ညီပါက၊ ဆာဗာဘက်တွင် စာမျက်နှာကို အကောင်အထည်ဖော်ရာတွင် မည်သည့်အချက်မှ မရှိပါ။
   • ဒေတာအနည်းငယ်သာရှိသောကြောင့် မဝေးတော့သောအနာဂတ်တွင် စွမ်းဆောင်ရည်ပြဿနာများ မမျှော်မှန်းနိုင်သည့်အခြေအနေရှိနိုင်သော်လည်း ဒေတာစုဆောင်းမှုသည် အဆက်မပြတ်ကြီးထွားလျက်ရှိသည်။ အနာဂတ်တွင် အချို့သော ဒေတာအစုများသည် ယခင်အချက်ကို ကျေနပ်မှုမရှိတော့ပါက၊ စာမျက်နှာကို ချက်ချင်းစတင်ရန် ပိုမိုကောင်းမွန်ပါသည်။
2. စုစုပေါင်းရလဒ်များကိုပြသရန် သို့မဟုတ် စာမျက်နှာနံပါတ်များကိုပြသရန် စီးပွားရေးလုပ်ငန်း၏ တင်းကျပ်သောလိုအပ်ချက်မရှိပါက၊ သင့်စနစ်တွင် ရှာဖွေရေးအင်ဂျင်မရှိပါက၊ ဤအချက်များကို အကောင်အထည်မဖော်ဘဲ ရွေးချယ်စရာနံပါတ် 2 ကို ထည့်သွင်းစဉ်းစားခြင်းက ပိုကောင်းပါတယ်။
3. မျက်နှာချင်းဆိုင်ရှာဖွေမှုအတွက် ရှင်းရှင်းလင်းလင်း လိုအပ်ချက်ရှိပါက၊ စွမ်းဆောင်ရည်ကို မထိခိုက်စေဘဲ သင့်တွင် ရွေးချယ်စရာ နှစ်ခုရှိသည်။
   • ရှာဖွေမှုစံနှုန်းများ ပြောင်းလဲသည့်အခါတိုင်း ပမာဏအားလုံးကို ပြန်မတွက်ပါနှင့်။
   • Solr၊ ElasticSearch၊ Sphinx နှင့် အခြားရှာဖွေရေးအင်ဂျင်များကို အသုံးပြုပါ။ သို့သော် ၎င်းသည် ပင်မဒေတာဘေ့စ်အတွက် အစားထိုးမရနိုင်ကြောင်း နားလည်ထားသင့်ပြီး ရှာဖွေမှုပြဿနာများကို ဖြေရှင်းရန်အတွက် ပင်မသိုလှောင်မှုအပြင် အသုံးပြုသင့်သည်။
4. ထို့အပြင်၊ မျက်နှာချင်းဆိုင်ရှာဖွေမှုကိစ္စတွင်၊ ရှာဖွေမှုရလဒ်စာမျက်နှာကို ပြန်လည်ရယူခြင်းနှင့် ရေတွက်ခြင်းတို့ကို အပြိုင်တောင်းဆိုမှုနှစ်ခုအဖြစ် ပိုင်းခြားရန် အဓိပ္ပာယ်ရှိပါသည်။ ရလဒ်များကို အသုံးပြုသူအတွက် ပိုအရေးကြီးသော်လည်း ရလဒ်များရရှိရန် ပမာဏများကို ရေတွက်ခြင်းထက် ပိုကြာနိုင်ပါသည်။
5. သင်ရှာဖွေရန်အတွက် SQL ဒေတာဘေ့စ်ကို အသုံးပြုနေပါက၊ ဤအပိုင်းနှင့်သက်ဆိုင်သည့် ကုဒ်ပြောင်းလဲမှုမှန်သမျှကို သင့်လျော်သောဒေတာပမာဏ (တိုက်ရိုက်ထုတ်လွှဒေတာဘေ့စ်တွင် ပမာဏထက်ကျော်လွန်) စွမ်းဆောင်ရည်အတွက် ကောင်းမွန်စွာစမ်းသပ်သင့်သည်။ ဒေတာဘေ့စ်၏ဖြစ်ရပ်အားလုံးနှင့် အထူးသဖြင့် "တိုက်ရိုက်" တစ်ခုပေါ်တွင် query execution time ကို စောင့်ကြည့်ရန်လည်း အကြံပြုလိုပါသည်။ ဒေတာပမာဏ တိုးလာသည်နှင့်အမျှ မေးမြန်းမှုအစီအစဉ်များသည် ဖွံ့ဖြိုးတိုးတက်ရေးအဆင့်တွင် အားလုံးအဆင်ပြေသော်လည်း၊ အခြေအနေမှာ သိသာစွာ ပြောင်းလဲသွားနိုင်ပါသည်။

source: www.habr.com