ຜົນໄດ້ຮັບຄົ້ນຫາແລະບັນຫາການປະຕິບັດ

ຫນຶ່ງໃນສະຖານະການປົກກະຕິໃນທຸກຄໍາຮ້ອງສະຫມັກທີ່ພວກເຮົາຄຸ້ນເຄີຍກັບແມ່ນການຊອກຫາຂໍ້ມູນຕາມເງື່ອນໄຂທີ່ແນ່ນອນແລະສະແດງມັນໃນຮູບແບບທີ່ງ່າຍຕໍ່ການອ່ານ. ອາດຈະມີທາງເລືອກເພີ່ມເຕີມສໍາລັບການຈັດຮຽງ, ການຈັດກຸ່ມ, ແລະການຈັດຫນ້າ. ວຽກງານແມ່ນ, ໃນທາງທິດສະດີ, trivial, ແຕ່ເມື່ອແກ້ໄຂມັນ, ນັກພັດທະນາຈໍານວນຫຼາຍເຮັດຜິດພາດຈໍານວນຫນຶ່ງ, ເຊິ່ງຕໍ່ມາເຮັດໃຫ້ຜົນຜະລິດເສຍຫາຍ. ໃຫ້ພະຍາຍາມພິຈາລະນາທາງເລືອກຕ່າງໆສໍາລັບການແກ້ໄຂບັນຫານີ້ແລະສ້າງຄໍາແນະນໍາສໍາລັບການເລືອກການປະຕິບັດທີ່ມີປະສິດທິພາບທີ່ສຸດ.

ທາງ​ເລືອກ​ຂອງ​ຫນ້າ #1​

ທາງເລືອກທີ່ງ່າຍດາຍທີ່ສຸດທີ່ເຂົ້າມາໃນໃຈແມ່ນການສະແດງຜົນການຄົ້ນຫາແບບຫນ້າຕໍ່ຫນ້າໃນຮູບແບບຄລາສສິກທີ່ສຸດ.

ໃຫ້ເວົ້າວ່າຄໍາຮ້ອງສະຫມັກຂອງທ່ານໃຊ້ຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງ. ໃນກໍລະນີນີ້, ເພື່ອສະແດງຂໍ້ມູນໃນຮູບແບບນີ້, ທ່ານຈະຕ້ອງດໍາເນີນການສອງຄໍາຖາມ SQL:

• ເອົາແຖວສຳລັບໜ້າປັດຈຸບັນ.
• ຄິດໄລ່ຈໍານວນເສັ້ນທັງຫມົດທີ່ສອດຄ່ອງກັບເງື່ອນໄຂການຊອກຫາ - ນີ້ແມ່ນຈໍາເປັນເພື່ອສະແດງຫນ້າ.

ໃຫ້ເບິ່ງຄໍາຖາມທໍາອິດໂດຍໃຊ້ຖານຂໍ້ມູນ MS SQL ທົດສອບເປັນຕົວຢ່າງ AdventureWorks ສໍາລັບເຊີຟເວີ 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.

ທ່ານ​ສາ​ມາດ​ໄດ້​ຮັບ​ສະ​ຖິ​ຕິ I/O ສໍາ​ລັບ​ການ​ສອບ​ຖາມ​ແຕ່​ລະ​ຄົນ​ໂດຍ​ການ​ແລ່ນ​ຄໍາ​ສັ່ງ SET STATISTICS IO ON ໃນ​ໄລ​ຍະ​ການ​ສອບ​ຖາມ​.

ດັ່ງທີ່ທ່ານສາມາດເບິ່ງໄດ້ຈາກແຜນການປະຕິບັດ, ທາງເລືອກທີ່ມີຊັບພະຍາກອນຫຼາຍທີ່ສຸດແມ່ນການຈັດລຽງແຖວທັງຫມົດຂອງຕາຕະລາງແຫຼ່ງໂດຍວັນທີເພີ່ມ. ແລະບັນຫາແມ່ນວ່າແຖວຫຼາຍປາກົດຢູ່ໃນຕາຕະລາງ, "ຍາກ" ການຈັດລຽງຈະເປັນໄປໄດ້. ໃນທາງປະຕິບັດ, ສະຖານະການດັ່ງກ່າວຄວນໄດ້ຮັບການຫຼີກເວັ້ນ, ດັ່ງນັ້ນໃຫ້ພວກເຮົາເພີ່ມດັດສະນີໃນວັນທີຂອງການເພີ່ມແລະເບິ່ງວ່າການບໍລິໂພກຊັບພະຍາກອນມີການປ່ຽນແປງ:

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 ບໍ່ໄດ້ຢູ່ໃນຕໍາແຫນ່ງທໍາອິດ, ດັ່ງນັ້ນການສອບຖາມບໍ່ສາມາດໃຊ້ມັນໄດ້. ບັນຫາໄດ້ຖືກແກ້ໄຂໂດຍການເພີ່ມດັດສະນີອື່ນໃນພາກສະຫນາມ SubTotal, ແລະດັ່ງນັ້ນມັນໃຫ້ພຽງແຕ່ 48 ເຫດຜົນອ່ານ.

ທ່ານສາມາດໃຫ້ຕົວຢ່າງເພີ່ມເຕີມຈໍານວນຫນ້ອຍຂອງການຮ້ອງຂໍສໍາລັບການນັບປະລິມານ, ແຕ່ໂດຍເນື້ອແທ້ແລ້ວຍັງຄົງຄືກັນ: ການໄດ້ຮັບຂໍ້ມູນຫນຶ່ງແລະການນັບຈໍານວນທັງຫມົດແມ່ນສອງຄໍາຮ້ອງຂໍທີ່ແຕກຕ່າງກັນໂດຍພື້ນຖານ, ແລະແຕ່ລະຄົນຮຽກຮ້ອງໃຫ້ມີມາດຕະການຂອງຕົນເອງສໍາລັບການເພີ່ມປະສິດທິພາບ. ໂດຍທົ່ວໄປແລ້ວ, ທ່ານຈະບໍ່ສາມາດຊອກຫາການປະສົມປະສານຂອງດັດສະນີທີ່ເຮັດວຽກເທົ່າທຽມກັນສໍາລັບທັງສອງຄໍາຖາມ.

ດັ່ງນັ້ນ, ຫນຶ່ງໃນຄວາມຕ້ອງການທີ່ສໍາຄັນທີ່ຄວນຈະມີຄວາມກະຈ່າງແຈ້ງໃນເວລາທີ່ການພັດທະນາການແກ້ໄຂການຄົ້ນຫາດັ່ງກ່າວແມ່ນວ່າມັນເປັນສິ່ງສໍາຄັນແທ້ໆສໍາລັບທຸລະກິດທີ່ຈະເຫັນຈໍານວນທັງຫມົດຂອງວັດຖຸທີ່ພົບເຫັນ. ມັນມັກຈະເກີດຂື້ນວ່າບໍ່ມີ. ແລະການນໍາທາງໂດຍຕົວເລກຫນ້າສະເພາະ, ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ແມ່ນການແກ້ໄຂທີ່ມີຂອບເຂດແຄບຫຼາຍ, ນັບຕັ້ງແຕ່ສະຖານະການຫນ້າເວັບສ່ວນໃຫຍ່ເບິ່ງຄືວ່າ "ໄປຫາຫນ້າຕໍ່ໄປ."

ທາງ​ເລືອກ​ຂອງ​ຫນ້າ #2​

ໃຫ້ສົມມຸດວ່າຜູ້ໃຊ້ບໍ່ສົນໃຈທີ່ຈະຮູ້ຈໍານວນທັງຫມົດຂອງວັດຖຸທີ່ພົບເຫັນ. ໃຫ້ພະຍາຍາມເຮັດໃຫ້ຫນ້າຄົ້ນຫາງ່າຍຂຶ້ນ:

ໃນຄວາມເປັນຈິງ, ສິ່ງດຽວທີ່ມີການປ່ຽນແປງແມ່ນວ່າບໍ່ມີວິທີທີ່ຈະໄປຫາຕົວເລກຫນ້າສະເພາະ, ແລະໃນປັດຈຸບັນຕາຕະລາງນີ້ບໍ່ຈໍາເປັນຕ້ອງຮູ້ວ່າມີຈໍານວນເທົ່າໃດເພື່ອສະແດງມັນ. ແຕ່ຄໍາຖາມທີ່ເກີດຂື້ນ - ຕາຕະລາງຮູ້ໄດ້ແນວໃດວ່າມີຂໍ້ມູນສໍາລັບຫນ້າຕໍ່ໄປ (ເພື່ອສະແດງການເຊື່ອມຕໍ່ "ຕໍ່ໄປ" ຢ່າງຖືກຕ້ອງ)?

ຄໍາຕອບແມ່ນງ່າຍດາຍຫຼາຍ: ທ່ານສາມາດອ່ານຈາກຖານຂໍ້ມູນຫນຶ່ງບັນທຶກຫຼາຍກ່ວາທີ່ຈໍາເປັນສໍາລັບການສະແດງ, ແລະການປະກົດຕົວຂອງບັນທຶກ "ເພີ່ມເຕີມ" ນີ້ຈະສະແດງໃຫ້ເຫັນວ່າມີສ່ວນຕໍ່ໄປຫຼືບໍ່. ວິທີນີ້, ທ່ານພຽງແຕ່ຕ້ອງການດໍາເນີນການຫນຶ່ງຄໍາຮ້ອງຂໍເພື່ອໃຫ້ໄດ້ຫນຶ່ງຫນ້າຂອງຂໍ້ມູນ, ເຊິ່ງປັບປຸງປະສິດທິພາບຢ່າງຫຼວງຫຼາຍແລະເຮັດໃຫ້ມັນງ່າຍຕໍ່ການສະຫນັບສະຫນູນການເຮັດວຽກດັ່ງກ່າວ. ໃນການປະຕິບັດຂອງຂ້ອຍ, ມີກໍລະນີທີ່ປະຕິເສດການນັບຈໍານວນບັນທຶກທັງຫມົດເລັ່ງການສົ່ງຜົນໄດ້ຮັບ 4-5 ເທື່ອ.

ມີຫລາຍທາງເລືອກໃນການໂຕ້ຕອບຜູ້ໃຊ້ສໍາລັບວິທີການນີ້: ຄໍາສັ່ງ "ກັບຄືນ" ແລະ "ສົ່ງຕໍ່", ເຊັ່ນດຽວກັບຕົວຢ່າງຂ້າງເທິງ, ປຸ່ມ "ໂຫຼດຫຼາຍ", ເຊິ່ງພຽງແຕ່ເພີ່ມສ່ວນໃຫມ່ໃຫ້ກັບຜົນໄດ້ຮັບທີ່ສະແດງ, "ເລື່ອນບໍ່ມີຂອບເຂດ", ເຊິ່ງເຮັດວຽກ. ໃນຫຼັກການຂອງ "ໂຫຼດຫຼາຍ" ", ແຕ່ສັນຍານທີ່ຈະໄດ້ຮັບສ່ວນຕໍ່ໄປແມ່ນສໍາລັບຜູ້ໃຊ້ທີ່ຈະເລື່ອນຜົນໄດ້ຮັບທີ່ສະແດງທັງຫມົດຈົນເຖິງທີ່ສຸດ. ບໍ່ວ່າວິທີການແກ້ໄຂສາຍຕາ, ຫຼັກການຂອງການເກັບຕົວຢ່າງຂໍ້ມູນຍັງຄົງຄືກັນ.

nuances ຂອງການປະຕິບັດຫນ້າ

ຕົວຢ່າງການສອບຖາມທັງໝົດທີ່ກ່າວມາຂ້າງເທິງນີ້ໃຊ້ວິທີການ “ຊົດເຊີຍ + ນັບ”, ເມື່ອການສອບຖາມຕົວມັນເອງໄດ້ລະບຸວ່າລຳດັບແຖວຜົນໄດ້ຮັບ ແລະຈຳນວນແຖວທີ່ຕ້ອງການສົ່ງຄືນ. ທໍາອິດ, ໃຫ້ເບິ່ງວິທີການທີ່ດີທີ່ສຸດໃນການຈັດລະບຽບ passing parameter ໃນກໍລະນີນີ້. ໃນທາງປະຕິບັດ, ຂ້າພະເຈົ້າໄດ້ພົບຫຼາຍວິທີການ:

• ເລກລໍາດັບຂອງຫນ້າທີ່ຮ້ອງຂໍ (pageIndex), ຂະຫນາດຫນ້າ (pageSize).
• ເລກລໍາດັບຂອງບັນທຶກທໍາອິດທີ່ຈະຖືກສົ່ງຄືນ (startIndex), ຈໍານວນສູງສຸດຂອງບັນທຶກໃນຜົນໄດ້ຮັບ (ນັບ).
• ຕົວເລກລໍາດັບຂອງບັນທຶກທໍາອິດທີ່ຈະຖືກສົ່ງຄືນ (startIndex), ຕົວເລກລໍາດັບຂອງບັນທຶກສຸດທ້າຍທີ່ຈະສົ່ງຄືນ (endIndex).

ຢູ່ glance ທໍາອິດມັນອາດຈະເບິ່ງຄືວ່ານີ້ແມ່ນປະຖົມດັ່ງນັ້ນບໍ່ມີຄວາມແຕກຕ່າງ. ແຕ່ນີ້ບໍ່ແມ່ນດັ່ງນັ້ນ - ທາງເລືອກທີ່ສະດວກທີ່ສຸດແລະທົ່ວໄປແມ່ນທີສອງ (startIndex, ນັບ). ມີຫຼາຍເຫດຜົນສໍາລັບການນີ້:

• ສໍາລັບວິທີການ proofreading ເຂົ້າ +1 ທີ່ກ່າວມາຂ້າງເທິງ, ທາງເລືອກທໍາອິດທີ່ມີ pageIndex ແລະ pageSize ແມ່ນບໍ່ສະດວກທີ່ສຸດ. ຕົວຢ່າງ, ພວກເຮົາຕ້ອງການສະແດງ 50 ຂໍ້ຄວາມຕໍ່ຫນ້າ. ອີງຕາມສູດການຄິດໄລ່ຂ້າງເທິງ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ອ່ານບັນທຶກຫນຶ່ງຫຼາຍກ່ວາຄວາມຈໍາເປັນ. ຖ້າ "+1" ນີ້ບໍ່ໄດ້ຖືກປະຕິບັດຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ, ມັນປາກົດວ່າສໍາລັບຫນ້າທໍາອິດພວກເຮົາຕ້ອງຮ້ອງຂໍການບັນທຶກຈາກ 1 ຫາ 51, ສໍາລັບທີສອງ - ຈາກ 51 ຫາ 101, ແລະອື່ນໆ. ຖ້າທ່ານກໍານົດຂະຫນາດຫນ້າຂອງ 51 ແລະເພີ່ມ pageIndex, ຫຼັງຈາກນັ້ນຫນ້າທີສອງຈະກັບຄືນມາຈາກ 52 ຫາ 102, ແລະອື່ນໆ. ດັ່ງນັ້ນ, ໃນທາງເລືອກທໍາອິດ, ວິທີດຽວທີ່ຈະປະຕິບັດປຸ່ມທີ່ຖືກຕ້ອງເພື່ອໄປຫນ້າຕໍ່ໄປແມ່ນການໃຫ້ເຄື່ອງແມ່ຂ່າຍພິສູດເສັ້ນ "ພິເສດ", ເຊິ່ງຈະເປັນ nuance implicit ຫຼາຍ.
• ທາງເລືອກທີສາມບໍ່ມີຄວາມຫມາຍຫຍັງເລີຍ, ເພາະວ່າເພື່ອດໍາເນີນການສອບຖາມໃນຖານຂໍ້ມູນສ່ວນໃຫຍ່ທ່ານຍັງຈະຕ້ອງຜ່ານການນັບຫຼາຍກວ່າດັດຊະນີຂອງບັນທຶກທີ່ຜ່ານມາ. ການຫັກລົບ startIndex ຈາກ endIndex ອາດຈະເປັນການທໍາງານເລກຄະນິດທີ່ງ່າຍດາຍ, ແຕ່ວ່າມັນແມ່ນ superfluous ຢູ່ທີ່ນີ້.

ໃນປັດຈຸບັນພວກເຮົາຄວນອະທິບາຍຂໍ້ເສຍຂອງການປະຕິບັດຫນ້າທີ່ຜ່ານ "ຊົດເຊີຍ + ປະລິມານ":

• ການດຶງຂໍ້ມູນແຕ່ລະຫນ້າຕໍ່ໄປຈະມີລາຄາແພງກວ່າແລະຊ້າກວ່າຫນ້າທີ່ຜ່ານມາ, ເພາະວ່າຖານຂໍ້ມູນຍັງຈະຕ້ອງຜ່ານບັນທຶກທັງຫມົດ "ຕັ້ງແຕ່ເລີ່ມຕົ້ນ" ຕາມເງື່ອນໄຂການຊອກຫາແລະການຈັດລຽງ, ແລະຫຼັງຈາກນັ້ນຢຸດຢູ່ໃນຊິ້ນທີ່ຕ້ອງການ.
• ບໍ່ແມ່ນ DBMS ທັງຫມົດສາມາດສະຫນັບສະຫນູນວິທີການນີ້.

ມີທາງເລືອກ, ແຕ່ພວກມັນບໍ່ສົມບູນແບບ. ວິທີທໍາອິດຂອງວິທີການເຫຼົ່ານີ້ເອີ້ນວ່າ "keyset paging" ຫຼື "ວິທີການຊອກຫາ" ແລະເປັນດັ່ງຕໍ່ໄປນີ້: ຫຼັງຈາກໄດ້ຮັບສ່ວນຫນຶ່ງ, ທ່ານສາມາດຈື່ຈໍາຄ່າພາກສະຫນາມໃນບັນທຶກສຸດທ້າຍໃນຫນ້າ, ແລະຫຼັງຈາກນັ້ນນໍາໃຊ້ພວກມັນເພື່ອໃຫ້ໄດ້. ສ່ວນຕໍ່ໄປ. ຕົວຢ່າງ, ພວກເຮົາດໍາເນີນການສອບຖາມຕໍ່ໄປນີ້:

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 ສ່ວນໃຫຍ່. ຂໍ້ຍົກເວັ້ນທີ່ຂ້ອຍຮູ້ແມ່ນ PostgreSQL, ເຊິ່ງສະຫນັບສະຫນູນການປຽບທຽບ tuple ຢ່າງເຕັມສ່ວນ, ແລະເງື່ອນໄຂຂ້າງເທິງສາມາດຂຽນເປັນ "WHERE (OrderDate, SalesOrderID) < ('2014-06-29', 75074)". ເນື່ອງຈາກລະຫັດປະກອບກັບສອງຊ່ອງຂໍ້ມູນນີ້, ຄໍາຖາມແບບນີ້ຄວນຈະງ່າຍພໍສົມຄວນ.

ວິທີການທາງເລືອກທີສອງສາມາດພົບໄດ້, ສໍາລັບການຍົກຕົວຢ່າງ, ໃນ ElasticSearch scroll API ຫຼື Cosmos DB — ເມື່ອ​ຄຳ​ຮ້ອງ​ຂໍ, ນອກ​ເໜືອ​ໄປ​ຈາກ​ຂໍ້​ມູນ, ສົ່ງ​ຄືນ​ຕົວ​ລະ​ບຸ​ພິ​ເສດ​ທີ່​ທ່ານ​ສາ​ມາດ​ໄດ້​ຮັບ​ຂໍ້​ມູນ​ສ່ວນ​ຕໍ່​ໄປ. ຖ້າຕົວລະບຸນີ້ມີອາຍຸບໍ່ຈໍາກັດ (ເຊັ່ນດຽວກັບ Comsos DB), ນີ້ແມ່ນວິທີທີ່ດີທີ່ຈະປະຕິບັດຫນ້າທີ່ມີການປ່ຽນລໍາດັບລະຫວ່າງຫນ້າ (ທາງເລືອກ #2 ທີ່ໄດ້ກ່າວມາຂ້າງເທິງ). ຂໍ້ເສຍທີ່ເປັນໄປໄດ້ຂອງມັນ: ມັນບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນໃນ DBMSs ທັງຫມົດ; ຕົວລະບຸຊຸດຕໍ່ໄປທີ່ເປັນຜົນອອກມາອາດຈະມີອາຍຸການຈຳກັດ, ເຊິ່ງໂດຍທົ່ວໄປແລ້ວບໍ່ເໝາະສົມສຳລັບການປະຕິບັດການໂຕ້ຕອບຂອງຜູ້ໃຊ້ (ເຊັ່ນ: ElasticSearch scroll API).

ການກັ່ນຕອງສະລັບສັບຊ້ອນ

ຂໍໃຫ້ສັບສົນວຽກງານຕື່ມອີກ. ສົມມຸດວ່າມີຄວາມຕ້ອງການທີ່ຈະປະຕິບັດອັນທີ່ເອີ້ນວ່າການຄົ້ນຫາ faceted, ເຊິ່ງມີຄວາມຄຸ້ນເຄີຍກັບທຸກຄົນຈາກຮ້ານຄ້າອອນໄລນ໌. ຕົວຢ່າງຂ້າງເທິງໂດຍອີງໃສ່ຕາຕະລາງຄໍາສັ່ງບໍ່ແມ່ນຕົວຢ່າງຫຼາຍໃນກໍລະນີນີ້, ສະນັ້ນໃຫ້ປ່ຽນໄປຫາຕາຕະລາງຜະລິດຕະພັນຈາກຖານຂໍ້ມູນ AdventureWorks:

ແນວຄວາມຄິດທີ່ຢູ່ເບື້ອງຫລັງການຄົ້ນຫາແບບປະເຊີນຫນ້າແມ່ນຫຍັງ? ຄວາມຈິງແມ່ນວ່າແຕ່ລະອົງປະກອບການກັ່ນຕອງຈໍານວນບັນທຶກທີ່ກົງກັບເງື່ອນໄຂນີ້ແມ່ນສະແດງໃຫ້ເຫັນ ຄໍານຶງເຖິງຕົວກອງທີ່ເລືອກຢູ່ໃນປະເພດອື່ນໆທັງຫມົດ.

ຕົວຢ່າງ, ຖ້າພວກເຮົາເລືອກປະເພດ Bikes ແລະສີ ດຳ ໃນຕົວຢ່າງນີ້, ຕາຕະລາງຈະສະແດງພຽງແຕ່ລົດຖີບສີ ດຳ, ແຕ່:

• ສໍາລັບແຕ່ລະເງື່ອນໄຂໃນກຸ່ມໝວດໝູ່, ຈໍານວນສິນຄ້າຈາກໝວດໝູ່ນັ້ນຈະຖືກສະແດງເປັນສີດຳ.
• ສໍາລັບແຕ່ລະເງື່ອນໄຂຂອງກຸ່ມ "ສີ", ຈໍານວນລົດຖີບຂອງສີນີ້ຈະຖືກສະແດງ.

ນີ້ແມ່ນຕົວຢ່າງຂອງຜົນໄດ້ຮັບສໍາລັບເງື່ອນໄຂດັ່ງກ່າວ:

ຖ້າທ່ານກວດເບິ່ງປະເພດ "ເສື້ອຜ້າ", ຕາຕະລາງຈະສະແດງເຄື່ອງນຸ່ງສີດໍາທີ່ມີຢູ່ໃນຫຼັກຊັບ. ຈໍານວນຂອງຜະລິດຕະພັນສີດໍາໃນພາກ "ສີ" ຍັງຈະຖືກຄິດໄລ່ຕາມເງື່ອນໄຂໃຫມ່, ພຽງແຕ່ຢູ່ໃນພາກ "ປະເພດ" ບໍ່ມີຫຍັງປ່ຽນແປງ ... ຂ້າພະເຈົ້າຫວັງວ່າຕົວຢ່າງເຫຼົ່ານີ້ແມ່ນພຽງພໍທີ່ຈະເຂົ້າໃຈວິທີການຄົ້ນຫາແບບປົກກະຕິ.

ຕອນນີ້ຂໍໃຫ້ຈິນຕະນາການວິທີການນີ້ສາມາດຖືກປະຕິບັດບົນພື້ນຖານຄວາມສໍາພັນ. ແຕ່​ລະ​ກຸ່ມ​ຂອງ​ມາດ​ຕະ​ຖານ​ເຊັ່ນ​ປະ​ເພດ​ແລະ​ສີ​, ຈະ​ຮຽກ​ຮ້ອງ​ໃຫ້​ມີ​ການ​ສອບ​ຖາມ​ແຍກ​ຕ່າງ​ຫາກ​:

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

ມີຫຍັງຜິດພາດກັບການແກ້ໄຂນີ້? ມັນງ່າຍດາຍຫຼາຍ - ມັນບໍ່ໄດ້ຂະຫນາດດີ. ແຕ່ລະພາກສ່ວນການກັ່ນຕອງຮຽກຮ້ອງໃຫ້ມີການສອບຖາມແຍກຕ່າງຫາກເພື່ອຄິດໄລ່ປະລິມານ, ແລະການສອບຖາມເຫຼົ່ານີ້ແມ່ນບໍ່ງ່າຍທີ່ສຸດ. ໃນຮ້ານຄ້າອອນໄລນ໌, ບາງປະເພດອາດມີພາກສ່ວນການກັ່ນຕອງຫຼາຍສິບ, ເຊິ່ງອາດຈະເປັນບັນຫາການປະຕິບັດທີ່ຮ້າຍແຮງ.

ປົກກະຕິແລ້ວຫຼັງຈາກຄໍາຖະແຫຼງເຫຼົ່ານີ້, ຂ້ອຍໄດ້ສະເຫນີວິທີແກ້ໄຂບາງຢ່າງ, ຄື:

• ສົມທົບການນັບປະລິມານທັງໝົດເຂົ້າໃນການສອບຖາມອັນດຽວ. ດ້ານວິຊາການນີ້ແມ່ນເປັນໄປໄດ້ໂດຍໃຊ້ຄໍາຫລັກຂອງ UNION, ແຕ່ມັນຈະບໍ່ຊ່ວຍປະສິດທິພາບຫຼາຍ - ຖານຂໍ້ມູນຍັງຈະຕ້ອງປະຕິບັດແຕ່ລະຊິ້ນຈາກຈຸດເລີ່ມຕົ້ນ.
• ປະລິມານແຄດ. ນີ້ແມ່ນແນະນໍາໃຫ້ຂ້ອຍເກືອບທຸກຄັ້ງທີ່ຂ້ອຍອະທິບາຍບັນຫາ. ຄໍາເຕືອນແມ່ນວ່ານີ້ແມ່ນເປັນໄປບໍ່ໄດ້ໂດຍທົ່ວໄປ. ໃຫ້ເວົ້າວ່າພວກເຮົາມີ 10 "ລັກສະນະ", ແຕ່ລະຄົນມີ 5 ຄຸນຄ່າ. ນີ້ແມ່ນສະຖານະການ "ເລັກນ້ອຍ" ເມື່ອທຽບກັບສິ່ງທີ່ສາມາດເຫັນໄດ້ໃນຮ້ານອອນໄລນ໌ດຽວກັນ. ທາງເລືອກຂອງອົງປະກອບ facet ຫນຶ່ງຜົນກະທົບຕໍ່ປະລິມານໃນ 9 ອື່ນໆ, ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ສໍາລັບແຕ່ລະປະສົມປະສານຂອງເງື່ອນໄຂປະລິມານສາມາດແຕກຕ່າງກັນ. ໃນຕົວຢ່າງຂອງພວກເຮົາ, ມີຈໍານວນທັງຫມົດ 50 ເງື່ອນໄຂທີ່ຜູ້ໃຊ້ສາມາດເລືອກໄດ້; ດັ່ງນັ້ນ, ຈະມີ 250 ປະສົມປະສານທີ່ເປັນໄປໄດ້. ບໍ່ມີຫນ່ວຍຄວາມຈໍາຫຼືເວລາພຽງພໍເພື່ອຕື່ມຂໍ້ມູນດັ່ງກ່າວ. ໃນທີ່ນີ້ທ່ານສາມາດຄັດຄ້ານແລະເວົ້າວ່າບໍ່ແມ່ນການປະສົມທັງຫມົດທີ່ແທ້ຈິງແລະຜູ້ໃຊ້ບໍ່ຄ່ອຍຈະເລືອກເອົາຫຼາຍກ່ວາ 5-10 ເງື່ອນໄຂ. ແມ່ນແລ້ວ, ມັນເປັນໄປໄດ້ທີ່ຈະເຮັດການໂຫຼດຂີ້ກຽດແລະ cache ໃນປະລິມານພຽງແຕ່ສິ່ງທີ່ເຄີຍເລືອກ, ແຕ່ການຄັດເລືອກຫຼາຍ, cache ດັ່ງກ່າວມີປະສິດທິພາບຫນ້ອຍລົງແລະສັງເກດເຫັນບັນຫາເວລາຕອບສະຫນອງຫຼາຍ (ໂດຍສະເພາະຖ້າ ຊຸດຂໍ້ມູນມີການປ່ຽນແປງເປັນປົກກະຕິ).

ໂຊກດີ, ບັນຫາດັ່ງກ່າວມີມາດົນແລ້ວມີວິທີແກ້ໄຂທີ່ມີປະສິດທິຜົນທີ່ຄາດເດົາໄດ້ໃນປະລິມານຂະຫນາດໃຫຍ່ຂອງຂໍ້ມູນ. ສໍາລັບທາງເລືອກໃດໆເຫຼົ່ານີ້, ມັນມີຄວາມຫມາຍທີ່ຈະແບ່ງການຄິດໄລ່ໃຫມ່ຂອງ facets ແລະການຮັບຫນ້າຜົນໄດ້ຮັບອອກເປັນສອງການໂທຂະຫນານກັບເຄື່ອງແມ່ຂ່າຍແລະຈັດການໂຕ້ຕອບຜູ້ໃຊ້ໃນລັກສະນະການໂຫຼດຂໍ້ມູນໂດຍ facets "ບໍ່ແຊກແຊງ" ກັບການສະແດງຂອງ. ຜົນການຄົ້ນຫາ.

• ໂທຫາການຄິດໄລ່ຄືນໃຫມ່ຂອງ "ລັກສະນະ" ທີ່ບໍ່ຄ່ອຍເປັນໄປໄດ້. ຕົວຢ່າງ, ຢ່າຄິດໄລ່ຄືນໃຫມ່ທຸກໆຄັ້ງທີ່ເງື່ອນໄຂການຊອກຫາປ່ຽນແປງ, ແຕ່ແທນທີ່ຈະຊອກຫາຈໍານວນຜົນໄດ້ຮັບທີ່ກົງກັບເງື່ອນໄຂໃນປະຈຸບັນແລະໃຫ້ຜູ້ໃຊ້ສະແດງໃຫ້ພວກເຂົາ - "1425 ບັນທຶກທີ່ພົບເຫັນ, ສະແດງ?" ຜູ້ໃຊ້ສາມາດສືບຕໍ່ປ່ຽນຄໍາຄົ້ນຫາຫຼືຄລິກໃສ່ປຸ່ມ "ສະແດງ". ພຽງແຕ່ໃນກໍລະນີທີສອງ, ທຸກໆຄໍາຮ້ອງຂໍການໄດ້ຮັບຜົນໄດ້ຮັບແລະການຄິດໄລ່ປະລິມານຄືນໃຫມ່ໃນ "ລັກສະນະ" ທັງຫມົດຈະຖືກປະຕິບັດ. ໃນກໍລະນີນີ້, ຕາມທີ່ເຈົ້າສາມາດເຫັນໄດ້ຢ່າງງ່າຍດາຍ, ທ່ານຈະຕ້ອງຈັດການກັບຄໍາຮ້ອງຂໍເພື່ອໃຫ້ໄດ້ຈໍານວນຜົນໄດ້ຮັບທັງຫມົດແລະການເພີ່ມປະສິດທິພາບຂອງມັນ. ວິທີການນີ້ສາມາດພົບໄດ້ຢູ່ໃນຮ້ານຄ້າອອນໄລນ໌ຂະຫນາດນ້ອຍຈໍານວນຫຼາຍ. ແນ່ນອນ, ນີ້ບໍ່ແມ່ນ panacea ສໍາລັບບັນຫານີ້, ແຕ່ໃນກໍລະນີງ່າຍດາຍມັນສາມາດເປັນການປະນີປະນອມທີ່ດີ.
• ໃຊ້ເຄື່ອງຈັກຊອກຫາເພື່ອຊອກຫາຜົນໄດ້ຮັບແລະນັບ facets, ເຊັ່ນ Solr, ElasticSearch, Sphinx ແລະອື່ນໆ. ພວກມັນທັງ ໝົດ ຖືກອອກແບບມາເພື່ອສ້າງ "ດ້ານ" ແລະເຮັດອັນນີ້ຢ່າງມີປະສິດທິພາບເນື່ອງຈາກດັດຊະນີທີ່ປີ້ນກັບກັນ. ເຄື່ອງຈັກຊອກຫາເຮັດວຽກແນວໃດ, ເປັນຫຍັງໃນກໍລະນີດັ່ງກ່າວ, ພວກມັນມີປະສິດທິພາບຫຼາຍກ່ວາຖານຂໍ້ມູນທີ່ມີຈຸດປະສົງທົ່ວໄປ, ການປະຕິບັດແລະ pitfalls ແມ່ນຫຍັງ - ນີ້ແມ່ນຫົວຂໍ້ສໍາລັບບົດຄວາມແຍກຕ່າງຫາກ. ທີ່ນີ້ຂ້າພະເຈົ້າຢາກຈະດຶງດູດຄວາມສົນໃຈຂອງທ່ານກັບຄວາມຈິງທີ່ວ່າເຄື່ອງຈັກຊອກຫາບໍ່ສາມາດເປັນການທົດແທນການເກັບຮັກສາຂໍ້ມູນຕົ້ນຕໍ; ມັນຖືກນໍາໃຊ້ເປັນການເພີ່ມເຕີມ: ການປ່ຽນແປງໃດໆໃນຖານຂໍ້ມູນຕົ້ນຕໍທີ່ກ່ຽວຂ້ອງກັບການຄົ້ນຫາແມ່ນ synchronized ເຂົ້າໄປໃນດັດສະນີຄົ້ນຫາ; ເຄື່ອງຈັກຊອກຫາມັກຈະພົວພັນກັບເຄື່ອງຈັກຊອກຫາເທົ່ານັ້ນແລະບໍ່ເຂົ້າເຖິງຖານຂໍ້ມູນຕົ້ນຕໍ. ຫນຶ່ງໃນຈຸດສໍາຄັນທີ່ສຸດນີ້ແມ່ນວິທີການຈັດ synchronization ນີ້ທີ່ເຊື່ອຖືໄດ້. ມັນທັງຫມົດແມ່ນຂຶ້ນກັບຄວາມຕ້ອງການ "ເວລາຕິກິຣິຍາ". ຖ້າເວລາລະຫວ່າງການປ່ຽນແປງໃນຖານຂໍ້ມູນຕົ້ນຕໍແລະ "ການສະແດງອອກ" ຂອງມັນໃນການຄົ້ນຫາແມ່ນບໍ່ສໍາຄັນ, ທ່ານສາມາດສ້າງບໍລິການທີ່ຄົ້ນຫາບັນທຶກທີ່ມີການປ່ຽນແປງບໍ່ດົນມານີ້ທຸກໆສອງສາມນາທີແລະດັດສະນີພວກມັນ. ຖ້າທ່ານຕ້ອງການເວລາຕອບໂຕ້ສັ້ນທີ່ສຸດ, ທ່ານສາມາດປະຕິບັດບາງສິ່ງບາງຢ່າງເຊັ່ນ: ກ່ອງອອກການເຮັດທຸລະກໍາ ເພື່ອສົ່ງອັບເດດໄປຫາບໍລິການຄົ້ນຫາ.

ການຄົ້ນພົບ

1. ການປະຕິບັດຫນ້າຂອງເຊີຟເວີແມ່ນເປັນອາການແຊກຊ້ອນທີ່ສໍາຄັນແລະພຽງແຕ່ເຮັດໃຫ້ຄວາມຮູ້ສຶກສໍາລັບການຂະຫຍາຍຕົວໄວຫຼືພຽງແຕ່ຊຸດຂໍ້ມູນຂະຫນາດໃຫຍ່ເທົ່ານັ້ນ. ບໍ່ມີສູດທີ່ແນ່ນອນສໍາລັບການປະເມີນ "ໃຫຍ່" ຫຼື "ການຂະຫຍາຍຕົວໄວ", ແຕ່ຂ້ອຍຈະປະຕິບັດຕາມວິທີການນີ້:
   • ຖ້າໄດ້ຮັບການເກັບກໍາຂໍ້ມູນຄົບຖ້ວນສົມບູນ, ຄໍານຶງເຖິງເວລາຂອງເຄື່ອງແມ່ຂ່າຍແລະການສົ່ງຜ່ານເຄືອຂ່າຍ, ເຫມາະກັບຄວາມຕ້ອງການຂອງການປະຕິບັດປົກກະຕິ, ບໍ່ມີຈຸດໃດໃນການປະຕິບັດຫນ້າໃນດ້ານເຊີຟເວີ.
   • ອາດຈະມີສະຖານະການທີ່ບໍ່ມີບັນຫາການປະຕິບັດທີ່ຄາດວ່າຈະມີໃນອະນາຄົດອັນໃກ້ນີ້, ເນື່ອງຈາກວ່າມີຂໍ້ມູນຫນ້ອຍ, ແຕ່ການລວບລວມຂໍ້ມູນແມ່ນການຂະຫຍາຍຕົວຢ່າງຕໍ່ເນື່ອງ. ຖ້າບາງຊຸດຂໍ້ມູນໃນອະນາຄົດອາດຈະບໍ່ພໍໃຈກັບຈຸດທີ່ຜ່ານມາ, ມັນກໍ່ດີກວ່າທີ່ຈະເລີ່ມການຫນ້າເວັບທັນທີ.
2. ຖ້າບໍ່ມີຂໍ້ກໍານົດທີ່ເຄັ່ງຄັດໃນສ່ວນຂອງທຸລະກິດເພື່ອສະແດງຈໍານວນຜົນໄດ້ຮັບທັງຫມົດຫຼືສະແດງຕົວເລກຫນ້າ, ແລະລະບົບຂອງທ່ານບໍ່ມີເຄື່ອງຈັກຊອກຫາ, ມັນດີກວ່າທີ່ຈະບໍ່ປະຕິບັດຈຸດເຫຼົ່ານີ້ແລະພິຈາລະນາທາງເລືອກ #2.
3. ຖ້າມີຄວາມຕ້ອງການທີ່ຊັດເຈນສໍາລັບການຄົ້ນຫາ faceted, ທ່ານມີສອງທາງເລືອກໂດຍບໍ່ມີການເສຍສະລະການປະຕິບັດ:
   • ຢ່າຄິດໄລ່ປະລິມານຄືນໃຫມ່ທຸກໆຄັ້ງທີ່ເງື່ອນໄຂການຊອກຫາປ່ຽນແປງ.
   • ໃຊ້ເຄື່ອງຈັກຊອກຫາເຊັ່ນ Solr, ElasticSearch, Sphinx ແລະອື່ນໆ. ແຕ່ມັນຄວນຈະເຂົ້າໃຈວ່າມັນບໍ່ສາມາດເປັນການທົດແທນຖານຂໍ້ມູນຕົ້ນຕໍ, ແລະຕ້ອງຖືກນໍາໃຊ້ເປັນການເພີ່ມການເກັບຮັກສາຕົ້ນຕໍສໍາລັບການແກ້ໄຂບັນຫາການຄົ້ນຫາ.
4. ນອກຈາກນີ້, ໃນກໍລະນີຂອງການຄົ້ນຫາ faceted, ມັນເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ຈະແບ່ງປັນການດຶງເອົາຫນ້າຜົນການຄົ້ນຫາແລະການນັບເປັນສອງຄໍາຮ້ອງຂໍຂະຫນານ. ການນັບຈໍານວນອາດຈະໃຊ້ເວລາດົນກວ່າການໄດ້ຮັບຜົນໄດ້ຮັບ, ໃນຂະນະທີ່ຜົນໄດ້ຮັບແມ່ນສໍາຄັນກວ່າກັບຜູ້ໃຊ້.
5. ຖ້າທ່ານກໍາລັງໃຊ້ຖານຂໍ້ມູນ SQL ສໍາລັບການຄົ້ນຫາ, ການປ່ຽນແປງລະຫັດໃດໆທີ່ກ່ຽວຂ້ອງກັບສ່ວນນີ້ຄວນໄດ້ຮັບການທົດສອບດີສໍາລັບການປະຕິບັດກ່ຽວກັບຈໍານວນຂໍ້ມູນທີ່ເຫມາະສົມ (ເກີນປະລິມານໃນຖານຂໍ້ມູນສົດ). ມັນຍັງແນະນໍາໃຫ້ໃຊ້ການຕິດຕາມເວລາປະຕິບັດການສອບຖາມໃນທຸກຕົວຢ່າງຂອງຖານຂໍ້ມູນ, ແລະໂດຍສະເພາະໃນ "ສົດ". ເຖິງແມ່ນວ່າທຸກສິ່ງທຸກຢ່າງຈະດີກັບແຜນການສອບຖາມໃນຂັ້ນຕອນການພັດທະນາ, ເມື່ອປະລິມານຂໍ້ມູນເພີ່ມຂຶ້ນ, ສະຖານະການອາດຈະມີການປ່ຽນແປງຢ່າງເຫັນໄດ້ຊັດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com