แล้วอีกอันนึงครับ

แบบที่ 1 ดีกว่าครับ แต่ให้ตัด AgricultureTypeCode ออกจาก TB_Agriculture

แบบที่ 1 มีปัญหาตรงที่ว่าถ้าผมจะเพิ่มชื่อ หรือว่า ลบชื่อพืชออกจากตารางผมจะใช้วิธีแบบไหนครับ คือตามที่พี่ PichaiTC แนะนำมา
คือตัด
            AgriculturCode ออกจาก TB_Agricultur
แล้ว
ต้องนำ AgriculturCode ใน TB_AgriculturType มา Relate กับ
            AgriculturCode ใน TB_Plant แทน รึปล่าวครับ

ขอรบกวนสอบถามอีกอย่างครับ คือ TB_Plant ที่ผมทำ จะรวมรายชื่อพืชทั้งหมดที่มีเรียงตามรหัสครับ ประมาณ..
RI001
RI002
RI003
.
.
RI100
VE001
VE002
VE003
.
.
VE100
HE001
HE002
HE003
.
.
HE100

หากผมต้องการจะลบรายชื่อพืชออก หรือว่า เพิ่มชื่อพืช ผมต้องทำยังไงครับ

- เนื่องจาก field ใน table TB_Plant รวมกันได้ ก็ควรรวม ไม่มีเหตุผลให้แยก (จากชื่อ field ในแบบที่ 2)

- การวาง AgricultureTypeCode ใน TB_Agriculture ถือเป็น duplicate ข้อมูลซ้ำโดยไม่จำเป็น (ยกเว้นจำเป็นจริงๆ เช่นข้อมูลที่เยอะมาก และ ใช้บ่อย) โดยสามารถใล่ดูได้จาก TB_Plant

- ไม่เข้าใจคำถาม "หากผมต้องการจะลบรายชื่อพืชออก หรือว่า เพิ่มชื่อพืช ผมต้องทำยังไงครับ"
... คือจะเพิ่ม/ลบที่ไหน เปิด table แล้วใส่ข้อมูลไม่ได้ หรือ สร้าง form อย่างไร???

- รหัสพืช ถ้าไม่จำเป็นก็ไม่ต้องมีตัวอักษรนำ/แบ่งประเภท เพราะมี AgricultureTypeCode อยู่แล้ว มิฉะนั้นจะยากในการเขียน Form บันทึก

ขอโทษครับ ผมก็ถามแบบงงๆ เหมือนกัน ..ใช่ครับตามที่คุณ PichaiTC บอกครับ คือว่าจะสร้าง Form เพิ่มลบ ข้อมูลพืช (แต่คงไม่ได้เพิ่มลบบ่อยครับ) เผื่อมีการเปลี่ยนแปลงหน่ะครับ จุดประัสงค์คืือ ใน Form ที่กรอกข้อมูลการทำเกษตรกรรม

สมมุติ ให้ Combo1 เลือก ประเภทเกษตรกรรรม ปลูกข้าว
      Combo 2 มีให้เลือกเฉพาะข้อมูลของ ข้าว ครับ ผมอธิบายไม่ค่อยเก่งครับ
ช่วยผมหน่อยนะครับ

ตอนนี้ผมทำตามที่คุณ PichaiTC แนะนำแล้วนะครับตาม R13097 รบกวนเรื่อง Combobox ตามที่ผมรบกวนถามไปที่ R13103 ครับ ช่วยข้าน้อยด้วยครับ ขอบคุณล่วงหน้าครับ

ในการเพิ่มข้อมูลลง TB_Agriculture ผ่าน form
สามารถสร้าง combo AgricultureTypeCode โดยไม่ต้องเชื่อม(bound) ข้อมูล (เพราะไม่มี field ให้เชื่อม) แต่วางไว้เป็นตัว filter ให้ combo PlantID โดยกำหนด row source ให้เป็น Select PlantID, PlantName From TB_Plant Where AgricultureCode = Forms![ชื่อ form]![ชื่อ combo AgrilcultureTypeCode]

พอดีมีปัญหาเกิดขึ้นครับ คุณ PichaiTC ผมกดปุ่มบันทึกที่ฟอร์มกรอกข้อมูล แล้วขึ้น Error ดังภาพครับ



Rowsource ของ combo AgricultureTypeCode (AG)

SELECT [TB_AgriculturType].[AgriculturTypeCode], [TB_AgriculturType].[AgriculturType] FROM TB_AgriculturType ORDER BY [AgriculturType];

Rowsource ของ combo PlantId (PN)

SELECT PlantID, PlantName FROM TB_Plant WHERE AgriculturType=Forms!FormRecordDataAgricultur!AG;

ผมทำตามที่คุณ PichaiTC ได้แนะนำมาแล้วครับแต่ยัง error ตอนกดปุ่มบันทึกครับ

ปล.ไม่่ว่าเกี่ยวกันรึปล่าวครับ คือว่าผมได้เขียน Code ไม่ให้บันทึกอัตโนมัติครับ ต้องกดปุ่ม บันทึก เท่านั้น

Private Sub AddRecord_Click()
IsSaveClicked = True
Me.Dirty = False
End Sub

มัน Error ที่บรรทัด สีแดง ครับ ช่วยหน่อยนะครับ

คาดว่าไม่เกี่ยวกับ Combo ทั้ง2 ครับ
อาจจะเป็นเพราะ record source ของ form

ขอบคุณสำหรับคำแนะนำครับ ตอนนี้ผมยังแก้ไม่ได้เลยครับ อาจารย์ผู้รู้ท่านไหนพอจะชี้ทางสว่างให้ผมได้มั้ยครับ ช่วยหน่อยนะครับ

ไม่ได้อ่านข้อความทั้งหมดนะครับ แต่ดูจาก error ในรูปล่าสุด
สันนิษฐานว่า ลำดับการทำงานผิดครับ

คุณได้กระทำการบันทึกข้อมูล โดยผิดลำดับของความสัมพันธ์
ถ้าข้อมูลของคุณมีการสร้างความสัมพันธ์แบบ one to many คุณต้องกระทำด้วยวิธีการใดก็ตาม ให้ข้อมูลเข้าในตารางฝั่ง one ก่อนเสมอ
ห้ามให้ข้อมูลไหลโดยไม่มีการควบคุณ ถ้าบังคับให้มันเข้าตารางฝั่ง many ก่อน มันก็จะ error ดังกล่าวครับ

สมมติว่า คุณมีตารางหลัก (ฝั่ง one) ชื่อ tableHead เก็บเลขที่ใบเสนอราคา
แล้วคุณมี tableDetail เก็บรายการสินค้าของใบเสนอราคานั้นๆ
เวลาเพิ่มข้อมูล คุณต้องเพิ่มเลขที่ เข้าไปในตาราง tableHead ก่อนเสมอ ในทุกๆ กรณี

ถ้าคุณฝืนให้มันเพิ่มรายการสินค้าก่อน ถ้ามันพูดได้มันก็คงถามว่า "จะเอารายการสินค้านี้ ไปผูกกับเลขที่ใบเสนอราคาที่เท่าไรล่ะ ก็เพราะในตารางหลัก มันยังไม่มีเลขที่เลย"

จากโค้ดที่ดูตามที่โพสต์ (ดุแบบคร่าวๆ) ยังไม่สามารถบอกได้ว่าลำดับงานที่ผิดนั้น เริ่มจากตรงไหนถึงตรงไหน ดังนั้น ให้คุณกลับไปสำรวจเองดีกว่าครับ เอาเป็นว่า โดยรวมๆ ก็คือ คุณสั่งให้ข้อมูลเข้าเก็บใน 'ตารางที่มีการเชื่อมความสัมพันธ์' ผิดลำดับของความสัมพันธ์นั้นๆ

พึ่งทำได้เมื่อกี้ครับ

ความเดิม...

Rowsource ของ combo AgricultureTypeCode (AG)

SELECT [TB_AgriculturType].[AgriculturTypeCode], [TB_AgriculturType].[AgriculturType] FROM TB_AgriculturType ORDER BY [AgriculturType];----ไม่เปลี่ยน

Rowsource ของ combo PlantId (PN) --- ของเดิม

SELECT PlantID, PlantName FROM TB_Plant WHERE AgriculturType=Forms!FormRecordDataAgricultur!AG;

SELECT [TB_Plant].[PlantId], [TB_Plant].[PlantName] FROM TB_Plant ORDER BY [PlantName];

อันนี้แก้ใหม่ครับ

แก้แล้วลอง กด บันทึก ดูอีกที ปรากฏว่าได้ครับไม่ Error แต่ไม่รู้ว่ามาถูกทางรึปล่าว แก้ได้ (แบบงงๆ)แต่อธิบายไม่ได้ครับ ความหมายของมันคืออะไรครับ คือว่าหลักการทำงานของ Code ใหม่นะครับ ช่วยบอกผมทีครับว่ามันทำงานยังไงครับ ขอบคุณจริงๆครับที่ให้ความรู้+แนวคิด

ช่วยดูตารางความสัมพันธ์ของผมหน่อยครับว่าควรปรับแก้ตรงไหนรึปล่าวครับ
ตาราง TB_Agricultur กับ TB_Farmer (ซึ่งผมได้สร้างฟอร์มไว้ทั้ง 2 ฟอร์ม)

เป็นตารางที่จะต้องเพิ่มข้อมูล อยู่ตลอดครับ แต่..
TB_Plant กับ TB_AgriculturType มีข้อมูลอยู่แล้วครับไม่ต้องปรับเปลี่ยน

ให้คำชี้แนะด้วยครับ ...หากข้อมูลที่ให้ไม่เพียงพอหรือ กำกวม ฯลฯ ต้องขออภัยด้วยนะครับ พึ่งหัดเขียน Access ได้ไม่กี่วันเองครับ ขอบคุณสำหรับคำแนะนำอีกครั้งครับคุณ yeadram และ สำหรับทุกๆท่านที่ให้ความอนุเคราะห์...ขอบคุณจริงๆครับ ขอให้มีสุข พลานามัย แข็งแรง

เออ อีกอย่างครับ
คำถาม
1. ตาราง TB_Agricultur ไม่มี PK จะมีปัญหาอะไรรึปล่าวครับ (ไม่รู้จริงๆอ่าครับ)
2.แล้วควรจะมี รึปล่าวครับ
3.ในการสร้างความสัมพันธ์ จำเป็นจะต้องใช้คีย์หลัก เชื่อมไปยังตารางอื่น เสมอ รึปล่าวครับ

เอาล่ะผมย้อนกลับไปอ่านมาทุกความเห็นแล้ว

-สรุปให้ดังนี้ ความสัมพันธ์และโครงสร้าง แบบสุดท้ายนี้ (R13154) สมบูรณ์ที่สุด
-ส่วนการสร้างฟอร์มบันทึกข้อมูล ทั้ง 4 ตารางที่มี เวลาสร้างฟอร์ม ให้สร้างเป็นฟอร์มเดี่ยวทั้งหมด ไม่มีการลิงค์ฟอร์มลูก เพราะไม่มีความจำเป็นใดๆ

ต่อไปตอบคำถามครับ เรียงลำดับย้อนนะครับ
- ในการสร้างความสัมพันธ์ ไม่จำเป็นต้องใช้คีย์หลักเสมอครับ ขึ้นอยู่กับการเลือกใช้ชนิดความสัมพันธ์ รูปแบบความสัมพันธ์ด้วย
- ตาราง TB_Agricultur ควรมี PK หรือเปล่า ถ้าไม่มีก็ไม่เป็นไรครับ อย่างที่บอกเวลานำไปสร้างฟอร์มสร้างรายงาน ต้องใช้ข้อมูลแบบตารางเดียวครับ ไม่ได้มีการลิงค์ฟอร์มลูก หรือรายงานย่อยแต่อย่างใด เพราะฉะนั้นมันไม่สร้างปัญหาใดๆ ให้ครับ แต่ควรจะเป็นอย่างน้อยเป็น Autonumber ก็ยังดี เพื่อให้มีการประมวลผล เวลาทำคิวรี่ จะเร็วขึ้นครับ (จะเห็นผลในกรณีข้อมูลมีหลายเรคคอร์ด ระดับหมื่นเรคคอร์ดเป็นต้นไป หรือมากกว่านี้น้อยกว่านี้จะมีเห็นผลกระทบหรือไม่ขึ้นอยู่กับความเร็วซีพียูและความจุของแรม)
- การเพิ่มลบข้อมูลของตารางใดๆ
- ตารางเกษตรกร สามารถเพิ่มได้ทันที จากฟอร์มของมันเอง
แต่การลบ ต้องดูว่าในตาราง TB_Agricultur มีการใช้งานเกษตรกรรายนี้บันทึกข้อมูลไปบ้างแล้วหรือไม่ ถ้ามีการนำไปใช้แล้ว จะต้องลบทุกๆ เรคคอร์ดที่เกี่ยวข้องกับเกษตรกรรายนี้ ออกจากตาราง TB_Agricultur ให้หมดเสียก่อน คุณถึงจะมีสิทธิ์ลบ เกษรกรรายนี้ ออกจากตารางเกษตรกรได้ (*ต้องลบฝั่ง many ก่อนถึงจะ ลบฝั่ง one ได้) ( **คุณสามารถใช้คำสั่งลบจากฟอร์มของมันเอง ด้วยคลิ๊กเดียวแล้วให้ทุกรายการในตาราง TB_Agricultur หายไปอัตโนมัติก็ได้ โดยการกำหนดลักษณะความสัมพันธ์ในเส้นความสัมพันธ์)
- ตารางประเภทการเกษตรกรรรม เพิ่ม/แก้ไข ได้จากฟอร์มของมันเอง
เวลาลบก็เช่นกัน เพราะมันอยู่ฝั่ง one ตัวบนสุด แต่ต้องระวัง เมื่อลบมัน อาจจะทำให้พืชทุกชนิดที่เกี่ยวข้องกับมัน ในตารางพืช จะหายไปด้วย และมีผลต่อเนื่องถึงตาราง TB_Agricultur ซึ่งทุกๆ เรคคอร์ดที่เกี่ยวข้องกับ พืชที่หายไป ก็จะพลอยหายไปด้วย (มันคือการลบจากหัวแถวสุด ข้อมูลย่อยๆ จะพลอยหายตามกันไปหมด ซึ่งสามารถป้องกันความผิดพลาดได้ ด้วยการกำหนดลักษณะความสัมพันธ์ ที่เส้นความสัมพันธ์ ว่าจะให้ลบตามกันทั้งหมดหรือไม่)

- ตารางพืช เวลาจะเพิ่ม เพิ่มได้จากฟอร์มของมันเอง แต่เวลาจะลบ จะเหมือนกับตารางเกษตรกร กล่าวคือ ต้องลบข้อมูลทุกๆ เรคคอร์ดจากตาราง TB_Agricultur ที่พืชตัวนี้อยู่ในรายการก่อน ถึงจะลบพืชตัวนี้ออกจากระบบได้
สามารถสั่งลบได้จากบนฟอร์มของมันเอง ถ้ามีการกำหนดลักษณะความสัมพันธ์ให้ลบรายการในข้อมูลย่อยอัตโนมัติ ก็ใช้คำสั่งแค่คำสั่งเดียว Delete ก็ไปทั้งยวง หมายถึงทั้งรายการในตาราง TB_Agricultur ที่เกี่ยวกับพืชตัวนี้ ก็จะหายไปด้วย แต่ถ้าไม่ได้กำหนดลักษณะเป็นแบบดังกล่าว จะต้องมีการสั่งคำสั่งสองครั้ง
คือ 1 สั่งให้ลบทุกเรคคอร์ดจาก TB_Agricultur ที่มีข้อมูลเกียวข้องกับพืชตัวนี้
และ 2 ค่อยสั่งให้ลบพืชตัวนี้ออกจากตารางของมันเอง

- ตาราง TB_Agricultur จะเพิ่มจะลบ (ทั้งรายการ) ทำได้ในฟอร์มของมันเอง มันเป็นตารางระดับล่างสุดในระบบความสัมพันธ์อยู่แล้ว
แต่หากจะเพิ่มรายการพืชตัวใหม่ หรือเกษตรรายใหม่ จะต้องสั่งการให้เพิ่มในตารางของมันเองเสียก่อน ถึงจะเพิ่มเข้าในตารางนี้ได้

ขอบคุณมากครับสำหรับคำอธิบาย เข้าใจอะไรได้มากเลยครับ จากความเดิม....- ตาราง TB_Agricultur ควรมี PK หรือเปล่า ถ้าไม่มีก็ไม่เป็นไรครับ อย่างที่บอกเวลานำไปสร้างฟอร์มสร้างรายงาน ต้องใช้ข้อมูลแบบตารางเดียวครับ ไม่ได้มีการลิงค์ฟอร์มลูก หรือรายงานย่อยแต่อย่างใด เพราะฉะนั้นมันไม่สร้างปัญหาใดๆ ให้ครับ แต่ควรจะเป็นอย่างน้อยเป็น Autonumber ก็ยังดี เพื่อให้มีการประมวลผล เวลาทำคิวรี่ จะเร็วขึ้น

ก่อนหน้านี้ผมได้ใช้ Autonumber (ก่อนที่จะลบออกเพราะคิดว่าไม่น่าจะมีความจำเป็น) ซึ่งผมไม่รู้เลยว่ามันจะมีประโยชน์กับการทำคิวรี่ครับ
Q - ถ้าผมจะใช้ตาราง TB_Agricultur ทำ Query ขึ้นมาเพื่อใช้ในการทำฟอร์มค้นหาข้อมูลครับ ก็ควรที่เพิ่ม Autonumber ใช่มั้ยครับ?
Q - ผมได้ค้นหาเรื่องการทำฟอร์มจากบอร์ด มาหลายวันครับ จับต้นชนปลายไม่ถูก ช่วยแนะนำการทำฟอร์มค้นหาข้อมูลให้ผมอีกสักทีได้มั้ยครับ ได้โปรดดด?

การลบ ต้องดูว่าในตาราง TB_Agricultur มีการใช้งานเกษตรกรรายนี้บันทึกข้อมูลไปบ้างแล้วหรือไม่ ถ้ามีการนำไปใช้แล้ว จะต้องลบทุกๆ เรคคอร์ดที่เกี่ยวข้องกับเกษตรกรรายนี้ ออกจากตาราง TB_Agricultur ให้หมดเสียก่อน คุณถึงจะมีสิทธิ์ลบ เกษรกรรายนี้ ออกจากตารางเกษตรกรได้ (*ต้องลบฝั่ง many ก่อนถึงจะ ลบฝั่ง one ได้) ( **คุณสามารถใช้คำสั่งลบจากฟอร์มของมันเอง( **คุณสามารถใช้คำสั่งลบจากฟอร์มของมันเอง ด้วยคลิ๊กเดียวแล้วให้ทุกรายการในตาราง TB_Agricultur หายไปอัตโนมัติก็ได้ โดยการกำหนดลักษณะความสัมพันธ์ในเส้นความสัมพันธ์)

ในทุกๆความสัมพันธ์ของตารางนี้ผมได้กำหนดให้เป็น
- ปรับปรุงเขตข้อมูลที่เกี่ยวข้องทั้งหมด
- ลบระเบียนที่เกี่ยวข้องทั้งหมด
Q - สิ่งที่ผมทำ ควรทำหรือไม่ครับ หรือว่าควรทำอย่างไรดีครับ?

- เพิ่ม PK ให้ตารางมีแต่ผลดี ไม่มีผลเสียอะไรครับ
- ฟอร์มค้นหาข้อมูล ค้นดูตัวอย่างของคนอื่นครับ โหลดมาดูเยอะๆ ครับ ในเมล์น่าจะพอมี มันมีหลายวิธี บ้างก็ใช้แบบสร้างคิวรี่ด้วยพารามิเตอร์ (ผมไม่แนะนำนะวิธีนี้ สร้างง่ายแต่ไม่ยืดหยุ่นในการจะดัดแปลงเพิ่มเติม) บางก็ใช้การเปลี่ยน source ของฟอร์ม บางก็ใช้ filter ของฟอร์ม บางก็ใช้ Bookmark ของ dao recordset และตอนนี้ ผมกำลังเขียนโปรแกรมขายให้กับ อบต. ผมว่าจะลองใช้ .find ของ ADODB recordset ไม่รู้จะเวิร์คมั้ย กำลังลองทำอยู่ครับ แต่ละวิธีอธิบายยากครับ มีหลายขั้นหลายส่วน โหลดตัวอย่างของหลายๆ คน มาดูหลายๆ วิธี แล้วประยุกต์เอาครับ
- การระบุลักษณะความสัมพันธ์ ผมหลีกเลี่ยง หัวข้อสุดท้ายที่สุด "ลบระเบียนที่เกี่ยวข้อง" ถ้าพลาดมากู้กลับลำบาก
สมมติว่า พลาด ลบพืช ออกจากตารางพืช มันยังฟ้องเตือนเราบ้าง เพราะมันจะลบไม่ได้ ถ้าไม่ลบพืชนั้นออกจากตารางกิจกรรมก่อน มันช่วยได้ดีนะผมว่า แต่ถ้าเกิดตั้งให้ลบทุกระเบียนที่เกี่ยวข้อง มันไม่เตือนเลย มันไปวูบเดียวหายหมด กะอีแค่รายการพืชในตารางพืช เราพอจำมันได้ครับ เพราะมันแค่เรคคอร์ดเดียว สามารถคีย์เข้าใหม่ก็ได้ แต่ว่ารายการอื่นๆ ที่อยู่ในตาราง TB_Agricultur ที่ถูกลบไปน่ะซิ เราไม่รู้ว่ามันไปกี่เรคคอร์ด แต่ละเรคคอร์ดผูกโยงกับตารางอื่นๆ อีกหรือเปล่า บังเอิญ(มักจะไม่ใช่) ว่า ก่อนจะสั่งลบพืช ไม่ได้แวะเข้ามาดู เข้ามาจดจำ พวกมันไว้ก่อนนี่ซิ ผมว่ามันอันตราย

ขอรบกวนอีกสักเรื่องนะครับ เรื่อง แยกข้อมูล Front-End กับ Back End นี่มันหมายความว่าอย่างไรครับ พอดีไปอ่านใน microsoft ไม่ค่อยไม่เข้าใจ มันมีประโยชน์อย่างไรครับ

คือสมมุติว่าโปรแกรม Access ที่เรานำไปให้ User ใช้ (แปลงเป็น .accde หรือว่ามีวิธีที่ดีกว่านี้มั้ยครับ) มีเหตุให้ต้องปรับปรุงตัวโปรแกรม ซึ่งต้นฉบับที่อยู่ที่เรามันไม่มีข้อมูลใดๆ ที่ user บันทึกไว้ตอนใช้งาน มันขั้นตอน/วิธีการอย่างไร ในการนำเข้าข้อมูลเก่าที่ user บันทึกไว้ (.accde) มาเข้ากับฐานข้อมูลใหม่ที่เราปรับปรุงใหม่ครับ

เรื่อง Front-End, Back-End นะครับ

http://office.microsoft.com/th-th/access-help/HA010240096.aspx

จาก link ของ microsoft นะครับ ลองอ่านดูอีกที
ถ้าไม่เข้าใจตรงไหนถามมาเป็นจุด ดีกว่าครับ

เรื่อง Primary Key (PK) ครับ

การสร้าง PK คือการสร้าง Index แบบข้อมูลห้ามซ้ำ(Unique)ครับ
ข้อดีคือ ป้องกันการบันทึกข้อมูลผิดพลาด และ ค้นหาได้เร็ว

เช่น หากเราต้องการระบุตัวบุคคล คนใดคนหนึ่งในประเทศไทย เราจะทำอย่างไร ในเมื่อมีคนที่ ชื่อซ้ำกัน และ นามสกุลซ้ำกัน บางทีอยู่ในบ้านเดียวกันอีก
- ไม่ต้องงงครับ มีเรื่องจริงแบบนี้ครับ นายสมชาย สกุลดี มีน้องสาวชื่อ นส.สมหญิง สกุลดี ต่อมานายสมชาย ได้แต่งงานกับ นส. สมหญิง ใจกล้า เมื่อแต่งงานกันจึงจดทะเบียนสมรสและเปลี่ยนนามสกุลเป็น นางสมหญิง สกุลดี และย้ายทะเบียนบ้านมาอยู่ร่วมกับสามี สรุปในทะเบียนบ้านมี นาง และ นส. สมหญิง สกุลดี อยู่ด้วยกัน -- ถ้าเกิดทั้งสอง สมหญิง รับราชการ ยศเดียวกัน คำนำหน้าชื่อก็คงจะเหมือนกันไปด้วย ...
ฉะนั้นระบบ เลขประจำตัวประชนจึงเกิดขึ้น

เช่นกันกับ ข้อมูลของเรา หากระบบใหญ่มาก จนอาจมีข้อมูลสำคัญ(เช่นชื่อ) ซ้ำกันได้ ก็ควรจะมี รหัส หรือ เลขประจำตัว มาใช้อ้างอิง
ดังนั้นการใช้ AutoNumber ก็เป็นการสร้าง รหัส แบบง่ายๆ(และใช้ได้ดี) ในการจำแนกความต่างของข้อมูล

- แต่การมี AutoNumber เป็น PK จะทำให้การ query ดีจริงหรือ ?
-- ไม่จริงเสมอไปครับ การมี PK จะสร้างเป็น index เหมือนกับตารางสารบัญ หรือ ดัชนีท้ายเล่มหนังสือ ซึ่งช่วยให้ค้นหาข้อมูลได้เร็วขึ้น แต่หากในความเป็นจริง ผู้ใช้งานไม่เคยใช้ index นั้นในการค้นหาเลย แน่นอนว่าไม่เกิดประโยชน์ เช่น ข้อมูลของคุณจะค้นหาข้อมูลว่า ใครปลูกพืชอะไร ไม่เคยออกบัตรที่มีหมายเลข, บาร์โค้ด หรืออะไรที่จะทำให้รู้ว่า AutoNumber ที่มีนั้นเป็นเลขอะไร แปลว่าคุณจะไม่เคยใช้ เลขนั้นเลย

สรุปกรณีนี้ PK ของ TB_Agricultur ควรจะเป็น FarmerID และ PlanID พร้อมกัน กรณีนี้เลขว่า คีย์ร่วม (Concatenate Key)