ใครก็ได้ช่วยแนะนำ Ebook สอนการออกแบบฐานข้อมูลแบบ text book หน่อยครับ พอดี...
ลองคิดแบบกลับขั้วกลับหัวก้อได้ค่ะ โดยคิดว่าต้องใช้ object อะไร เกาะเกี่ยวกันเป็น application ที่ต้องการ
ซึ่งถ้าเป็น ORM แบบ commerce มักจะสนับสนุนวิธีคิดแบบนี้อย่าง Telerik ORM ไม่แน่ใจว่า Hibernate จะมีป่าวนะคะ
จากนั้นก้อเขียน class ของ object แล้ว reverse mapping จากนั้น ORM จะ generate database - table - field - relation ให้
เพียงแต่ index บางตัวต้องมาใส่เองทีหลังค่ะ หนังสือที่ออกแบบ database ส่วนใหญ่จะเป็น RDM (Relation Database Management) ค่ะ
ไม่ค่อยจะเห็น ที่เป็น OODM (Object Oriented Database Management) สักเท่าไหร่
ทั้งนี้หากเข้าใจหรือใช้ Relation database ได้พอสมควรก้อจะมอง OODM ได้ค่อนข้างง่ายทั้งนี้เพราะ table หรือ entity ก้อคือ object
ของ OOD นั่นเองค่ะ แต่แปลกหนังสือส่วนมากที่พอจะเกี่ยวกับ OODM มักจะรวมอยู่ในพวก Design pattern ทั้งนี้
เพราะเมื่อทุกอย่างเป็น Object เราก้อมักจะดำเนินการ และจัดการกับมันตามแบบของ object แหละค่ะ
Date :
2010-09-27 19:33:09
By :
blurEyes
อีกอย่างครับ ORM นั้นมันมี convension อยู่ซึ่งผมเองไม่แม่นดาต้าเบส รีเลชั่นอยู่แล้ว บางทีมันบอกให้ต้องมี pk แต่ผมเองก็ไ่ม่รู้ว่าต้องเพิ่มฟีล หรือเอาฟีลที่เป็นคีย์ของอีกสองตารางมาทำ กันแน่ (และเหตุผลที่ทำไมต้องมี)
ผมไม่อยากดำน้ำคืออยากรู้ทฤษฎีของดาต้าเบสให้ดีก่อน แล้วค่อยมองเห็นข้อจำกัดในการทำ ORM แล้วหาวิธีลดข้อจำกัดนั้น
Date :
2010-09-27 20:18:57
By :
pjgunner.com
อ๋อค่ะ เอาเป็นว่า ทุก table ควรจะมี pk ของตัวเองจะเหมาะกับ ORM
ส่วนในกรณีที่ table นั้นแต่เดิมใช้ key หลาย key ประกอบกันเป็น fk ก้อให้สร้างของ table อีก field ต่างหากแทน
ส่วนข้อแนะนำอื่นเห็นจะเป็นว่า datatype ที่ใช้ควรจะเป็น datatype แบบมาตรฐานตามแบบ SQL ค่ะ
Date :
2010-09-27 20:32:17
By :
blurEyes
ขอโทษนะครับ ผมก็มั่วๆนะ ส่วนเรื่อง pk หรือไม่ pk ยังไง ผมก็ยังจะต้องลองอยู่ เห็นคุณพราวถนัดเรื่องดาต้าเบสรีเลชั่นชิพ
อยากช่วยอธิบายและ แสดงตัวอย่างการ ออกแบบตารางและแสดงความสัมพันธ์ให้ดูหน่อยครับ ถ้ามีเวลา
1. one to one
2. one to many
3. many to many
4. many to many (through)
และอยากถามว่า 1 ตารางสามารถใช้ รีเลชั่นหลายๆ แบบเลยได้มั้ยครับ
Date :
2010-09-27 20:37:42
By :
pjgunner.com
ป่าวถนัดค่ะ จริงๆถนัดวาดการ์ตูนมากกว่า
ถ้าจะออกแบบตามทฤษฎีเป๊ะๆ มันก้อได้ database ที่มี table เยอะโดยธรรมชาติ (เพราะโดน normalized เข้าไปหลายครั้ง)
แต่ในบางโครงงานถ้าเราไม่ยึดกับกฏมากนัก ผลลัพธ์ที่ได้จะเร็วกว่าเป็นธรรมชาติมากกว่า
ทั้งนี้เพราะงาน it มักจะเป็นศิลป์(Art)ครึ่งนึงและศาสตร์(Science)สะอีกครึ่ง
ถ้าเราใช้ศาสตร์มากระบบจะแน่นทำงานเป๊ะๆๆ แต่ขาดความยืดหยุ่นตอบสนองกับอารมณ์และความต้องการที่หลากหลายของ user ไม่ได้
แต่ถ้าใช้ ART มากไป ระบบจะไม่ค่อยสเถียร การซ่อมบำรุงทำได้ยาก อันนี้จากที่ฟัง อจ. เล่ามาและเจอกับตัวเองมั่งแล้วอะนะคะ
เส่วนเรื่องที่ถามนี่เรียนผ่านมาปีนึงละ ไม่ค่อยชัวร์กับคำตอบเท่าไหร่
แบบว่าความรู้ที่เรียนพอผ่านมา ก้อคืนให้ท่านอาจารย์เอาไปสอนรุ่นน้องสะเยอะแล้ว
ขอตอบตามที่ติดอยู่ในสมองละกันเพราะตอนนี้ก้อยัดความรู้ใหม่ๆมาเพื่อสอบอยู่ค่ะ
ตารางหนึ่งตารางมีความสัมพันธ์ได้มากกว่าหนึ่งแบบ เพราะโดยระบบอาจมีความต้องการแบบนี้
แต่พยายามหลีกเลี่ยงได้จะดีกว่าค่ะ จะด้วยการ normalized หรือตัดตารางออกเป็นส่วนๆก่อนจะจัดการระบบโดยรวมได้สะดวกค่ะ
ส่วน one-one ,one-many ก้อตามปกติค่ะ แต่ many-many ต้อง normalized ออกเป็น many-one ,one-many ค่ะ
Date :
2010-09-27 22:03:27
By :
blurEyes
ขอบคุณคุณพราว บิวตี้มากครับ
อืมถามอีกนิด คือที่ผ่านมากก็สักแต่ออกแบบอ่ะครับ ไม่รู้อันไหนชื่ออะไร ตอนนี้ มิกซืแอนแมตช์ มั่วๆ ซะเยอะ ลืมไปเลย
one-one นี่จำไม่ได้แฮะว่าเคยใช้ หรือลืมว่ามันเป็นยังไงใช้ ตอนไหน
one-many นี่รู้สึกว่าจะเขาใจ ^^ ใช้บ่อย
many-many นี่รู้สึกว่าจะเคยใช้แค่ 2-3 ครั้ง ไม่รู้ ว่ามันใช่ตัวนี้ป่าว
เดานะไม่รู้ถูกป่าว ชี้แนะด้วยครับ อันนี้ 1:1 ว่าผมเข้าใจถูกไหม หรือมั่วเอา
table users
id
uname
upass
table profile (ไม่แน่ใจว่าควรมี s ด้วยหรือป่าว)
user_id
name
surname
etc..
อันนี้ 1:many ผู้ใช้มีหลายโพส, บอร์ดมีหลายโพส
table users
id
uname
upass
table forums
id
name
table posts
user_id
forum_id
data
อันนี้ many to many
table users
id
name
table product_user (pivot) ไม่รู้ว่าควรมีฟีล id ที่เป็น primary key ด้วยหรือป่าว ชี้แนะด้วย
user_id
product_id
table products
id
name
etc..
ปล. มั่วเอานะครับ ใครมีความรู้ประสบการ์ณ ช่วยแนะนำด้วยครับ
ประวัติการแก้ไข 2010-09-28 00:03:48
Date :
2010-09-27 23:49:07
By :
pjgunner.com
ตัวอย่าง many-many
sys_user
===============
id
role_id
name
......
sys_role
===============
id
user_id
name
......
normalized
sys_user
===============
id
name
......
sys_role
===============
id
name
......
sys_user_in_role
===============
id
user_id
role_id
พอจะเข้าใจปะคะ ส่วนการย้าย key เปลี่ยน key ตามทฤษฎีเป๊ะ ต้องหาเอกสารอ้างอิงเอาค่ะ
ที่ต้อง strict เพราะจะมีการทำเอกสารแล้วแจกจ่ายให้ทีมพัฒนาทำต่อ และไม่ควรมาแก้ไขฐานข้อมูลอีก
ถ้ายังเขียนไปแก้ไป ก้อแสดงว่าเริ่มๆจะใช้ art มากกว่า science แล้วค่ะโอกาสจะปลายบานมีสุง
Date :
2010-09-28 00:24:15
By :
blurEyes
เข้าใจจ๊ะ เข้าใจขึ้นมากเลย
ผมเปลี่ยนใจไม่ใช้ ORM แล้ว เพราะผมเข้าใจมันมากขึ้น คิดว่ามันก็ไม่ได้มีอะไรดีเท่าไหร่ หันไปใช้ query builder แทน
ประวัติการแก้ไข 2010-09-28 01:41:07
Date :
2010-09-28 01:30:41
By :
pjgunner.com
Load balance : Server 05