Normalization ໃນໂລກທີ່ແທ້ຈິງ
ຖານຂໍ້ມູນປົກກະຕິແມ່ນຫນຶ່ງໃນງົວທີ່ສັກສິດຂອງການພັດທະນາຄໍາຮ້ອງສະຫມັກ. ແນ່ນອນວ່າທຸກໆຫຼັກສູດການຂຽນໂປຼແກຼມທີ່ທ່ານໄດ້ປະຕິບັດຫຼືປື້ມທີ່ທ່ານໄດ້ອ່ານມັກຈະອ່ານຄວາມສໍາຄັນຂອງການ ປົກກະຕິ ຂອງ ຖານຂໍ້ມູນ .
ມັນເປັນເວລາທີ່ຈະທ້າທາຍ truism ວ່າ. ບາງຄັ້ງມັນກໍ່ບໍ່ເຫມາະສົມທີ່ຈະປ່ຽນຊື່ຖານຂໍ້ມູນຂອງທ່ານ!
ເວລາທີ່ທ່ານຄວນປະກະຕິ?
ຖານຂໍ້ມູນປົກກະຕິປົກປ້ອງຄວາມຖືກຕ້ອງຂອງຂໍ້ມູນຂອງທ່ານ. ມັນເປັນຄວາມຄິດທີ່ດີໃນຫຼາຍໆກໍລະນີ, ແລະທ່ານຄວນຈະເລີ່ມຕົ້ນການອອກແບບຖານຂໍ້ມູນທີ່ມີຄວາມລະມັດລະວັງ. ຖ້າທ່ານສາມາດປົກກະຕິຖານຂໍ້ມູນຂອງທ່ານ, ໃຫ້ມັນ! ໃນຄວາມເປັນຈິງ, ນີ້ແມ່ນຄໍາແນະນໍາບາງຢ່າງກ່ຽວກັບວິທີການປົກກະຕິຂອງຖານຂໍ້ມູນຂອງທ່ານໃນເວັບໄຊນີ້:
- ການຕັ້ງຖານຂໍ້ມູນຂອງທ່ານໃນຮູບແບບປົກກະຕິທໍາອິດ (1NF)
- ການວາງຖານຂໍ້ມູນຂອງທ່ານໃນຮູບແບບປົກກະຕິທີສອງ (2NF)
- ການວາງຖານຂໍ້ມູນຂອງທ່ານໃນຮູບແບບປົກກະຕິທີສາມ (2NF)
ເສັ້ນທາງລຸ່ມແມ່ນວ່າທ່ານ ຄວນ ປະຕິບັດຕາມຖານຂໍ້ມູນຂອງທ່ານແບບປົກກະຕິເວັ້ນເສຍແຕ່ວ່າທ່ານມີເຫດຜົນທີ່ດີທີ່ຈະບໍ່ເຮັດແນວນັ້ນ. ປົກກະຕິແມ່ນປົກກະຕິການອອກແບບການອອກແບບສຽງ. ມັນຫຼຸດຜ່ອນຂໍ້ມູນຊ້ໍາຊ້ອນ, ປະສິດທິພາບຂອງການເຮັດວຽກແລະຫຼຸດຜ່ອນຄວາມເປັນໄປໄດ້ທີ່ທ່ານຈະມີບັນຫາຄວາມສົມບູນຂອງຂໍ້ມູນທີ່ເກີດຂື້ນຈາກການເກັບຂໍ້ມູນດຽວກັນຢູ່ໃນຖານທີ່ແຕກຕ່າງກັນຂອງຖານຂໍ້ມູນຂອງທ່ານ.
ບາງເຫດຜົນທີ່ດີບໍ່ໃຫ້ທໍາມະດາ
ທີ່ເວົ້າວ່າ, ມີບາງເຫດຜົນທີ່ດີທີ່ຈະບໍ່ທໍາມະດາຖານຂໍ້ມູນຂອງທ່ານ. ຂໍໃຫ້ເບິ່ງບາງຄົນ:
- ຮ່ວມກັນມີລາຄາແພງ . Normalizing ຖານຂໍ້ມູນຂອງທ່ານມັກຈະມີການສ້າງ lots ຂອງຕາຕະລາງ. ໃນຄວາມເປັນຈິງ, ທ່ານສາມາດລົມກັບສິ່ງທີ່ທ່ານຄິດວ່າຄວນເປັນແບບສອບຖາມທີ່ງ່າຍດາຍເຊິ່ງກວມເອົາຫ້າຫຼື 10 ຕາຕະລາງ. ຖ້າທ່ານເຄີຍພະຍາຍາມເຮັດການເຂົ້າຮ່ວມຫ້າໂຕະ, ທ່ານຮູ້ວ່າມັນເຮັດວຽກຢູ່ໃນຫຼັກການ, ແຕ່ວ່າມັນລ້າໆໃນການປະຕິບັດ. ຖ້າທ່ານກໍາລັງສ້າງຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ທີ່ອີງໃສ່ການສອບຖາມຫຼາຍຄັ້ງ, ທ່ານອາດຈະຄິດວ່າທ່ານຄິດວ່າ "ຖ້າຖານຂໍ້ມູນນີ້ບໍ່ຖືກຕ້ອງຕາມປົກກະຕິ!" ເມື່ອທ່ານໄດ້ຍິນຄວາມຄິດທີ່ຢູ່ໃນຫົວຂອງທ່ານ, ມັນເປັນເວລາທີ່ດີສໍາລັບ ພິຈາລະນາ denormalizing. ຖ້າທ່ານສາມາດຕິດທັງຫມົດຂອງຂໍ້ມູນທີ່ນໍາໃຊ້ໂດຍການສອບຖາມທີ່ເຂົ້າມາໃນຕາຕະລາງດຽວໂດຍບໍ່ມີຄວາມອັນຕະລາຍຕໍ່ຄວາມສົມບູນຂອງຂໍ້ມູນຂອງທ່ານ, ໃຫ້ມັນ! ເປັນ rebel ແລະ denormalize ຖານຂໍ້ມູນຂອງທ່ານ. ທ່ານຈະບໍ່ເບິ່ງຄືນ!
- ການອອກແບບປົກກະຕິແມ່ນມີຄວາມຫຍຸ້ງຍາກ . ຖ້າທ່ານກໍາລັງເຮັດວຽກຮ່ວມກັບແຜນທີ່ຖານຂໍ້ມູນສະລັບສັບຊ້ອນ, ທ່ານອາດຈະພົບເຫັນຕົວທ່ານເອງໃສ່ຫົວຂອງທ່ານຕໍ່ກັບຕາຕະລາງຫຼາຍກວ່າຄວາມສັບສົນຂອງການປົກກະຕິ. ໃນຖານະເປັນກົດລະບຽບງ່າຍໆ, ຖ້າທ່ານກໍາລັງໃຊ້ເວລາທັງຫມົດໃນວັນທີພະຍາຍາມຄົ້ນຫາວິທີທີ່ຈະຍ້າຍໄປຫາຮູບແບບປົກກະຕິທີ່ສີ່, ທ່ານອາດຈະໄດ້ຮັບການປົກກະຕິເກີນໄປ. ກັບຄືນໄປບ່ອນແລະຖາມຕົວເອງວ່າມັນກໍ່ຈະມີມູນຄ່າຕໍ່ເນື່ອງ.
- ໄວແລະເປື້ອນຄວນຈະໄວແລະເປື້ອນ . ຖ້າທ່ານພຽງແຕ່ພັດທະນາຮູບແບບຕົ້ນສະບັບ, ພຽງແຕ່ເຮັດສິ່ງທີ່ເຮັດວຽກໄດ້ໄວ. ຈິງໆ ບໍ່ເປັນຫຍັງ. ການພັດທະນາແອບພິເຄຊັນຢ່າງລວດໄວແມ່ນບາງຄັ້ງສໍາຄັນກວ່າການອອກແບບທີ່ສວຍງາມ. ພຽງແຕ່ຈື່ກັບຄືນໄປບ່ອນແລະເບິ່ງຮູບແບບຂອງທ່ານຢ່າງລະມັດລະວັງເມື່ອທ່ານພ້ອມທີ່ຈະຍ້າຍອອກຈາກຂັ້ນຕອນການທົດລອງ. ລາຄາທີ່ທ່ານຈ່າຍສໍາລັບການອອກແບບຖານຂໍ້ມູນທີ່ລວດໄວແລະເປື້ອນແມ່ນວ່າທ່ານອາດຈໍາເປັນຕ້ອງຖິ້ມມັນແລະເລີ່ມຕົ້ນໃນເວລາທີ່ມັນເປັນເວລາທີ່ຈະສ້າງສໍາລັບການຜະລິດ.
- ຖ້າທ່ານກໍາລັງໃຊ້ຖານຂໍ້ມູນ NoSQL , ແບບປົກກະຕິແບບດັ້ງເດີມບໍ່ແມ່ນຄວາມຕ້ອງການ. ແທນທີ່ຈະ, ການອອກແບບຖານຂໍ້ມູນຂອງທ່ານໂດຍໃຊ້ຮູບແບບ BASE ເຊິ່ງຫຼາຍກວ່າການໃຫ້ອະໄພ. ນີ້ແມ່ນມີຜົນປະໂຫຍດໃນເວລາທີ່ທ່ານເກັບຮັກສາຂໍ້ມູນທີ່ບໍ່ມີໂຄງສ້າງເຊັ່ນອີ, ຮູບພາບຫຼືວິດີໂອ.
ບາງຄໍາເວົ້າຂອງຄວາມລະມັດລະວັງ
ການປົກກະຕິຂອງຖານຂໍ້ມູນໂດຍທົ່ວໄປແມ່ນເປັນຄວາມຄິດທີ່ດີ. ທ່ານຄວນພະຍາຍາມປະຕິບັດຕາມຫຼັກການຂອງການປົກກະຕິໃນເວລາທີ່ມັນເບິ່ງຄືວ່າເປັນເຫດຜົນທີ່ຈະເຮັດແນວນັ້ນ. ແຕ່ຖ້າຕົວຊີ້ວັດທັງຫມົດຊີ້ໃຫ້ເຫັນວ່າການປະຕິບັດຕາມປົກກະຕິແມ່ນສັບສົນເກີນໄປທີ່ຈະປະຕິບັດ, ພິຈາລະນາວິທີການທີ່ຈະເຮັດວຽກເຮັດໃນຂະນະທີ່ຍັງປົກປ້ອງຂໍ້ມູນຂອງທ່ານ.
ສຸດທ້າຍ - ຖ້າທ່ານເລືອກທີ່ຈະຫຼີກເວັ້ນຈາກກົດລະບຽບຂອງການປົກກະຕິ, ໃຫ້ລະມັດລະວັງກ່ຽວກັບວິທີການປະຕິບັດຄວາມຖືກຕ້ອງຂອງຖານຂໍ້ມູນ. ຖ້າທ່ານເກັບຂໍ້ມູນທີ່ບໍ່ຈໍາເປັນ, ໃຫ້ຄໍາແນະນໍາແລະການຄວບຄຸມອື່ນເພື່ອໃຫ້ແນ່ໃຈວ່າຂໍ້ມູນຄົງຢູ່.