เท่าที่รู้ ฐานข้อมูลยาวมากๆ หมายความว่ามีโอกาสที่จะมีข้อมูลที่ซ้ำซ้อนสูง ตอนผมทำ project ผมทำตารางเล็กๆ แยกทุกตัวตามที่เรียนมาเกี่ยวกับระบบฐานข้อมูล

ท้ายสุด โดนหัวหน้าภาคด่า ว่าทำแยกทำไมเยอะแยะ ตอนนี้ harddisk ถูกจะตาย ไม่จำเป็นต้องแยกปานนั้น

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

ตอนที่ผมทำ แยกหมดทุกตาราง จนไม่มีโอกาสที่จะซ้ำเลยนอกจากชื่อคน ha ha โดนด่าเช็ด

การแตกตารางบ้างครั้งใช้ enum datatype ช่วยได้ หรืออย่างเช่นพวกรายชื่อประเทศ หรือจังหวัดอาจจะใช้พวก xml, json หรือ array (native data-type ในภาษานั้น ๆ) เข้าช่วยแทนครับ ชนิดข้อมูลที่อ้างอิงที่ไม่มีการเปลี่ยนแปลงบ่อย ๆ ใช้แนวคิดนี้ช่วยได้เยอะ และใน field นั้น ๆ ใส่แค่ index หรือ key ของ value นั้น ๆ แทนก็ช่วยได้เยอะครับ

แต่แนวคิดส่วนของ native data-type อาจจะไม่เหมาะกับภาษาที่ต้อง compile อาจจะใช้ xml/json แทนก็เป็นทางออกที่ดี

อีกอย่างที่ใช้บ่อย ๆ คือใช้ gettext (mo file) เข้าช่วย ;P หรือ file base database พวก sqlite

Ford AntiTrust’s Blog | PHP Hoffman Framework

มันมีผลนิดหน่อย แล้วแต่สถานการณ์ต่างๆ ขออธิบายยาวๆ ล่ะกันนะครับ (ขอยกตัวอย่างใน MySQL นะครับ ใช้เป็นแค่นี้)

ในประเภทของฟิลด์ที่เก็บข้อความ สั้นๆ ทั้ว ไป ก็จะเป็น CHAR กัน VARCHAR

สองตัวนี้ต่างกันที่ CHAR(50) จะใช้เนื้อที่ 50 Bytes ตลอด ไม่ว่าข้อมูลจะยาวแค่ไหน แต่ VARCHAR(50) จะใช้เนือที่ 1 + n Bytes โดยที่ n = ความยาวข้อมูล นั่นก็คือ จะใช้เนื้อที่มากที่สุด 51 Bytes โดย 1B ที่เพิ่มมา คือเก็บความยาวของข้อมูล (เพราะมันไม่คงที่ เลยต้องเก็บไว้ด้วย ว่ามันยาวเท่าไหร่)

ถามว่า เอ๊ะ.. แล้วงี้ ใครจะไปใช้ CHAR เปลืองตาย ใช้ VARCHAR ไม่ดีกว่าเหรอ?

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

ส่วนฟิลด์ประเภทข้อความยาวๆ จะมี TINYTEXT, TEXT, MEDIUMTEXT และ LONGTEXT ก็เก็บข้อมูลได้ยาวขึ้นเรื่อยๆ ตามชื่อของมัน และจะมี byte ที่เก็บขนาดข้อมูลมากขึ้น เช่น ของ tinytext ใช้ 1B เท่า varchar, text ใช้ 2B, medium = 3B (แต่ขนาดตรงนี้ไม่ค่อยมีผล เพราะแค่ไม่กี่ไบต์)

ส่วนการทำ index นั้น มันสามารถกำหนดได้ครับ ว่าฟิลด์นี้จะให้อินเด็กซ์กี่ตัวอักษร เช่น ฟิลด์ขนาด 10 ตัวอักษร แต่เราให้อินเด็กซ์แค่ 3 ตัวแรกก็ได้

สรุปโดยรวมก็คือ แทบจะไม่มีผล แค่อาจจะทำให้ใช้เนื้อที่มากขึ้นโดยไม่จำเป็น โดยเฉพาะการใช้ฟิลด์ประเภท fixed size (CHAR)

---------- iPAtS

From WordNet (r) 2.0 (August 2003) [wn]:
redundancy
n 1: repetition of messages to reduce the probability of errors
in transmission
3: (electronics) a system design that duplicates components to
provide alternatives in case one component fails

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

อันนี้ความหมายสำหรับการออกแบบระบบเพื่อป้องกันความผิดพลาดครับ โดยมีการเพิ่มองค์ประกอบที่ทำหน้าที่เดียวกันอย่างน้อยสององค์ประกอบเพื่อให้นำมาใช้แทนได้ในกรณีที่องค์ประกอบที่เหลือพังหน่ะครับ

หรือการออกแบบให้เอาข้อมูลใส่ไว้ใน Harddisk หลายๆ ตัวอย่าง Raid 0 เพื่อป้องกันความผิดพลาด อะไรแนวนั้น

ตามความหมายนี้ในแวดวง Database ก็น่าจะใช้อีกคำนึงคือ Replicate มากกว่าครับ

สำหรับในกรณีของ Database โดยตรงนี้ น่าจะหมายถึง
2: the attribute of being superfluous and unneeded; "the use of
industrial robots created redundancy among workers" [syn:
{redundance}]
4: repetition of an act needlessly

2: การที่มีมากเกินไป หรือเกินความต้องการ
4: การทำซ้ำๆ ที่ไม่ได้ต้องการ

Data redundancy ก็จะหมายถึง ความซ้ำซ้อนของข้อมูล
สำหรับ Database เราก็จะใช้วิธีแก้โดย Normalization ตาม ค.ห. 1 และ 2 นั่นแหละครับ

ผมเชื่อว่า สุดท้าย คุณสามารถจัด environment แล้ววัดค่าได้ในที่สุด

แต่ผมกลับมองอีกภาพหนึ่ง

ใจเย็นๆครับ ผมมองว่านี่คือ micro-optimization ครับ

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

ถ้าคุณคิดจะปรับแต่ง optimize ระบบ ผมอยากให้คุณทำการวัดแล้วแยกแยะให้ได้จริงๆว่า นี่เป็นเป้าหมายที่คุ้มค่าสิ่งที่คุณต้องเสียไปที่คุณจะทำ (เช่น เวลาที่เสียในการปรับแก้, ความง่ายในการดูแลรักษาภายหลัง, ความสามารถในการเข้าใจ, ฯลฯ) เคยได้ยินคำว่า "premature optimization is the root of all evil" ใช่รึเปล่าครับ ผมเชื่อว่ามันมีจุดที่เป็น bottleneck อื่นๆ มากมายที่อยู่ในระบบคุณ บางที bottleneck อาจจะเป็นส่วนอื่นๆในระบบคุณก็ได้

วัดก่อน, หา candidate ประเมินผลกระทบ, เลือก, tune/improve, ทดสอบใหม่ แล้วพอถึงจุด SLA (service level agreement) แล้ว พอ อย่าไปหมกมุ่นกับมันครับ

:)ลองเช็คดูข้อจำกัดของโปรแกรมระบบฐานข้อมูลที่เลือกใช้ ขอยกตัวอย่าง MySQL5.0 จาก http://dev.mysql.com/doc/refman/5.0/en/column-count-limit.html
[Every table has a maximum row size of 65,535 bytes. This maximum applies to all storage engines, but a given engine might have additional constraints that result in a lower effective maximum row size.

The maximum row size constrains the number of columns because the total width of all columns cannot exceed this size. For example, utf8 characters require up to three bytes per character, so for a CHAR(255) CHARACTER SET utf8 column, the server must allocate 255 × 3 = 765 bytes per value. Consequently, a table cannot contain more than 65,535 / 765 = 85 such columns] (เหลือ 64 columns ใน MySQL6.0)

โอ้ว ได้ความรู้อีกแล้ว