ຂໍ້ຜິດພາດທົ່ວໄປທີ່ເຮັດໃນການອອກແບບຖານຂໍ້ມູນ

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

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

ຂໍ້ຜິດພາດຖານຂໍ້ມູນ # 1: ເຮັດຊ້ໍາອີກດ້ານຫນຶ່ງໃນຕາຕະລາງ

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

ໂຊກດີ, ເຂດທົ່ງພຽງແມ່ນມັກຈະງ່າຍທີ່ຈະເຫັນ. ພຽງແຕ່ເບິ່ງຕາຕະລາງນີ້:

ຈະເກີດຫຍັງຂຶ້ນເມື່ອຄໍາສັ່ງປະກອບມີສີ່ຜະລິດຕະພັນ? ພວກເຮົາຈະຕ້ອງເພີ່ມພາກສະຫນາມອີກເພື່ອສະຫນັບສະຫນູນຫຼາຍກວ່າສາມຜະລິດຕະພັນ. ແລະຖ້າຫາກວ່າພວກເຮົາໄດ້ສ້າງຄໍາຮ້ອງສະຫມັກຂອງລູກຄ້າທົ່ວຕາຕະລາງເພື່ອຊ່ວຍໃຫ້ພວກເຮົາເຂົ້າຂໍ້ມູນ, ພວກເຮົາອາດຕ້ອງປັບປຸງມັນກັບເຂດຜະລິດຕະພັນໃຫມ່. ແລະເຮັດແນວໃດພວກເຮົາພົບເຫັນຄໍາສັ່ງທັງຫມົດທີ່ມີ Jellybeans ໃນຄໍາສັ່ງ? ພວກເຮົາຈະຖືກບັງຄັບໃຫ້ຄົ້ນຫາທຸກເຂດຜະລິດຕະພັນໃນຕາຕະລາງທີ່ມີຄໍາສັ່ງ SQL ທີ່ອາດຈະຄື: SELECT * FROM ຜະລິດຕະພັນ WHERE Product1 = 'Jelly Beans' OR product2 = 'Jelly Beans' OR product3 = 'Jelly Beans'.

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

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

ຂໍ້ຜິດພາດຖານຂໍ້ມູນ # 2: ຝັງຕາຕະລາງໃນຕາຕະລາງ

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

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

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

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

ຂໍ້ຜິດພາດຖານຂໍ້ມູນ # 3: ການເອົາຂໍ້ມູນສອງຫຼືຫຼາຍຂໍ້ມູນເຂົ້າໄປໃນພາກສະຫນາມດຽວ

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

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

ນີ້ແມ່ນສິ່ງທີ່ຕາຕະລາງຄວນຄື:

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

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

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

ຂໍ້ຜິດພາດຖານຂໍ້ມູນ # 4: ບໍ່ນໍາໃຊ້ຄີຫລັກທີ່ຖືກຕ້ອງ

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

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

ແລະນັ້ນແມ່ນບັນຫາທີ່ນໍາໃຊ້ຂໍ້ມູນຕົວຈິງເປັນມູນຄ່າທີ່ສໍາຄັນ. ມັນສາມາດປ່ຽນແປງ.

ຂໍ້ຜິດພາດຖານຂໍ້ມູນ # 5: ບໍ່ໄດ້ໃຊ້ສົນທິສັນຍາຊື່

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

ພຽງແຕ່ຈິນຕະນາການວ່າວິທີການທີ່ມີຄວາມຫຍຸ້ງຍາກຫຼາຍກວ່ານັ້ນຈະເປັນແນວໃດຖ້າຊື່ຖືກເກັບໄວ້ເປັນ FirstName, LastName ໃນຕາຕະລາງແລະ first_name, last_name ໃນຕາຕະລາງອື່ນ.

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

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

ສົນທິສັນຍາຊື່ວ່າທ່ານເລືອກບໍ່ແມ່ນສິ່ງທີ່ສໍາຄັນຄືຂະບວນການຂອງການເລືອກແລະການຕິດຕາມສົນທິສັນຍາຊື່.

ຂໍ້ຜິດພາດຖານຂໍ້ມູນ # 6: ການດັດສ້າງບໍ່ຖືກຕ້ອງ

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

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

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