ต่อไป »

[kanin03]

คือว่าผมกำลัง งง กับการออกแบบฐานข้อมูล mysql โดยมีข้อมูลที่ต้องเก็บในลักษณะนี้ครับ

สมมุติว่า เราต้องการเก็บข้อมูล รถคันนึง โดยที่รถคันนั้นมี ประกันภัยมาเกี่ยวข้องด้วย ซึ่งประกันภัยนั้นมีวันหมดอายุ เมื่อหมดอายุเราต้องเพิ่มประกันภัยของรถคันนั้นเข้าไปใหม่โดยสามารถทราบข้อมูลประกันภัยอันเก่าได้ด้วย (history)

เราควรจะออกแบบอย่างไรดีครับ

เท่าที่ผมคิดไว้ 2 แบบคือ

แบบแรก many-to-many

มีตารางของรถ ตารางของประกัน และตารางของประวัติประกัน

ตารางรถ มีคอลั่ม : ชื่อรถ, รายละเอียด
ตารางประกัน มีคอลั่ม : เวลาหมดประกันรถหาย (timestamp nullable), เวลาหมดประกันรถชน (timstamp nullable)
ตารางประวัติประกัน มีคอลั่ม : id_รถ, id_ประกัน

ซึ่งเวลาหาว่ารถคันนั้นมีประกันไหมหมดเมื่อไหร่ก็จะดูจากตารางประวัติประกัน อ้างอิงจาก id_รถ แล้วเลือกอันล่าสุด

หรือแบบที่ 2 one-to-many

ตารางรถ มีคอลั่ม : ชื่อรถ, รายละเอียด
ตารางประกัน มีคอลั่ม : id_รถ, เวลาหมดประกันรถหาย (timestamp nullable), เวลาหมดประกันรถชน (timstamp nullable)

ซึ่งเวลาหาว่ารถคันนั้นมีประกันไหมหมดเมื่อไหร่ก็จะดูจากตารางประกัน อ้างอิงจาก id_รถ แล้วเลือกอันล่าสุด

ผมกำลัง สับสนว่าทั้ง 2 แบบมันแตกต่างกันอย่างไรแล้วควรจะใช้แบบไหนดี

หรือท่านใดมีแบบอื่นแนะนำ รบกวนทีครับ

ขอบพระคุณมากๆครับ  

[imagineverend]

เป็นผมจะทำ 2 ตารางครับ ทำแค่นี้เราก็เล่นได้หมดครับ ว่าจะเอาอะไรมาแสดง
จะคลิกชื่อรถแล้วไปดูประวัติ(ประกัน)ของรถคันนั้น หรือ จะคลิกประกันแล้วดูว่าเป็นรถคันไหน

tbl_car
car_id
car_name
car_desc
..

tbl_insure
car_id
insure_id
insure_lost
insure_accident
insure_expire
...

[kanin03]

เป็นผมจะทำ 2 ตารางครับ ทำแค่นี้เราก็เล่นได้หมดครับ ว่าจะเอาอะไรมาแสดง
จะคลิกชื่อรถแล้วไปดูประวัติ(ประกัน)ของรถคันนั้น หรือ จะคลิกประกันแล้วดูว่าเป็นรถคันไหน

tbl_car
car_id
car_name
car_desc
..

tbl_insure
car_id
insure_id
insure_lost
insure_accident
insure_expire
...

ขอบคุณมากครับผม ผมก็คิดไว้แบบนี้แต่กลัวว่าจะคิดอะไรผิดไป  

ขอถามอีกนิดครับคือว่าถ้าหากเราจะใช้ แบบที่ 1 ที่มี 3 ตาราง ตารางประกันมันจะต้องมีคอลั่มใดคอลั่มหนึ่งที่เป็นแบบ unique หรือปล่าวครับเพราะมันจะเพิ่มซ้ำๆกันไม่ได้

อย่างเช่น หากผมเปลี่ยนจากรถ - ประกัน กลายเป็น รถ - เลขทะเบียน การออกแบบก็ควรจะเป็นแบบ 3 ตารางถูกไหมครับท่านเพราะเลขทะเบียนมันเพิ่มซ้ำๆกันไม่ได้

[imagineverend]

เป็นผมจะทำ 2 ตารางครับ ทำแค่นี้เราก็เล่นได้หมดครับ ว่าจะเอาอะไรมาแสดง
จะคลิกชื่อรถแล้วไปดูประวัติ(ประกัน)ของรถคันนั้น หรือ จะคลิกประกันแล้วดูว่าเป็นรถคันไหน

tbl_car
car_id
car_name
car_desc
..

tbl_insure
car_id
insure_id
insure_lost
insure_accident
insure_expire
...

ขอบคุณมากครับผม ผมก็คิดไว้แบบนี้แต่กลัวว่าจะคิดอะไรผิดไป  

ขอถามอีกนิดครับคือว่าถ้าหากเราจะใช้ แบบที่ 1 ที่มี 3 ตาราง ตารางประกันมันจะต้องมีคอลั่มใดคอลั่มหนึ่งที่เป็นแบบ unique หรือปล่าวครับเพราะมันจะเพิ่มซ้ำๆกันไม่ได้

อย่างเช่น หากผมเปลี่ยนจากรถ - ประกัน กลายเป็น รถ - เลขทะเบียน การออกแบบก็ควรจะเป็นแบบ 3 ตารางถูกไหมครับท่านเพราะเลขทะเบียนมันเพิ่มซ้ำๆกันไม่ได้

เลขทะเบียนรถ มันก็ควรจะอยู่ที่ตารางของรถ ไม่น่าจะต้องทำแยกนะครับ
tbl_car
car_id
car_name
car_desc
..
car_registration //ทะเบียนรถ

[kanin03]

เป็นผมจะทำ 2 ตารางครับ ทำแค่นี้เราก็เล่นได้หมดครับ ว่าจะเอาอะไรมาแสดง
จะคลิกชื่อรถแล้วไปดูประวัติ(ประกัน)ของรถคันนั้น หรือ จะคลิกประกันแล้วดูว่าเป็นรถคันไหน

tbl_car
car_id
car_name
car_desc
..

tbl_insure
car_id
insure_id
insure_lost
insure_accident
insure_expire
...

ขอบคุณมากครับผม ผมก็คิดไว้แบบนี้แต่กลัวว่าจะคิดอะไรผิดไป  

ขอถามอีกนิดครับคือว่าถ้าหากเราจะใช้ แบบที่ 1 ที่มี 3 ตาราง ตารางประกันมันจะต้องมีคอลั่มใดคอลั่มหนึ่งที่เป็นแบบ unique หรือปล่าวครับเพราะมันจะเพิ่มซ้ำๆกันไม่ได้

อย่างเช่น หากผมเปลี่ยนจากรถ - ประกัน กลายเป็น รถ - เลขทะเบียน การออกแบบก็ควรจะเป็นแบบ 3 ตารางถูกไหมครับท่านเพราะเลขทะเบียนมันเพิ่มซ้ำๆกันไม่ได้

เลขทะเบียนรถ มันก็ควรจะอยู่ที่ตารางของรถ ไม่น่าจะต้องทำแยกนะครับ
tbl_car
car_id
car_name
car_desc
..
car_registration //ทะเบียนรถ

คือว่าเลขทะเบียนก็มีโอกาสเปลี่ยนไปใช้เลขอื่นได้อ่าครับ แล้วก็ต้องมี ประวัติด้วยว่า รถคันนี้เคยมีเลขทะเบียนอะไรบ้าง  

[imagineverend]

คือว่าเลขทะเบียนก็มีโอกาสเปลี่ยนไปใช้เลขอื่นได้อ่าครับ แล้วก็ต้องมี ประวัติด้วยว่า รถคันนี้เคยมีเลขทะเบียนอะไรบ้าง  

งั้นก็เพิ่มตารางเข้าไป จัดการง่ายเลย

tbl_registration
car_id
reg_id
reg_name
reg_....

[kanin03]

ขอบคุณ ท่าน imagineverend มากครับ 

[MapTwoZa]

to จขกท ผมเสริมให้นิดนึง เดี๋ยวจะเข้าใจผิดไปยาว

ผมพูดถึง case ที่ท่านออกแบบ เป็น many to many นะครับ ผมมองว่ายังไงมันก็คือ one to many ไม่ใช่ many to many

1. การที่มันจะเป็น many to many นั้นมันต้องเป็น many to many โดยธรรมชาติจริงๆครับ ไม่เกี่ยวกับการ join table เลยครับ
2. การที่มันเป็น one to many มันก็ join table ได้นะครับ ไม่ผิดหลักการออกแบบเลยครับ (ซึ่งมันก็คือ อันที่ท่านมองมันเป็น many to many นั่นแหละ แค่ต้องสร้าง unique key ของ fk ของฝั่งที่เป็น many ครับ )

[kanin03]

to จขกท ผมเสริมให้นิดนึง เดี๋ยวจะเข้าใจผิดไปยาว

ผมพูดถึง case ที่ท่านออกแบบ เป็น many to many นะครับ ผมมองว่ายังไงมันก็คือ one to many ไม่ใช่ many to many

1. การที่มันจะเป็น many to many นั้นมันต้องเป็น many to many โดยธรรมชาติจริงๆครับ ไม่เกี่ยวกับการ join table เลยครับ
2. การที่มันเป็น one to many มันก็ join table ได้นะครับ ไม่ผิดหลักการออกแบบเลยครับ (ซึ่งมันก็คือ อันที่ท่านมองมันเป็น many to many นั่นแหละ แค่ต้องสร้าง unique key ของ fk ของฝั่งที่เป็น many ครับ )

ขอบคุณท่าน MapTwoZa มากครับผม  

ผมอ่านแล้วยังไม่ค่อยเข้าใจความหมายของข้อ 2 เท่าไหร่นะครับ คือท่านจะบอกว่า one to many สามารถออกแบบแบบ 3 ตารางได้ใช่หรอไม่ครับ

[MapTwoZa]

to จขกท ผมเสริมให้นิดนึง เดี๋ยวจะเข้าใจผิดไปยาว

ผมพูดถึง case ที่ท่านออกแบบ เป็น many to many นะครับ ผมมองว่ายังไงมันก็คือ one to many ไม่ใช่ many to many

1. การที่มันจะเป็น many to many นั้นมันต้องเป็น many to many โดยธรรมชาติจริงๆครับ ไม่เกี่ยวกับการ join table เลยครับ
2. การที่มันเป็น one to many มันก็ join table ได้นะครับ ไม่ผิดหลักการออกแบบเลยครับ (ซึ่งมันก็คือ อันที่ท่านมองมันเป็น many to many นั่นแหละ แค่ต้องสร้าง unique key ของ fk ของฝั่งที่เป็น many ครับ )

ขอบคุณท่าน MapTwoZa มากครับผม  

ผมอ่านแล้วยังไม่ค่อยเข้าใจความหมายของข้อ 2 เท่าไหร่นะครับ คือท่านจะบอกว่า one to many สามารถออกแบบแบบ 3 ตารางได้ใช่หรอไม่ครับ

ใช่แล้วครับ

[kanin03]

  ขอบคุณอีกครั้งครับ