ຄອມພິວເຕີ, ດໍາເນີນໂຄງການ
ຊ້າຍເຂົ້າຮ່ວມ (SQL) - ຕົວຢ່າງ, ການອະທິບາຍລາຍລະອຽດ, ການນໍາໃຊ້ຄວາມຜິດພາດໄດ້
ໃນຖານຂໍ້ມູນເຊີງສໍາພັນໃດຫນຶ່ງທີ່ແທ້ຈິງ, ຂໍ້ມູນທັງຫມົດໄດ້ຖືກແຈກຢາຍໃນຕາຕະລາງທີ່ແຍກຕ່າງຫາກ. ຈໍານວນຫຼາຍຂອງຕາຕະລາງແມ່ນກໍານົດໄວ້ໃນໂຄງການສື່ສານທີ່ມີກັນແລະກັນ. ຢ່າງໃດກໍຕາມ, ດ້ວຍຄວາມຊ່ວຍເຫລືອຂອງ Sql ສອບຖາມ ວ່າມັນເປັນໄປໄດ້ຂ້ອນຂ້າງຈະເອົາໃຈໃສ່ການເຊື່ອມຕໍ່ລະຫວ່າງຂໍ້ມູນ, ບໍ່ຝັງໃນວົງຈອນຂອງ. ນີ້ແມ່ນເຮັດໄດ້ໂດຍການປະຕິບັດການເຊື່ອມຕໍ່ເຂົ້າຮ່ວມ, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານເພື່ອສ້າງຄວາມສໍາພັນລະຫວ່າງຈໍານວນຂອງຕາຕະລາງໃດຫນຶ່ງ, ແລະແມ້ກະທັ້ງເຊື່ອມຕໍ່ຂໍ້ມູນຂ່າວສານກົດວ່າແຕກຕ່າງ.
ບົດຄວາມນີ້ຈະສົນທະນາໂດຍສະເພາະກ່ຽວກັບການນອກຊ້າຍເຂົ້າຮ່ວມ. ກ່ອນທີ່ຈະດໍາເນີນໄປເຖິງຄໍາອະທິບາຍປະເພດຂອງການເຊື່ອມຕໍ່ນີ້, ເພີ່ມໃນຕາຕະລາງຖານຂໍ້ມູນຈໍານວນຫນຶ່ງ.
ກະກຽມຕາຕະລາງທີ່ຈໍາເປັນ
ສໍາລັບຕົວຢ່າງ, ໃນຖານຂໍ້ມູນຂອງພວກເຮົາ, ບໍ່ມີຂໍ້ມູນກ່ຽວກັບປະຊາຊົນແລະຊທີ່ແທ້ຈິງຂອງເຂົາເຈົ້າ. ສະຫຼຸບອີງໃສ່ສາມຕາຕະລາງ: ປະຊາຊົນ (ປະຊາຊົນ), Realty (ຊທີ່ແທ້ຈິງ), Realty_peoples (ຄວາມສໍາພັນຕາຕະລາງ, ປະຊາຊົນຜູ້ທີ່ຈາກສິ່ງທີ່ຄຸນສົມບັດເປັນ). ສົມມຸດຂໍ້ມູນດັ່ງຕໍ່ໄປນີ້ເກັບຮັກສາໄວ້ໃນຕາຕະລາງຂອງປະຊາຊົນ:
ປະຊາຊົນ | ||||
id | L_name | F_name | Middle_name | ວັນເດືອນປີເກີດ |
1 | Ivanova | Daria |
B. | 07/16/2000 |
2 | pugin | Vladislav | Nikolaevich | 29.01.1986 |
3 | Evgenin | ອະເລັກຊານເດີ | Federovich | 04/30/1964 |
4 | Annina | ຮັກ | P. | 31.12.1989 |
5 | Gerasimovsky | ຫວັງວ່າ | P. | 14.03.1992 |
6 | Gerasimovsky | Oleg | Albertovich | 01/29/1985 |
7 | Sukhanovskaya | ຄະນະລູກຂຸນ | A. | 09/25/1976 |
8 | Sukhanovskaya | Julia | Y. | 01.10.2001 |
ຊທີ່ແທ້ຈິງ:
Realty | |
id | ທີ່ຢູ່ |
1 | Arkhangelsk, ul. Voronin, d. 7, kv.6 |
2 | Arkhangelsk, ul. Severodvinskaya, d. 84, q. 9 BR. 5 |
3 | ພາກ Arkhangelsk, Severodvinsk, st. Lenin, d. 134, q. 85 |
4 | ພາກ Arkhangelsk, Novodvinsk, ul. Proletarshaya, d. 16, q. 137 |
5 | Arkhangelsk, pl. Terekhina, d. 89, q. 13 |
ປະຊາຊົນພົວພັນ - ຄຸນສົມບັດ:
Realty_peoples | ||
id_peoples | id_realty | ປະເພດ |
7 | 3 | ຄວາມເປັນເຈົ້າຂອງຮ່ວມມືລະຫວ່າງທັງຫມົດ |
8 | 3 | ຄວາມເປັນເຈົ້າຂອງຮ່ວມມືລະຫວ່າງທັງຫມົດ |
3 | 5 | ຄຸນສົມບັດ |
7 | 1 | ຄຸນສົມບັດ |
5 | 4 | ພາກສ່ວນທົ່ວໄປ |
6 | 4 | ພາກສ່ວນທົ່ວໄປ |
ໄວ້ເຂົ້າຮ່ວມ (Sql) - ລາຍລະອຽດ
ປະສົມປະໄວ້ມີ syntax ດັ່ງຕໍ່ໄປນີ້:
Table_A ຊ້າຍເຂົ້າຮ່ວມ table_B [{ON ຢາ} | {ໃຊ້ spisok_ ກັບ tolbtsov}] |
ແລະ schematically ເປັນດັ່ງຕໍ່ໄປນີ້:
ແລະການສະແດງອອກນີ້ແມ່ນໄດ້ແປເປັນ "ເລືອກທັງຫມົດ, ໂດຍບໍ່ມີການຍົກເວັ້ນ, ເສັ້ນທາງຂອງຕາຕະລາງ A ແລະຕາຕະລາງ B ທີ່ຈະສະແດງພຽງແຕ່ແຖວເກັດທີ່ຢູ່ໂຍບາຍຄວາມລັບຂອງຢາໄດ້. ຖ້າຫາກວ່າຕາຕະລາງດັ່ງກ່າວໄດ້ພົບເຫັນຢູ່ໃນຕາຕະລາງ string ສໍາລັບຄູ່ A, ຫຼັງຈາກນັ້ນຕື່ມຂໍ້ມູນໃສ່ຖັນທີ່ໄດ້ຮັບ Null - ຄ່າ ".
ສ່ວນຫຼາຍມັກ, ໃນເວລາທີ່ການເຊື່ອມຕໍ່ໄວ້ແມ່ນຊີ້ບອກກ່ຽວກັບ, ການນໍາໃຊ້ຖືກນໍາໃຊ້ພຽງແຕ່ໃນເວລາທີ່ຊື່ຄໍລໍາທີ່ມີການວາງແຜນເພື່ອເຮັດໃຫ້ການເຊື່ອມຕໍ່ແມ່ນດຽວກັນ.
ຊ້າຍເຂົ້າຮ່ວມ - ຕົວຢ່າງຂອງການນໍາໃຊ້
ມີການເຊື່ອມຕໍ່ຂອງເບື້ອງຊ້າຍເປັນໄດ້ພວກເຮົາສາມາດເບິ່ງ, ປະຊາຊົນທັງຫມົດຈາກບັນຊີລາຍຊື່ຖ້າຫາກວ່າມີປະຊາຊົນຄຸນສົມບັດ. ເພື່ອເຮັດສິ່ງນີ້ຊ້າຍເຂົ້າຮ່ວມຕົວຢ່າງແບບສອບຖາມ sql:
ຄົນທີ່ຖືກເລືອກ. *, Realty_peoples.id_realty, Realty_peoples.type ຈາກປະຊາຊົນຊ້າຍເຂົ້າຮ່ວມ Realty_peoples ON Peoples.id = Realty_peoples.id_peoples; |
ອີງໃສ່ຜົນດັ່ງຕໍ່ໄປນີ້:
Query1 | ||||||
id | L_name | F_name | Middle_name | ວັນເດືອນປີເກີດ | id_realty | ປະເພດ |
1 | Ivanova | Daria | B. | 07/16/2000 | ||
2 | pugin | Vladislav | Nikolaevich | 29.01.1986 | ||
3 | Evgenin | ອະເລັກຊານເດີ | Federovich | 04/30/1964 | 5 | ຄຸນສົມບັດ |
4 | Annina | ຮັກ | P. | 31.12.1989 | ||
5 | Gerasimovsky | ຫວັງວ່າ | P. | 14.03.1992 | 4 | ພາກສ່ວນທົ່ວໄປ |
6 | Gerasimovsky | Oleg | Albertovich | 01/29/1985 | 4 | ພາກສ່ວນທົ່ວໄປ |
7 | Sukhanovskaya | ຄະນະລູກຂຸນ | A. | 09/25/1976 | 1 | ຄຸນສົມບັດ |
7 | Sukhanovskaya | ຄະນະລູກຂຸນ | A. | 09/25/1976 | 3 | ຄວາມເປັນເຈົ້າຂອງຮ່ວມມືລະຫວ່າງທັງຫມົດ |
8 | Sukhanovskaya | Julia | Y. | 01.10.2001 | 3 | ຄວາມເປັນເຈົ້າຂອງຮ່ວມມືລະຫວ່າງທັງຫມົດ |
ດັ່ງທີ່ພວກເຮົາເບິ່ງ, Ivanova Darya pugin Vladislav ແລະ Anninoy Lyubovi No ລົງທະບຽນສິດທິຊທີ່ແທ້ຈິງ.
ແລະສິ່ງທີ່ພວກເຮົາຈະໄດ້ຮັບ, ການນໍາໃຊ້ໃນເຂົ້າຮ່ວມພາຍໃນເຂົ້າຮ່ວມ? ຂະນະທີ່ທ່ານຮູ້ຈັກ, ມັນບໍ່ໄດ້ລວມເອົາແຖວທີ່ບໍ່ແມ່ນກົງກັນ, ສະນັ້ນສາມອອກຈາກຕົວຢ່າງສຸດທ້າຍຂອງພວກເຮົາພຽງແຕ່ຈະໄດ້ຮັບການຫຼຸດລົງ:
Query1 | ||||||
id | L_name | F_name | Middle_name | ວັນເດືອນປີເກີດ | id_realty | ປະເພດ |
3 | Evgenin | ອະເລັກຊານເດີ | Federovich | 04/30/1964 | 5 | ຄຸນສົມບັດ |
5 | Gerasimovsky | ຫວັງວ່າ | P. | 14.03.1992 | 4 | ພາກສ່ວນທົ່ວໄປ |
6 | Gerasimovsky | Oleg | Albertovich | 01/29/1985 | 4 | ພາກສ່ວນທົ່ວໄປ |
7 | Sukhanovskaya | ຄະນະລູກຂຸນ | A. | 09/25/1976 | 1 | ຄຸນສົມບັດ |
7 | Sukhanovskaya | ຄະນະລູກຂຸນ | A. | 09/25/1976 | 3 | ຄວາມເປັນເຈົ້າຂອງຮ່ວມມືລະຫວ່າງທັງຫມົດ |
8 | Sukhanovskaya | Julia | Y. | 01.10.2001 | 3 | ຄວາມເປັນເຈົ້າຂອງຮ່ວມມືລະຫວ່າງທັງຫມົດ |
ມັນຈະເບິ່ງຄືວ່າສະບັບພາສາທີສອງຍັງພົບສະພາບຂອງບັນຫາຂອງພວກເຮົາໄດ້. ຢ່າງໃດກໍຕາມ, ຖ້າຫາກວ່າພວກເຮົາເລີ່ມຕົ້ນທີ່ຈະຕິດໃສ່ຄົນອື່ນ, ແລະຕາຕະລາງອື່ນ, ສາມປະຊາຊົນຈາກຜົນໄດ້ຮັບແລ້ວຫມົດແກ້ໄຂບໍ່ໄດ້. ຊ້າຍແລະຂວາການເຊື່ອມຕໍ່ດັ່ງນັ້ນ, ໃນການປະຕິບັດ, ໃນເວລາທີ່ສົມທົບຕາຕະລາງຫຼາຍຫຼາຍມັກຫຼາຍການນໍາໃຊ້ກ່ວາພາຍໃນເຂົ້າຮ່ວມ.
ຈະສືບຕໍ່ຊອກຫາໄປທາງຊ້າຍເຂົ້າຮ່ວມຕົວຢ່າງ sql. ແນບຕາຕະລາງທີ່ມີຢູ່ເຮືອນຂອງພວກເຮົາເປັນ:
ຄົນທີ່ຖືກເລືອກ. *, Realty_peoples.id_realty, Realty_peoples.type, Realty.address ຈາກປະຊາຊົນ ຊ້າຍຮ່ວມ Realty_peoples ON Peoples.id = Realty_peoples.id_peoples ຊ້າຍຮ່ວມ Realty ON Realty.id = Realty_peoples.id_realty |
ໃນປັດຈຸບັນພວກເຮົາໄດ້ຮັບການບໍ່ພຽງແຕ່ປະເພດຂອງກົດຫມາຍວ່າດ້ວຍ, ແຕ່ຍັງທີ່ຢູ່ຂອງຊທີ່ແທ້ຈິງ:
Query1 | |||||||
id | L_name | F_name | Middle_name | ວັນເດືອນປີເກີດ | id_realty | ປະເພດ | ທີ່ຢູ່ |
1 | Ivanova | Daria | B. | 07/16/2000 | |||
2 | pugin | Vladislav | Nikolaevich | 29.01.1986 | |||
3 | Evgenin | ອະເລັກຊານເດີ | Federovich | 04/30/1964 | 5 | ຄຸນສົມບັດ | Arkhangelsk, pl. Terekhina, d. 89, q. 13 |
4 | Annina | ຮັກ | P. | 31.12.1989 | |||
5 | Gerasimovsky | ຫວັງວ່າ | P. | 14.03.1992 | 4 | ພາກສ່ວນທົ່ວໄປ | ພາກ Arkhangelsk, Novodvinsk, ul. Proletarshaya, d. 16, q. 137 |
6 | Gerasimovsky | Oleg | Albertovich | 01/29/1985 | 4 | ພາກສ່ວນທົ່ວໄປ | ພາກ Arkhangelsk, Novodvinsk, ul. Proletarshaya, d. 16, q. 137 |
7 | Sukhanovskaya | ຄະນະລູກຂຸນ | A. | 09/25/1976 | 3 | ຄວາມເປັນເຈົ້າຂອງຮ່ວມມືລະຫວ່າງທັງຫມົດ | ພາກ Arkhangelsk, Severodvinsk, st. Lenin, d. 134, q. 85 |
7 | Sukhanovskaya | ຄະນະລູກຂຸນ | A. | 09/25/1976 | 1 | ຄຸນສົມບັດ | Arkhangelsk, ul. Voronin, d. 7, kv.6 |
8 | Sukhanovskaya | Julia | Y. | 01.10.2001 | 3 | ຄວາມເປັນເຈົ້າຂອງຮ່ວມມືລະຫວ່າງທັງຫມົດ |
ພາກ Arkhangelsk, Severodvinsk, st. Lenin, d. 134, q. 85 |
ຊ້າຍເຂົ້າຮ່ວມ - ການນໍາໃຊ້ປົກກະຕິຂອງຄວາມຜິດພາດ: ຕາຕະລາງລະບຽບການທີ່ບໍ່ຖືກຕ້ອງ
ຄວາມຜິດພາດພື້ນຖານໄດ້ຢູ່ນອກຊ້າຍເຂົ້າຮ່ວມຕາຕະລາງ, ສອງ:
- ຖືກຕ້ອງເລືອກຄໍາສັ່ງຂອງຕາຕະລາງສໍາລັບການທີ່ຂໍ້ມູນໄດ້ສູນເສຍ.
- ບ່ອນທີ່ຄວາມຜິດພາດໃນເວລາທີ່ການນໍາໃຊ້ການສອບຖາມກັບເຂົ້າຮ່ວມຕາຕະລາງ.
ພິຈາລະນາຄວາມຜິດພາດຄັ້ງທໍາອິດ. ກ່ອນທີ່ຈະຕັດສິນໃຈບັນຫາໃດຫນຶ່ງຄວນໄດ້ຮັບການເຂົ້າໃຈຢ່າງຈະແຈ້ງວ່າສິ່ງທີ່ພວກເຮົາຕ້ອງການເພື່ອໃຫ້ໄດ້ຮັບໃນທີ່ສຸດ. ໃນຕົວຢ່າງຂ້າງເທິງນີ້, ພວກເຮົາໄດ້ທຸກຫນຶ່ງດຽວຂອງປະຊາຊົນ, ແຕ່ສູນເສຍຂໍ້ມູນກ່ຽວກັບວັດຖຸຕ່ໍາກວ່າຈໍານວນ 2, ທີ່ເຈົ້າຂອງບໍ່ໄດ້ພົບເຫັນການຄົບຖ້ວນ.
ຖ້າຫາກວ່າພວກເຮົາໄດ້ຍ້າຍຕາຕະລາງໃນການສອບຖາມໃນບາງທ້ອງຖິ່ນ, ແລະຈະເລີ່ມຕົ້ນກັບ« ... From Realty ໄວ້ເຂົ້າຮ່ວມປະຊາຊົນ ... »ຫນຶ່ງຄຸນສົມບັດໃດຫນຶ່ງ, ພວກເຮົາຈະບໍ່ໄດ້ສູນເສຍ, ທ່ານຈະໄດ້ບອກກ່ຽວກັບປະຊາຊົນ.
ແຕ່ບໍ່ຕ້ອງຢ້ານກົວຂອງການເຊື່ອມຕໍ່ທາງດ້ານຊ້າຍສະຫລັບໄປຢ່າງເຕັມທີ່ພາຍນອກ, ເຊິ່ງລວມຢູ່ໃນຜົນໄດ້ຮັບແລະໂຍບາຍຄວາມລັບ, ແລະບໍ່ສາຍໂຍບາຍຄວາມລັບ.
ຫຼັງຈາກທີ່ທັງຫມົດ, ປະລິມານຂອງຕົວຢ່າງທີ່ ມັກຈະມີຂະຫນາດໃຫຍ່ຫຼາຍ, ແລະຂໍ້ມູນເພີ່ມເຕີມແມ່ນ useless ຕົວຈິງ. ການທົດສອບຕົ້ນຕໍ - ທີ່ຈະຄິດອອກສິ່ງທີ່ທ່ານຕ້ອງການເພື່ອໃຫ້ໄດ້ຮັບຜົນເປັນ: ຂອງທັງຫມົດປະຊາຊົນທີ່ມີບັນຊີລາຍຊື່ຂອງຄຸນສົມບັດທີ່ມີຢູ່ຂອງເຂົາເຈົ້າຫຼືບັນຊີລາຍຊື່ຄຸນສົມບັດທັງຫມົດທີ່ມີເຈົ້າຂອງຂອງເຂົາເຈົ້າ (ຖ້າມີ) ໄດ້.
ຊ້າຍເຂົ້າຮ່ວມ - ການນໍາໃຊ້ປົກກະຕິຂອງຄວາມຜິດພາດ: ການຮ້ອງຂໍຖືກຕ້ອງໃນເວລາທີ່ການສ້າງຕັ້ງສະພາບການໃນກໍລະນີທີ່
ຄວາມຜິດພາດທີ່ສອງແມ່ນກ່ຽວຂ້ອງກັບການສູນເສຍຂອງຂໍ້ມູນ, ແລະບໍ່ສະເຫມີໄປປາກົດຂື້ນທັນທີ.
ໃຫ້ຂອງໄປສອບຖາມໃນເວລາທີ່ພວກເຮົາປະໄວ້ທາງເຊື່ອມຕໍ່ໄດ້ຮັບຂໍ້ມູນສໍາລັບທຸກຄົນແລະຄຸນສົມບັດທີ່ມີຢູ່ແລ້ວຂອງເຂົາເຈົ້າ. ຈືຂໍ້ມູນການດັ່ງຕໍ່ໄປນີ້ກັບຊ້າຍເຂົ້າຮ່ວມຕົວຢ່າງ sql:
ຈາກປະຊາຊົນຊ້າຍເຂົ້າຮ່ວມ Realty_peoples ON Peoples.id = Realty_peoples.id_peoples; |
ສົມມຸດວ່າພວກເຮົາຕ້ອງການທີ່ຈະອະທິບາຍຄໍາຮ້ອງຂໍແລະບໍ່ໄດ້ຜົນຜະລິດຂໍ້ມູນ, ບ່ອນທີ່ປະເພດຂອງກົດຫມາຍ - "ຄຸນສົມບັດ". ຖ້າຫາກວ່າພວກເຮົາພຽງແຕ່ເພີ່ມເຕີມ, ການນໍາໃຊ້ຊ້າຍເຂົ້າຮ່ວມ sql, ຍົກຕົວຢ່າງຂອງສະພາບດັ່ງຕໍ່ໄປນີ້ເປັນ:
...
ບ່ອນທີ່ຊະນິດ <> "ຄຸນສົມບັດ" |
ພວກເຮົາຈະສູນເສຍຂໍ້ມູນທີ່ກ່ຽວກັບປະຊາຊົນຜູ້ທີ່ມີຄຸນສົມບັດບໍ່ມີ, ເພາະວ່າ Null ຄ່າ null ບໍ່ໄດ້ປຽບທຽບດັ່ງຕໍ່ໄປນີ້:
Query1 | ||||||
id | L_name | F_name | Middle_name | ວັນເດືອນປີເກີດ | id_realty | ປະເພດ |
5 | Gerasimovsky | ຫວັງວ່າ | P. | 14.03.1992 | 4 | ພາກສ່ວນທົ່ວໄປ |
6 | Gerasimovsky | Oleg | Albertovich | 01/29/1985 | 4 | ພາກສ່ວນທົ່ວໄປ |
7 | Sukhanovskaya | ຄະນະລູກຂຸນ | A. | 09/25/1976 | 3 | ຄວາມເປັນເຈົ້າຂອງຮ່ວມມືລະຫວ່າງທັງຫມົດ |
8 | Sukhanovskaya | Julia | Y. | 01.10.2001 | 3 | ຄວາມເປັນເຈົ້າຂອງຮ່ວມມືລະຫວ່າງທັງຫມົດ |
ເພື່ອປ້ອງກັນຄວາມຜິດພາດເກີດຂຶ້ນສໍາລັບເຫດຜົນດັ່ງກ່າວນີ້, ມັນເປັນທີ່ດີທີ່ສຸດທີ່ຈະກໍາຫນົດເງື່ອນໄຂການຄັດເລືອກໃນທັນທີຕາມການເຊື່ອມຕໍ່. ພວກເຮົາໄດ້ແນະນໍາໃຫ້ພິຈາລະນາດັ່ງຕໍ່ໄປນີ້ກັບຊ້າຍເຂົ້າຮ່ວມຕົວຢ່າງ sql.
ຄົນທີ່ຖືກເລືອກ. *, Realty_peoples.id_realty, Realty_peoples.type ຈາກປະຊາຊົນ ຊ້າຍຮ່ວມ Realty_peoples ON (Peoples.id = Realty_peoples.id_peoples ແລະຊະນິດ <> "ຄຸນສົມບັດ") |
ຜົນໄດ້ຮັບຈະເປັນດັ່ງຕໍ່ໄປນີ້:
Query1 | ||||||
id | L_name | F_name | Middle_name | ວັນເດືອນປີເກີດ | id_realty | ປະເພດ |
1 | Ivanova | Daria | B. | 07/16/2000 | ||
2 | pugin | Vladislav | Nikolaevich | 29.01.1986 | ||
3 | Evgenin | ອະເລັກຊານເດີ | Federovich | 04/30/1964 | ||
4 | Annina | ຮັກ | P. | 31.12.1989 | ||
5 | Gerasimovsky | ຫວັງວ່າ | P. | 14.03.1992 | 4 | ພາກສ່ວນທົ່ວໄປ |
6 | Gerasimovsky | Oleg | Albertovich | 01/29/1985 | 4 | ພາກສ່ວນທົ່ວໄປ |
7 | Sukhanovskaya | ຄະນະລູກຂຸນ | A. | 09/25/1976 | 3 | ຄວາມເປັນເຈົ້າຂອງຮ່ວມມືລະຫວ່າງທັງຫມົດ |
8 | Sukhanovskaya | Julia | Y. | 01.10.2001 | 3 | ຄວາມເປັນເຈົ້າຂອງຮ່ວມມືລະຫວ່າງທັງຫມົດ |
ດັ່ງນັ້ນ, ໂດຍປະຕິບັດຕາມໄດ້ງ່າຍດາຍໄປທາງຊ້າຍເຂົ້າຮ່ວມຕົວຢ່າງ sql, ພວກເຮົາໄດ້ຮັບບັນຊີລາຍຊື່ຂອງປະຊາຊົນທັງຫມົດ, ການເຄື່ອນຍ້າຍໃນຕໍ່ຫນ້າ, ຫນຶ່ງໃນຄຸນສົມບັດເຫຼົ່ານີ້ຢູ່ໃນການສະເຫມີພາບ / ຄວາມເປັນເຈົ້າຂອງຮ່ວມກັນ.
ເປັນການສະຫລຸບຂ້າພະເຈົ້າຢາກຈະເນັ້ນຫນັກໃສ່ອີກເທື່ອຫນຶ່ງວ່າເປັນຕົວຢ່າງຂອງຂໍ້ມູນຈາກຖານຂໍ້ມູນທີ່ຈໍາເປັນຕ້ອງໄດ້ຮັບການປະຕິບັດຄວາມຮັບຜິດຊອບ. nuances ຫຼາຍເປີດຢູ່ທາງຫນ້າຂອງພວກເຮົາກັບຊ້າຍເຂົ້າຮ່ວມຍົກຕົວຢ່າງງ່າຍດາຍ sql, ຄໍາອະທິບາຍຂອງທີ່ຫນຶ່ງ - ກ່ອນທີ່ທ່ານຈະເລີ່ມຕົ້ນທີ່ຈະຂຽນເຖິງແມ່ນວ່າການສອບຖາມພື້ນຖານ, ທ່ານຕ້ອງລະມັດລະວັງທີ່ຈະເຂົ້າໃຈສິ່ງທີ່ພວກເຮົາຕ້ອງການເພື່ອໃຫ້ໄດ້ຮັບໃນທີ່ສຸດ. ໂຊກດີ!
Similar articles
Trending Now