ສິ່ງທີ່ຂາດບໍ່ໄດ້ຂອງການສືບຄົ້ນຂໍ້ມູນ (Query) ໃນ Database ຄື “ຄວາມໄວ” ເຊິ່ງຄົນໄອທີ ທີ່ເຮັດຫນ້າທີ່ໂດຍກົງຢ່າງ SQL Developer แລະ DBA ເອງກໍໄດ້ພະຍາຍາມເຮັດໃຫ້ການສືບຄົ້ນຂໍ້ມູນວ່ອງໄວທີ່ສຸດເທົ່າທີ່ຈະເຮັດໄດ້ຢູ່ແລ້ວ ແຕ່ໜ້າເສຍດາຍວ່າ ເຮົາບໍ່ສາມາດແກ້ໄຂຫລືເຮັດທຸກຢ່າງໃຫ້ອອກຜົນລັບມາໄດ້ຢ່າງສົມບູນແບບດ້ວຍວິທີການດຽວໄດ້ ກົດ 21 ຂໍ້ທີ່ຈະຊ່ວຍໃຫ້ຖານຂໍ້ມູນຂອງເຈົ້າໄວ ແລະ ມີປະສິດທິພາບຍິ່ງຂຶ້ນມີຫຍຫງແດ່ ມາເບິ່ງກັນ!
- ຫຼີກລ້ຽງການໃຊ້ເຄີເຊີ
(Cursor)
ຄົນໄອທີໜ້າຈະຮູ້ກັນດີວ່າ ເມື່ອໃດທີ່ມີການໃຊ້ Cursor ນັ້ນໝາຍເຖິງ ຕ້ອງມີການຖ້າຄຳສັ່ງວ່າຈະໃຫ້ເຮັດຫຍັງ ເຊິ່ງແນ່ນອນວ່າມັນມີຜົນຕໍ່ຄວາມໄວ ອີກທັງຍັງເປັນສາເຫດຂອງການ Block ການເຮັດວຽກງານອື່ນໆ ໂດຍບໍ່ຈຳເປັນດ້ວຍ (ເພາະຕ້ອງຖ້າຄຳສັ່ງຈາກ Cursor ນີ້ແຫຼະ)
- ຫາກລ້ຽງຂໍ້ 1 ບໍ່ໄດ້ ໃຫ້ໃຊ້ Temp
Table
ຫາກເຈົ້າບໍ່ສາມາດລ້ຽງການໃຊ້ Cursor ໄດ້ ກໍຄວນສ້າງ Temp Table ແທນການໃຊ້ຂໍ້ມູນຈາກ Table ແທ້ໆ ເຊິ່ງນອກຈາກຈະມີຂະໜາດນ້ອຍ ແລະ ສະດວກໃນການໃຊ້ງານແລ້ວ ຍັງໃຊ້ Resource ຂອງລະບົບແຕ່ຊົ່ວຄາວອີກດ້ວຍ
- ໃຊ້ Temp Table ຢ່າງສະຫລາດ
ເຈົ້າສາມາດໃຊ້ Temp Table ໃນສະຖານນະການອື່ນໆ ອີກ ເຊັ່ນ ເຈົ້າຕ້ອງການ Join Table ໜຶ່ງກັບອີກ Table ທີ່ໃຫຍ່ຫລາຍໆ ແລະ ຕ້ອງກຳນົດ Condition ຈາກໃນ Table ໃຫຍ່ນັ້ນດ້ວຍ ແນະນຳວ່າເຈົ້າຄວນດຶງຂໍ້ມູນທີ່ຈະໃຊ້ມາຈາກ Table ໃຫຍ່ ມາໃສ່ Temp Table ແລ້ວຄ່ອຍ Joint ກັບ Table ທີ່ຕ້ອງການໃນພາຍຫຼັງ ຈະຊ່ວຍເຮັດໃຫ້ມີປະສິດທິພາບທີ່ດີກວ່າ ນອກຈາກຈະຊ່ວຍລຸດການໃຊ້ resource ແລ້ວ ຍັງເປັນການຊ່ວຍໃຫ້ເຈົ້າເຮັດວຽກສະດວກຂຶ້ນຫາກມີ Query ອື່ນໆ ໃນ Procedure ທີ່ຕ້ອງໃຊ້ການ Join Table ດຽວກັນນີ້ອີກ
- ກຽມຂໍ້ມູນໄວ້ກ່ອນ
(Pre-Stage)
ຖືເປັນເທັກນິກເກົ່າທີ່ຫຼາຍໆ ຄົນມັກເບິ່ງຂ້າມ ຫາກເຈົ້າມີ Report ຫລື Procedure ທີ່ຕ້ອງ Join Table ແບບດຽວກັນ ເຈົ້າຄວນຈະຈັດກຽມຂໍ້ມູນໄວ້ກ່ອນ (Pre-Stage) ໂດຍການ Join Table ກຽມໄວ້ລ່ວງໜ້າ ຈະໄດ້ບໍ່ຕ້ອງ Join Table ຂະໜາດໃຫຍ່, ບາງຄົນອາດເບິ່ງວ່າເທັກນິກນີ້ບໍ່ມີຄວາມຈຳເປັນ ແຕ່ຖ້າເຈົ້າຕ້ອງການໃຊ້ຂໍ້ມູນເຫຼົ່ານັ້ນເລື້ອຍໆ ເປັນຫຍັງເຮົາຈຶ່ງບໍ່ເຮັດໃຫ້ມັນງ່າຍຕໍ່ການໃຊ້ງານແລະປະຢັດ resource ຂອງລະບົບ ແມ່ນບໍ
- ຫຼີກລ້ຽງການໃຊ້
Nested View
ການໃຊ້ View ມີຂໍ້ດີຄື ຊ່ວຍສະແດງໃຫ້ເຫັນຂໍ້ມູນເທົ່າທີ່ຕ້ອງການ ແຕ່ຫາກເຈົ້າໃຊ້ View ຊ້ອນໃນ View ແລະຊ້ອນໄປເລື້ອຍໆ (Nested View) ຈະຍິ່ງເຮັດໃຫ້ Database ຍິ່ງຊ້າລົງ ເພາະຂໍ້ມູນຈະຖືກ Query ຊ້ອນກັນໄປເລື້ອຍໆ ຫລືໃນເຄດຮ້າຍແຮງສຸດຄື ລະບົບອາດຈະບໍ່ສະແດງຜົນຫຍັງອອກມາເລຍກໍໄດ້ເພາະເຮັດວຽກໜັກເກີນໄປ ຫາກເຈົ້າລຸດການໃຊ້ Nested View ໄດ້ຈະລຸດເວລາຈາກນາທີ ລົງເຫຼືອເປັນ ວິນາທີເລີຍທີດຽວ
- ໃຊ້ CASE ແທນການໃຊ້
UPDATE
ສົມມຸດ ເຈົ້າຕ້ອງການນຳຂໍ້ມູນລູກຄ້າທັງໝົດຈາກ Table Customer ມາໃສ່ Temp Table ໂດຍທີ່ຖ້າລູກຄ້າຄົນໃດມີຍອດສັ່ງຊື້ເກີນ $100,000 ຂຶ້ນໄປ ໃຫ້ໃສ່ Label ຂອງລູກຄ້າເຫຼົ່ານັ້ນໃນເປັນ “Preferred” ປົກກະຕິຖ້າບໍ່ຄິດຊັບຊ້ອນຫລາຍ ຂັ້ນທຳອິດເຮົາຈະ INSERT ຂໍ້ມູນທັງໝົດຈາກ Table Customer ລົງໃນ Temp Table ກ່ອນ ແລ້ວຂັ້ນຕອນຖັດມາ ຄ່ອຍ UPDATE ຂໍ້ມູນ Label ໃຫ້ເປັນ Preferred ສຳລັບລູກຄ້າທີ່ມີຍອດສັ່ງຊື້ເກີນ $100,000 ແຕ່ນັ້ນເຮັດໃຫ້ເຈົ້າຕ້ອງໃຊ້ເຖິງ 2 ຂັ້ນຕອນໃນການເຮັດໃຫ້ສຳເລັດ ມັນມີເທັກນິກທີ່ງ່າຍກວ່ານັ້ນຄື ການໃຊ້ CASE ຕັ້ງແຕ່ໃນຂັ້ນຕອນ Insert ແທນທີ່ຈະມາທຳການ UPDATE ພາຍຫລັງ ເພາະເມື່ອໃຊ້ CASE ແລ້ວ ເຈົ້າຈະສາມາດເລືອກລູກຄ້າໂດຍທີ່ເງື່ອນໄຂຂ້າງຕົ້ນມາກ່ອນທີ່ຈະ INSERT ໃນ Temp Table ໄດ້ເລີຍ ເຮັດໃຫ້ເຫຼືອພຽງ 1 ຂັ້ນຕອນເທົ່ານັ້ນ ຊຶ່ງຈະຊ່ວຍເຮັດໃຫ້ມີປະສິດທິພາບທີ່ດີກວ່າ
- ໃຊ້ Table-valued Function ແທນການໃຊ້ Scalar
ສຳລັບຫົວຂໍ້ນີ້ຖືເປັນ Tip ທີ່ໜ້າສົນໃຈ ຄື ເມື່ອເຈົ້າໃຊ້ Scalar Function ໃນການ SELECT ຂໍ້ມູນ ເຈົ້າສາມາດເພີ່ມປະສິດທິພາບໄດ້ໂດຍການແປງໄປເປັນ Table-valued Function ແລະໃຊ້ CROSS APPLY ໃນການ Query ການເຮັດເຊັ່ນນີ້ສາມາດລຸດຈຳນວນການ Query ລົງໄດ້ເຄິ່ງໜຶ່ງເລີຍ
- ໃຊ້ Partitions ໃນ SQL
Server
ຜູ້ທີ່ໃຊ້ SQL Server Enterprise ສາມາດໃຊ້ປະໂຫຍດຈາກ Feature “Automatic Partition” ເພື່ອເພີ່ມປະສິດທິພາບຄວາມໄວໃຫ້ຫລາຍຂຶ້ນ ໃນ SQL Server ເຖິງວ່າ Table ຈະຖືກສ້າງຂຶ້ນເປັນ Partition ດຽວ ເຊິ່ງເຈົ້າສາມາດແບ່ງອອກເປັນຫຼາຍໆ ສ່ວນໄດ້ ດັ່ງນັ້ນ ເມື່ເຈົ້າຕ້ອງການຍ້າຍຂໍ້ມູນຈຳນວນຫລາຍລະຫວ່າງ Table ເຈົ້າສາມາດໃຊ້ຄຳສັ່ງ SWITCH ແທນ INSERT ແລະ DELETE ເນື່ອງຈາກເຈົ້າກຳລັງປ່ຽນ metadata ສຳລັບ Table ດຽວແທນການ DELETE ແລະ INSERT ຂໍ້ມູນທີ່ມີຈຳນວນຫລາຍລະຫວ່າງ Table ຈະໃຊ້ເວລາພຽງບໍ່ຈັກວິນາທີໃນການເຮັດວຽກງານ
- DELETE ແລະ UPDATE ເປັນ Batch
ໃຫຍ່ໆ
ການ DELETE ແລະ UPDATE ຂໍ້ມູນທີ່ມີປະລິມານມະຫາສານ (Batch ໃຫຍ່ໆ) ໃນ Table ໜ້າຈະຖືເປັນ “ຝັນຮ້າຍ” ຂອງຄົນໄອທີຫຼາຍໆ ຄົນ ບັນຫາຄືທັງ 2 ຄຳສັ່ງຖືກ Run ເປັນ Transaction ດຽວ ຖ້າເຈົ້າຕ້ອງການ Kill Process ຫລືມີບັນຫາຫຍັງເກີດຂຶ້ນລະຫວ່າງການ Run ກໍຕາມ ລະບົບຈະ Roll back ທັງ Transaction ນັ້ນໝາຍເຖິງ ຕ້ອງໃຊ້ເວລາດົນກວ່າສຳເລັດ ໃນຂະນະດຽວກັນມັນຈະໄປປິດກັ້ນການເຮັດວຽກງານຂອງ Transaction ອື່ນໆ ດ້ວຍ ທາງແກ້ໄຂ ກໍຄື ຄວນ DELETE ແລະ UPDATE ທີ່ເປັນ Batch ນ້ອຍໆ ຈະດີກວ່າເພາະຫາກເກີດບັນຫາແລ້ວຕ້ອງ Roll back ຈະໃຊ້ເວລານ້ອຍກວ່າ ເຮັດໃຫ້ຖານຂໍ້ມູນກັບມາໃຊ້ງານໄດ້ວ່ອງໄວກວ່າ
- ທຸກຢ່າງຕ້ອງໃຊ້ເວລາ
Developer ບາງຄົນຕ້ອງມາ “ຕິດ” ກັບຄຳສັ່ງ DELETE ແລະ UPDATE ໃນຂໍ້ 9 ຢູ່ດົນແສນດົນ ພຽງຫວັງວ່າມັນຈະເຮັດສຳເລັດພາຍໃນມື້ດຽວ ຄຳຕອບຄື ມັນອາດຈະບໍ່ໄດ້ເປັນແບບນັ້ນສະເໝີໄປ ຖ້າມັນຈຳເປັນຕ້ອງຖ້າ ເຈົ້າກໍຄວນຂະຫຍາຍເວລາຖ້າຜົນອອກໄປ ແຕ່ການເຮັດເປັນ Batch ນ້ອຍໆ ຈະຊ່ວຍໃຫ້ເຈົ້າບໍ່ຮູ້ສຶກວ່າຕ້ອງຖ້າດົນໆ ຖ້າມີບັນຫາຂຶ້ນມາກໍຫຼຸດການເກີດລະບົບ Down ອີກດ້ວຍ
- Stored Procedure ມີປະໂຫຍດຫຼາຍຢ່າງ
ນອກຈາກຈະເຮັດໃຫ້ຕົວ Code ມີປະສິດທິພາບແລ້ວ ຍັງມີຂໍ້ດີອີກຫຼາຍຢ່າງ ທັງຊ່ວຍລຸດ Traffic ຂອງ Network ຫລືລະຫວ່າງ Database ກັບ Application ແລະ ງ່າຍໃນການຕິດຕາມຂໍ້ມູນ ໂດຍການໃຊ້ Tool ຢ່າງເຊັ່ນ Profiler ເຊິ່ງຊ່ວຍໃຫ້ເຈົ້າໄດ້ຮູ້ສະຖິຕິຕ່າງໆ ໄດ້ຢ່າງມີປະສິດທິພາບ ລວມທັງລະບຸບັນຫາທີ່ອາດເກີດຂຶ້ນໄດ້ຢ່າງວ່ອງໄວຂຶ້ນ ນອກຈາກນີ້ ຍັງເໝາະກັບການເອີ້ນໃຊ້ຂໍ້ມູນຊ້ຳໆດ້ວຍ ມີ .Net Developer ຫຼາຍຄົນມັກໃຫ້ຄວາມສຳຄັນກັບການພັດທະນາຕົວ Front end ຂອງ App ໃຫ້ສອດຄ້ອງກັບຄວາມຕ້ອງການຂອງທຸລະກິດຫລາຍກວ່າໃຫ້ຄວາມສຳຄັນກັບ Database ເຊິ່ງໃນຄວາມເປັນຈິງແລ້ວ ເປັນຄວາມຄິດທີ່ບໍ່ຖືກຕ້ອງປານໃດ
- ຂຽນ Query ໃໝ່ເພື່ອຫຼີກລ້ຽງຜົນກະທົບໃນການ Search ຂໍ້ມູນ
ຫາກເຈົ້າຕ້ອງການປຽບທຽບຂໍ້ມູນແຕ່ລະແຖວ(Row) ກໍລະນີທີ່ບໍ່ສາມາດໃຊ້ Index ເຊັ່ນ SELECT * FROM Customers WHERE RegionID <> 3 ແຕ່ມັນຈະດີກວ່າຫາກຂຽນ Query ໃໝ່ໂດຍທີ່ສາມາດໃຊ້ການ Index ເພື່ອຊ່ວຍໃນການຄົ້ນຫາຂໍ້ມູນໄດ້ ໂດຍແກ້ໄຂເປັນ SELECT * FROM Customers WHERE RegionID < 3 UNION ALL SELECT * FROM Customers WHERE RegionID > 3 ກໍລະນີທີ່ຊຸດຂໍ້ມູນມີຂະໜາດໃຫຍ່ຫລາຍໆ ການໃຊ້ Index ຈະສາມາດຄົ້ນຫາໄດ້ດີກວ່າການ Scan ຂໍ້ມູນໃນ Table ແຕ່ທາງທີ່ດີເຈົ້າຄວນທົດສອບກ່ອນຈະ Implement ສະເໝີ ແລະຫາກເຈົ້າສັງເກດດີໆ ຈະພບວ່າ ມັນຂັດແຍ້ງກັບກົດໃນຂໍ້ 13 (ຫຼີກລ້ຽງການເກີດ Double-Dipping) ຢູ່ ແຕ່ມັນກໍສະທ້ອນເຫັນເຊັ່ນກັນວ່າ ບໍ່ມີເທັກນິກໃດທີ່ໃຊ້ໄດ້ໃນທຸກກໍລະນີສະເໝີໄປ ເຖິງວ່າຈະເກີດ Double-Dipping ໃນເທື່ອນີ້ ແຕ່ເຮົາກໍຍັງຄົງເຮັດເພື່ອຫຼີກລ້ຽງການທີ່ຕ້ອງ Scan ຂໍ້ມູນທັງ Table ນັ້ນເອງ ສິ່ງສຳຄັນທີ່ສຸດຄື ເຮົາຄວນເລືອກວິທີທີ່ເໝາະສົມຫລາຍກວ່າ ຢ່າຢຶດແຕ່ຫຼັກການພຽງຢ່າງດຽວ
- ຫຼີກລ້ຽງການໃຊ້
ORM
ອັນທີ່ຈິງແລ້ວ Object-relational mappers (ORMs) ເປັນການຂຽນ Code ເພື່ອອຳນວຍຄວາມສະດວກໃນການແປງຈາກ Object ໄປເປັນ Database ຫຼື ແປງຈາກ Database ກັບມາເປັນ Object ໂດຍບໍ່ຕ້ອງຍຸ່ງກັບໃນສ່ວນຂອງ SQL ເລີຍ ແຕ່ຂະນະດຽວກັນ ມັນກໍສົ່ງຜົນກະທົບຕໍ່ Performance ໂດຍລວມໄດ້ ແລະ ອາດເບິ່ງບໍ່ຄ່ອຍຈຳເປັນເທົ່າໃດ ແຕ່ຫາກເຈົ້າຈຳເປັນຕ້ອງໃຊ້ ORM ແນະນຳໃຫ້ໃຊ້ Stored Procedures ແລ້ວໃຫ້ ORM ມາເອີ້ນມັນໃຊ້ງານແທນການໃຊ້ ORM ໂດຍກົງ
- ແຍກ Transaction ໃຫຍ່ໆ ໃຫ້ນ້ອຍລົງ
ການດຳເນີນການຫຍັງກໍຕາມກັບຫຼາຍໆ Table ພ້ອມໆ ກັນພາຍໃນ Transaction ດຽວ ຈະເຮັດໃຫ້ Table ເຫຼົ່ານັ້ນຈະຖືກ Lock ຈົນກວ່າຈະດຳເນີນການ Transaction ນັ້ນສຳເລັດ ທາງແກ້ບັນຫາຈາກກໍລະນີແບບນີ້ຄື ຄວນແບ່ງເປັນ Transaction ຍ່ອຍໆ ແທນ ໂດຍພະຍາຍາມໃຫ້ເຫຼືອ 1 Operation ຕໍ່ Table ແລ້ວຄ່ອຍໆດຳເນີນການໄປໃນແຕ່ລະ Table ການເຮັດແບບນີ້ເພື່ອຊ່ວຍໃຫ້ Table ອື່ນທີ່ບໍ່ຖືກ Operation ຈະໄດ້ບໍ່ຖືກ Block ໄປນຳ
- ໃຊ້ System Table ໃນການນັບແຖວຂໍ້ມູນ
Rows ຂອງຂໍ້ມູນໃນ Table ທີ່ມີຂະໜາດໃຫຍ່ໆ ສາມາດໃຊ້ຄຳສັ່ງ SELECT rows from sysindexes ພຽງເທົ່ານີ້ ເຈົ້າກໍຈະໄດ້ຈຳນວນແຖວ Index ທັງໝົດ ແລະ ເນື່ອງຈາກກຸ່ມ Index ເອງກໍເປັນຂໍ້ມູນຢູ່ແລ້ວ ເຈົ້າສາມາດຮູ້ຈຳນວນ Rows ຂອງ Table ດ້ວຍການເພີ່ມເງື່ອນໄຂ WHERE indid = 1 ເຂົ້າໄປ ຈາກນັ້ນກໍໃສ່ຊື່ Table ແລະ ເຈົ້າກໍຈະໄດ້ຂໍ້ມູນທີ່ຕ້ອງການ ໂດຍເຈົ້າສາມາດໃຊ້ຄຳສັ່ງ Query ດັ່ງນີ້ SELECT rows FROM sysindexes WHERE object_name(id) = ‘T1’ AND indid = 1
- ຄວນດຶງສະເພາະ Column
ທີ່ຕ້ອງການເທົ່ານັ້ນ
ມັນອາດຈະເບິ່ງງ່າຍ ແຄ່ໃຊ້ຄຳສັ່ງ SELECT * ແທນທີ່ຈະດຶງ Column ເທື່ອລະລາຍການ ເມື່ອເຮັດແບບນີ້ມີບັນຫາຄື ເຈົ້າຈະໄດ້ຂໍ້ມູນທີ່ບໍ່ຕ້ອງການອອກມາດ້ວຍ ຄິດເບິ່ງຫາກເຈົ້າໃຊ້ຄຳສັ່ງ SELECT * ໃນ Table ທີ່ມີ 120 Columns ແລະມີຈຳນວນແຖວເປັນລ້ານໆ Rows ແຕ່ຂໍ້ມູນທີ່ເຈົ້າຕ້ອງການໃຊ້ຈິງ ມີພຽງ 3 – 5 ລາຍການເທົ່ານັ້ນ ຜົນຄື ບໍ່ພຽງຕ້ອງປະມວນຜົນຂໍ້ມູນໃນຈຳນວນມະຫາສານເທົ່ານັ້ນ ແຕ່ຍັງກິນ Resource ຂອງລະບົບໄປຫລວງຫລາຍໂດຍບໍ່ຈຳເປັນອີກດ້ວຍ
- ລະມັດລະວັງການໃຊ້
Trigger
ການໃຊ້ Trigger ກໍອາດຈະເກີດບັນຫາໃນລັກສະນະດຽວກັບຫົວຂໍ້ທີ່ແລ້ວໄດ້ເຊັ່ນກັນ ຄືລະວ່າງໃຊ້ Trigger ມັນຈະ Lock ຕົວ Table ທີ່ກ່ຽວຂ້ອງຈົນກວ່າຈະດຳເນີນການ Transaction ນັ້ນສຳເລັດ ທາງແນະນຳກໍຄື ເຮັດເປັນ Trigger ຍ່ອຍໆ ສຳລັບແຕ່ລະ Table ເຊິ່ງມັນຈະໃຊ້ງານ Resource ຕ່າງໆ ນ້ອຍລົງ ແລະ ຖ້າຈະ Rollback ຂໍ້ມູນ ກໍສາມາດເຮັດໄດ້ງ່າຍກວ່າດ້ວຍ ອັນທີ່ຈິງ ໃນຫຼາຍກໍລະນີກໍບໍ່ຈຳເປັນຕ້ອງໃຊ້ Trigger ກໍໄດ້
- ຫຼີກລ້ຽງການເກີດ
Double-Dipping
ບາງກໍລະນີການໃຊ້ງານ Stored Procedure ກໍອາດເຮັດໃຫ້ເກີດ Double-Dipping ໄດ້ເຊັ່ນກັນ ຫາກເຈົ້າຕ້ອງການ Query ຂໍ້ມູນ ຈາກ Table ໃຫຍ່ໆຫຼາຍໆເທື່ອ ແລ້ວໄປໃສ່ໃນແຕ່ລະ Temp Table ຈາກນັ້ນເອົາ Table ທັງຫຼາຍເຫຼົ່ານັ້ນມາ Join ກັນອີກ ການເຮັດແບບນີ້ ເປັນການເຮັດໃຫ້ Performance ຮ້າຍກວ່າເກົ່າ ແຕ່ມີວິທີທີ່ດີກວ່າຄື ຄວນຫຼີກລ້ຽງການ Query ຂໍ້ມູນຈາກ Table ຂະໜາດໃຫຍ່ຫຼາຍໆ ເທື່ອ ແຕ່ຄວນຈະ Query ຂໍ້ມູນມາຈາກ Table ໃຫຍ່ນັ້ນ ໃຫ້ມີຂະໜາດຂໍ້ມູນທີ່ນ້ອຍລົງ ແລ້ວຄ່ອຍດຳເນີນການຫຍັງກໍຕາມກັບຂໍ້ມູນເຫຼົ່ານັ້ນຈະດີກວ່າ
- ຫຼີກລ້ຽງການໃຊ້
GUIDs
ພະຍາຍາມຫຼີກລ້ຽງການໃຊ້ Globally Unique Identifiers (GUIDs) ໃນການ Order (ຈັດລຽງ) ຂໍ້ມູນໃນ Table ເພາະຕົວເລກ 16 ບິດທີ່ຖືກສ້າງຂຶ້ນ “ແບບ Random” ຂອງ GUID ອາດເຮັດໃຫ້ເກີດບັນຫາກັບ Table ໄດ້ຫລາຍຂຶ້ນ ຄວນໃຊ້ການ Order ຂໍ້ມູນໂດຍໃຊ້ຄ່າທີ່ສະເພາະເຈາະຈົງໄປເລີຍ ເຊັ່ນ DATE ຫລື IDENTITY ເປັນຕົ້ນ ຈະຊ່ວຍລຸດການເກີດບັນຫາຂອງ Table
- ຢ່າໃຊ້ຄຳສັ່ງ COUNT
ກັບຂໍ້ມູນທັງໝົດໃນ Table
ສົມມຸດເຈົ້າຕ້ອງການເບິ່ງຂໍ້ມູນບາງຢ່າງວ່າ ມີຢູ່ໃນ Table ນັ້ນບໍ ເຊັ່ນ ຢາກເຊັກຂໍ້ມູນຂອງລູກຄ້າ ແນ່ນອນວ່າເຈົ້າຕ້ອງ Query ຂໍ້ມູນຈາກ Table ອອກມາ ແຕ່ເຊື່ອບໍວ່າມີບາງຄົົນທີ່ໃຊ້ຄຳສັ່ງ SELECT COUNT(*) FROM dbo.T1 ເພື່ອເຊັກຂໍ້ມູນວ່າມີຢູ່ບໍ ລອງເບິ່ງຈາກຕົວຢ່າງ
SET @CT = (SELECT COUNT(*) FROM dbo.T1);
If @CT > 0
BEGIN <Do something>
END
ແນ່ນອນວ່າໄດ້ຂໍ້ມູນ ແຕ່ກໍບໍ່ເຫັນຈຳເປັນຕ້ອງເຮັດເຖິງຂະໜາດນັ້ນ ຖ້າຢາກຈະເຊັກ ກໍລອງເຮັດແບບນີ້ເບິ່ງ:
If EXISTS (SELECT 1 FROM dbo.T1)
BEGIN
<Do something>
END
ສະນັ້ນເຮົາບໍ່ຄວນໃຊ້ Count(*) ຖ້າບໍ່ຈຳເປັນ ຫາກເຮົາຕ້ອງການແຕ່ເຊັກຂໍ້ມູນທີ່ເຮົາສົນໃຈ ກໍພຽງດຶງຂໍ້ມູນ Row ນັ້ນອອກມາເທົ່ານັ້ນເອງ ຢ່າງໃນ SQL Server ເອງກໍສາມາດໃຊ້ຄຳສັ່ງ EXISTS ເຂົ້າມາຊ່ວຍໄດ້ ໂດຍຈາກຕົວຢ່າງທີ່ 2 ເຈົ້າຈະໄດ້ຜົນລັບທີ່ວ່ອງໄວກວ່າຕົວຢ່າງທຳອິດຫລາຍ
- ຢ່ານຳ Code
ຄົນອື່ນ ມາໃຊ້ແບບສຸ່ມສີ່ສຸມຫ້າ
ມັນເປັນເລື່ອງງ່າຍຫລາຍໃນການ Copy Code ຂອງຄົນອື່ນມາໃຊ້ງານ ເມື່ອເຈົ້າເຫັນວ່າມັນດຶງຂໍ້ມູນໃນລັກສະນະດຽວກັນມາໃຫ້ເຈົ້າໄດ້ ແຕ່ບັນຫາຄື ການເຮັດແບບນີ້ ເຈົ້າມັກຈະໄດ້ຂໍ້ມູນທີ່ເຈົ້າບໍ່ຕ້ອງການອອກມາດ້ວຍ ແລະເຫຼົ່າ Developer ກໍມັກບໍ່ຄ່ອຍໃຫ້ຄວາມສຳຄັນໃນການຕັດສິ່ງບໍ່ຈຳເປັນພວກນັ້ນອອກດ້ວຍ ສຸດທ້າຍເຈົ້າກໍໄດ້ຂໍ້ມູນທີ່ບໍ່ຈຳເປັນອອກມາຫລວງຫລາຍ ໂດຍທີ່ມາຂອງຜົນລັບທີ່ບໍ່ຈຳເປັນດັ່ງກ່າວ ມັກເກີດຈາກການໃຊ້ OUTER JOIN ຫລືເງື່ອນໄຂພິເສດຕ່າງໆ ໃນ WHERE clause ເຊິ່ງເຈົ້າສາມາດແກ້ໄຂບັນຫານີ້ໄດ້ໂດຍການໃຊ້ສະເພາະ Code ທີ່ກົງກັບຄວາມຕ້ອງການຂອງເຈົ້າເທົ່ານັ້ນເອງ
No comments:
Post a Comment