ออกแบบฐานข้อมูลยังไงดีคะ ข้อมูลมันซ้ำซ้อนกัน ทั้งหมดมี 10 ฟิลด์มีฟิลด์ นึงเป็นรหัส คะ
ข้อมูลทุกฟิลด์เหมือนกัน ? แล้วใส่ลงฐานข้อมูลซ้ำๆกันทำไมอ่ะ ?
ผมว่าคุณอธิบายงานของคุณดีกว่าจะได้เข้าใจเหมือนกัน
Date :
2010-06-29 10:26:11
By :
oxygenyoyo
ป่าวๆ ข้อมูลทุก record ตั้งแต่ 1-10 เหมือนกันนะคะ ไม่ใช่ ทุกฟิลด์เหมือนกัน อิอิ
Date :
2010-06-29 10:29:33
By :
แพร
ทั้งหมดมี 10 ฟิลด์
มีฟิลด์ นึงเป็นรหัส คะ แล้ว รหัสตั้งแต่ 1-10 มีข้อมูลทุก record ตั้งแต่ 1-10 เหมือนกันเลย แล้วก็ต่อด้วย 11 12 ข้อมูลอาจจะไม่เหมือนกัน พอมา 13-15 ข้อมูลก็จะเหมือนกันอีก
เช่น
1 A A A A A A
2 A A A A A A
3 A A A A A A
4 A A A A A A
5 A A A A A A
6 A A A A A A
7 A A A A A A
8 A A A A A A
9 A A A A A A
10 A A A A A A
11 B B B B B B B
12 C C C C C C C
13 D D D D D D D
14 D D D D D D D
15 D D D D D D D
ควรสร้าง index ยังไงดีคะ เพื่อให้การค้นหา เร็วขึ้นแร้วก็ ไม่เปลืองเนื้อที่ โดยใช้เหตุด้วยอ่ะ
Date :
2010-06-29 10:30:37
By :
แพร
หรือ ต้องเพิ่มอีก 1 ฟิลดฺ ขึ้นมาเพื่อ group
1 A A A A A A 1
2 A A A A A A 1
3 A A A A A A 1
4 A A A A A A 1
5 A A A A A A 1
6 A A A A A A 1
7 A A A A A A 1
8 A A A A A A 1
9 A A A A A A 1
10 A A A A A A 1
11 B B B B B B B 2
12 C C C C C C C 3
13 D D D D D D D 4
14 D D D D D D D 4
15 D D D D D D D 4
Date :
2010-06-29 10:39:10
By :
แพร
แล้วในเมื่อมันเหมือนกันถ้าคุณจะหยิบแถวไหนออกมามันก็เหมือนกันคุณจะใส่ข้อมูลลงไปเพื่ออะไรอ่ะครับ ?
แล้วอีกอย่างคุณทำงานอะไรก็ไม่อธิบาย ผมจะมองเห็นภาพกว้างของงานคุณได้อย่างไรครับ
บางทีท่านอื่นฟังแล้่วเขาอาจจะแนะนำอย่างอื่น ที่ไม่ต้องมาใส่ข้อมูลซ้ำๆอย่างที่คุณทำก็ได้
ถามอีกว่าแล้วเวลาแถวที่ไม่เหมือนอ่ะ ข้อมูลก็ไม่เท่ากันหรือเปล่าครับ ?
หรือข้อมูลก็เท่ากัน หมายถึงว่าจำนวน column ที่จะเก็บเท่ากันหรือเปล่าอ่ะครับ
Date :
2010-06-29 11:09:43
By :
oxygenyoyo
ให้รายละเอียดน้อยมากการจะออกแบบฐานข้อมูลให้มีประสิทธิภาพ
อย่างน้อยต้องทราบคุณลักษณะ ธรรมชาติ เงื่อนไข หรือจุดประสงค์การนำไปใช้
คุณบอกมาว่า 10 field ก้อ อืม 10 field วิเคราะห์ใดๆให้ไม่ได้ค่ะ
ได้แต่มองตาปริบๆว่าจะทำยังไง
Date :
2010-06-29 11:10:40
By :
blurEyes
คือย่างนี้ค่ะ หมายเลข 1-10 นั้นจิงๆ คือหมายเลข 4790041057-71 ซึ่งก็คือเป็นหมายเลข invoice ที่ คีย์โดยเอาข้อมูลจาก เอกสารค่ะ ว่ารายละเอียด invoice หมายเลข 4790041057 ถึง 71 มีข้อมูลเดียวกันคะ เช่น ส่งของด้วยเรือลำเดียวกัน วันที่เดียวกัน รับของที่เดียวกัน อย่างนี้นะคะ
เลย ลองกำหนดเป็นเลขง่ายๆ 1-10 อย่างนี้นะคะ
Date :
2010-06-29 11:15:22
By :
แพร
อะนะคะ นั้น เด่วจะสมมติข้อมูลเกือบจริงให้นะคะ
ปรกติ เดิมเค้าจะใช้วิธีการกรอก 4790042057-71 อย่างนี้เลยคะ แต่ เวลาค้นหา เกิดเค้าค้นเป็น 47900042059 อย่างนี้อะคะ มันจะเจอข้อมูลหรอ
ก็เลย คิดว่าจะแตกข้อมูล มา นะคะ แต่มันจะเปลืองเนื้อที่มาก เพราะข้อมุลมันเหมือนกันนะคะ สำหรับ invoice ฉบับนี้
ไม่ทราบว่ามีวิธีอื่นที่ดีกว่านี้มั้ยคะ
Date :
2010-06-29 11:21:16
By :
แพร
เป็นแนวๆนี้นะคะ
Date :
2010-06-29 11:22:10
By :
แพร
ถ้าเป็นผมนะ ผมจะออกแบบให้ field invoice มี 2 field คือ invoice_start และ invoice_end แล้วบังคับให้กรอกทั้งสอง field และทั้งสอง field ให้กรอกเลข invoice แบบเต็มๆ ถ้ามี invoice เลขเดียวก็ให้กรอกเลขเดียวกันทั้ง 2 field
เวลา search ก็ where invoice_start <= field_search and invoice_end >= field_search
อันนี้ความคิดผมนะ
Date :
2010-06-29 12:48:00
By :
tinthai
คิดดีจังๆๆๆๆๆๆๆๆๆๆๆๆ คุณถิ่นไทย ยย ย ย ขอบคุณมากค๊าาาาาาาาา
มีแนวคิดอื่นอีกมั้ยค่ะะๆๆ
Date :
2010-06-29 12:53:34
By :
แพร
ยังมีอีกกรณีนึงอะคะ
4790042349-56,60-66
- - ยังมีกรณีอย่างนี้อีกอ่ะ ถ้าคิดทำแบบคุณ ถิ่นไทย ก็ต้องกรอกเป็น 2 record ใช่ป่าวคะ
ยังมีวิธีอื่นอีกมั้ยอ่าคะ
Date :
2010-06-29 13:07:40
By :
แพร
แล้วถ้าออกแบบ ฟิลด์เดียว
เก็บ
4790042349
..
4790042356
4790042360
...
4790042366
แต่มาทำการ ใช้การกรอง เลขที่กรอกหล่ะครับเช่น เจอ , หรือ - ให้ insert ไปตาม Logic ที่คิด
ส่วนการserch ก็ง่ายขึ้น เพราะหาได้ตรงๆเลย
Date :
2010-06-29 13:13:33
By :
50121680
หรือว่า ต้องแยก มาอีกตารางเพื่อเป็นข้อมูลในการแตก Invoice
ดีป่าวคะ
Date :
2010-06-29 13:25:04
By :
แพร
Date :
2010-06-29 13:29:23
By :
แพร
ข้อมูลข้างบน มันผิดอยู่คะ เอาเปน ภาพล่าสุดนะคะ
ถ้าออกแบบ ฐานแบบนี้โอเคไม๊ค่า
Date :
2010-06-29 13:30:02
By :
แพร
เห็นด้วยกับ คุณ Gusto ครับ
ใช้ algo ในการควบคุมงานดีกว่าครับ
Date :
2010-06-29 13:32:41
By :
ขนมหม้อแกง
อ๋อ คุนกำลังเอาแนวคิดเรื่องอำนวยควมสะดวกของ user ขณะกรอก
มารวมกับจะออกแบบฐานข้อมูลตามนั้น ฮื่อ
ก้อเข้าใจนะคะ แต่ออกจะผิดหลักการไปหน่อย
ปกติการเก็บข้อมูลต้องเก็บรายละเอียดปลีกย่อยให้ครบเท่าที่จำเป็น
เพราะเราจะมีกระบวนการอีกหลายขั้นตอนไม่ใช่เฉพาะมากรอกข้อมูลอย่างเดียว ค่ะ
เช่นนำไปทำรายงาน เดือนนี้ส่งของไปประทศนี้เท่าไหร่ เป็นต้น
ฉะนั้นฐานข้อมูลก้อควรจะเก็บข้อมูล 1 invoice ต่อหนึ่งรายการ( record )ไป
แต่หากคุณอยากให้การกรอกข้อมูลเป็นไปด้วยความสะดวกอันนี้น่าจะเป็นฝั่ง App Layer ส่วน
USER INTERFACE มั้งคะ โดยอาจจะออกแบบ form ให้สามารถกรอกข้อมุลซ้ำๆ
จาก invoice หมายเลข A1 ไปจนถึง หมายเลข An ได้ง่ายๆ มากกว่ามังคะ
ทีนี้จะ SEARCH จะ ANALYST หรือ จา PREDICT ไรก้อน่าจะทำได้ตามปกติค่ะ
ในเรื่อง FIELD TYPE ของหมายเลข INVOICE ก็แนะนำว่า
เป็น VARCHAR(100) ทำ INDEX แบบ UNIQUE ไปพร้อมกันค่ะ
ขอบคุณค่ะ
Date :
2010-06-29 13:37:08
By :
blurEyes
ถ้าตามที่คุณ Stupid gal บอก
ในฐานข้อมูล
invoice นึง ก็ต้องเก็บ ทุก field
คือต้องเรียงเป็น เลข invoice ให้ครบไปเลยหรอคะ แล้วมันจะไม่สิ้นเปลืองพื้นที่หรอคะ
Date :
2010-06-29 13:50:53
By :
แพร
ตามความถูกต้องต้องทำอย่างนั้นครับ
เรื่องสิ้นเปลืองไม่ต้องกลัวหรอกครับ
Date :
2010-06-29 14:00:43
By :
50121680
แต่ ลองถาม ข้อมูลดูแล้ว เค้า ไม่มีการ นำเลขใดๆ มาคำนวนเลยนะคะ แค่เปนการคีย์ข้อมูลเพื่อนำมาแสดง ผลสรุปเท่านั้น
Date :
2010-06-29 14:03:24
By :
แพร
ก็ใช่ไงครับ เป็นระบบนำเข้าและรายงานข้อมูลเท่านั้น
แต่ที่ให้มีการทำ Logic เพราะว่าคุณต้องการใช้ user กรอกข้อมูลง่ายที่สุด ก็ต้องมาทำ Logic ให้รองรับกับการกรอกข้อมูลแบบนั้น เพราะปกติถ้าก็ข้อมูลไปแบบนั้นตรงๆ มันก็ผิดอยู่นะ
หรือว่าผมเข้าใจอะไรผิดหรือเปล่า
Date :
2010-06-29 14:08:11
By :
50121680
ถามนิดหนึ่งครับ คุณต้องการเก็บรูปแบบการเก็บข้อมูลแบบนี้ไว้ไหม 4790042057-71 หรือต้องการเปลี่ยนรูปแบบเลย จะได้แนะนำถูก จุด
และเลข นี้ 4790042057-71 ตรงส่วน 4 ตัหลัง 57-71 เป็น ลำดับใช่ปะ ส่วนตรงนี้ 47900420 มี 8 หลักเสมอเลยปะ
Date :
2010-06-29 14:13:21
By :
aimoomoo
@ลูกเป็ดขี้เหล่ : ไม่คะ :))
@Stupid gal : INV_NO เก็บแบบนี้หรอคะ 4790042057,4790042058,4790042059,4790042060,4790042061,....,4790042072
แบบนี้ป่าวคะ
Date :
2010-06-29 15:00:53
By :
แพร
คือ user อย่ากป้อนอะไรที่มันง่ายๆเร็วๆจบๆ ใช่ปะคะ นี่โจทย์นึง
ฐานข้อมูลควาหน้าตาเป็นยังไง นี่ก้อโจทย์นึง
อันนี้ก้อตอบไปแล้ว ข้างบนค่ะ
ส่วนค่าจะเป็นแบบนี้
Code (PHP)
INV_NO SHIP_DATE DESTINATION_COUNTRY DOCCUMENT_ARRIVED_DATE BOOK_ID
======================================================================================
4790042057 2010-02-01 USA 2010-02-12 HOME1005-001
4790042058 2010-02-01 USA 2010-02-12 HOME1005-001
4790042059 2010-02-01 USA 2010-02-12 HOME1005-001
4790042060 2010-02-01 USA 2010-02-12 HOME1005-001
4790042061 2010-02-01 USA 2010-02-12 HOME1005-001
4790042062 2010-02-01 USA 2010-02-12 HOME1005-001
ตัวข้อมูลค่าของมันจะซ้ำด้วยธรรมชาติ คืออาจมีข้อมูลหลายชุดถูกสร้างมาในขณะนั้น
แต่เราก็ไม่อาจระบุได้ว่าจะซ้ำ ( คือ จำนวน record มากขนาดไหนต่อวัน )
อันนี้คือคำตอบโจทย์ข้อสอง
มาโจทย์ข้อแรก คุณกำลังจะบอกว่าก้อข้อมูลมันซ้ำกันเยอะอย่างนี้ก้อ key กันทุก record สิ
ตอบว่าไม่ไงคะ ธรรมชาติงานคีย์ข้อมูล ต่อให้ซ้ำกันอย่างน้อย record แรกคุณก้อต้อง key
จิงปะคะ พอ key เส็ด ถ้ามันซ้ำ คุณก้อหา textbox อันนึง มาแปะ บอกว่า ต่อข้อมูลจาก
4790042060-47999999999 ซ้ำกัน เราก้อแค่สร้างจำนวน record มาและ copy ค่าลงไปค่ะ
พอเข้าใจยังคะ
Date :
2010-06-29 15:12:01
By :
blurEyes
สรุปว่า ควรเก็บข้อมูลเป็น invoice ละ 1 record ไปเลย ใช่มั้ยคะ
ทีนี้จะสรุป
ตารางหลัก : ประกอบด้วย
จะมีกรอกรายละเอียด แค่ record เดียว โดยกรอกตาม BOOK_ID ซึ่งใน bookid นี้จะประกอบด้วย CUSTOM_INV อะไรบ้าง ก็ให้ไปแตกไว้อีกตารางนึงชื่อตาราง CUSTOM_INV
ตาราง : CUSTOM_INV
จะใช้ BOOK_ID เป็น foreinge key ในตาราง CUSTOM_INV
อย่างนี้ โอเค ยังคะ
Date :
2010-06-30 14:31:57
By :
แพร
^^
มันก็ใช้งานได้นะคะ
แต่ยังไม่ OPTIMIZED เท่าไหร่
แล้วก็น่าจะยังไม่ผ่านการ NORMALIZED มาด้วย
ยังแตกตารางย่อยออกไปได้ค่ะ
แต่อย่าไปซิเรียสเลยมั้งคะ
อ่อ FIELD ที่เป็น DATE ใช้เป็น DATETIME ไปเหอะค่ะเพิ่มอีก BYTE เดิยว เผื่อไว้
และ REMARK น่าจะเป็น TEXT นะคะ
แล้วก้อน้า ตั้งชื่อให้เป็นมาตรฐานเดียวกันดิคะ
อย่าง
NET_DUEDATE
จะไม่ให้เข้าพวกสักหน่อยหรอคะ >> NET_DUE_DATE
หรือ OVERDUE
กับ OVERDATE
OVERDUE คำเดียวกันไม่เป็นไร
แต่ควรแก้ OVERDATE เป็น OVER_DATE
ถ้าตั้งชื่อใช้ให้เป็นมาตรฐานแล้วจะได้ไม่เกิด ERROR
แบบสดุดขนกระต่ายอย่างเขียนชื่อ field ผิด บ่อยๆค่ะ
Date :
2010-06-30 17:43:44
By :
blurEyes
แวะมาดู
Date :
2010-06-30 19:12:09
By :
plakrim
distinct อะไรเหรอ ก็รหัส invoice มันไม่ซ้ำ ไม่ใช่เหรอ
ที่ผมออกแบบ มันไม่ซ้ำซักอันอ่ะ
มันไม่ได้ซับซ้อน เกินกว่าคนอื่นจะอ่านนะคับ
Date :
2010-06-30 20:02:25
By :
pjgunner
invoice ไม่ซ้ำแต่อย่างอื่นซ้ำดิคะ เคยเจอตารางที่คนคิดแผลงๆ แบบพี่เอี่ยวนี่แหละ
ทำ QUERY สรุปยอดรายการสูงสุด นั่งคิดอยู่สองวัน
ออกแบบให้มันปกติๆธรรมดาๆเหอะค่ะ
Date :
2010-06-30 20:17:06
By :
blurEyes
ผมว่า การออกแบบปรกติ ปรกติผมก็เขียนปรกติ (ยังไงนี่)
แต่ถ้าคิดถึงความเป็นจริงแล้ว ถ้าเป็นระบบที่จำเป็นต้อง optimize เช่นเว็บที่มีรีเควส วันนึงเป็นแสนครั้ง การ optimize นั่นย่อมจำเป็น ที่ผมบอกไปนั้น มันเป็นแค่ solution หนึ่งเท่านั้น ทั้งนี้ต้องมองถึงปัญหาที่จะตามมาไว้ก่อนแล้ว
ซึ่งการ optimize อาจเพิ่มปัญหาในการพัฒนาได้ในภายหลัง แต่ถ้ามองให้ดี มีจุดที่พอจะ ทำได้ ซึ่งมีผลในการลดต้นทุน(ด้าน ทรัพยาการ เซอร์ฟเวอร์)
ตัวอย่างเช่น เว็บเกม
ถ้าเว็บเกม มีคนออนไลน์ 200-500 ตลอดเวลา เฉลี่ย 4 วินาทีต่อครั้ง ลองคำนวนดู 500*4=2000 รีเควส ถ้าเกิดว่า มีคิวรี่ต่ำสุดที่ สองคิวรี่ ก็จะพบว่ามีทั้งหมด 1000 คิวรี่ ต่อวินาที ถ้าเกิดมีการจอยตารางขึ้น 1 ครั้งก็จะมีการสร้างตาราง temp ไว้ด้วย ซึ่งจะยิ่งช้า จะต้องให้ลงทุนกับเซอร์ฟเวอร์ซักเท่าไหร่ และคิดค่าบริการต่อเดือนเท่าไหร่ ถึงจะสามารถแข่งขันได้ การออปติไมซ์ มีประโยชน์เช่นนี้แล และสมมติว่า 500 นี่เป็นแนวต้านแล้ว การออปติไมซ์แบบดีๆ อาจเพิ่มได้มากกว่า สิบเปอร์เซนต์ (อันนี้แล้วแต่ แค่เดาเอา)
Date :
2010-06-30 21:21:22
By :
pjgunner
Load balance : Server 03