แนวทางการออกแบบฐานข้อมูลหลายภาษา (Multi-Language Database)

Multi-Language Database มีหลายวิธีในการปรับใช้ข้อมูลแบบหลายภาษาในฐานข้อมูลของคุณ แต่มีเพียงวิธีเดียวที่ใช้งานได้ยาวนานและคุ้มค่า แนวคิดของการแปลเป็นภาษาท้องถิ่นมีความสำคัญต่อการพัฒนาแอปพลิเคชันซอฟต์แวร์ โดยเฉพาะอย่างยิ่งเมื่อขอบเขตของแอปพลิเคชันนั้นเป็นสากล การรองรับหลายภาษาเป็นสิ่งสำคัญที่ต้องพิจารณา การออกแบบฐานข้อมูลที่รองรับแอปพลิเคชันหลายภาษาทำให้คุณสามารถกระจายตลาดเป้าหมายและเข้าถึงลูกค้าได้มากขึ้น นอกจากนี้ การออกแบบ ฐานข้อมูลดังกล่าวอาจเป็นส่วนหนึ่งของกลยุทธ์ระยะยาวของคุณสำหรับการออกแบบระบบที่พร้อมแปลเป็นภาษาท้องถิ่น

Database ที่ดีควรง่ายที่คุณจะแก้ไขแอปพลิเคชันหรือเพิ่มฟังก์ชันใหม่ในขณะที่ยังคงรองรับหลายภาษา โดยไม่ต้องเพิ่มความพยายามหรือค่าใช้จ่ายเพิ่มเติม นอกจากนี้ยังควรง่ายที่คุณจะรวมภาษาใหม่โดยไม่ต้องแก้ไขแอปพลิเคชันมากนัก

คำแนะนำของฉันในที่นี้คือให้เลือกการออกแบบ Database แบบที่มีฟังก์ชันการทำงานและความยืดหยุ่นมากกว่าเสมอ บางครั้งเราคิดผิดว่าแอปพลิเคชันของเรามีขนาดเล็กเกินไป ซึ่งไม่คุ้มที่จะใช้โครงสร้างข้อมูลที่ซับซ้อนเพื่อแก้ปัญหาต่างๆ เช่น การรองรับหลายภาษา แต่ในที่สุด แอปพลิเคชันนั้นจะเติบโตและเราจะเสียใจที่เลือกใช้วิธีที่ไม่มีความยืดหยุ่นมากพอซึ่งดูเหมือนง่าย ไปดูแนวทางในการออกแบบฐานข้อมูลหลายภาษา (Multi-Language Database) กันเลย

1. แบบเพิ่มคอลัมน์ภาษา

วิธีนี้เป็นวิธีที่ง่ายที่สุด จุดประสงค์หลักคือสร้างคอลัมน์เพิ่มเติมสำหรับแแต่ละภาษาที่ต้องแปลข้อความ

// ตัวอย่าง SQL
SELECT * FROM Products WHERE id = 1

• ความเรียบง่าย ง่ายต่อการนำไปใช้
• สืบค้นง่าย ไม่จำเป็นต้อง JOIN
• ไม่มีรายการที่ซ้ำกัน ไม่มีเนื้อหาที่ซ้ำกัน มีเพียงแถวเดียวสำหรับแต่ละข้อมูล และเฉพาะคอลัมน์ภาษาเท่านั้นที่ซ้ำกัน

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

2. แบบรวมข้อมูลทุกภาษาไว้ในคอลัมน์เดียวกัน

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

// ตัวอย่าง SQL

SELECT id, price, translate.title, translate.detail
FROM Products CROSS APPLY OPENJSON(Products.translate)
WITH (
	lang varchar(2) '$.lang',
	title varchar(100) '$.translate.title’
	detail varchar(100) '$.translate.detail’
) AS translate
WHERE translate.lang = 'th' AND id = 1;

• ความเรียบง่าย ง่ายต่อการนำไปใช้
• สืบค้นง่าย ไม่จำเป็นต้อง JOIN
• ไม่มีรายการที่ซ้ำกัน ไม่มีเนื้อหาที่ซ้ำกัน มีเพียงแถวเดียวสำหรับแต่ละข้อมูล
• การทำให้เป็นมาตรฐานที่เหมาะสม ดูเหมือนเป็นแนวทางที่สะอาดและสัมพันธ์กัน

• ดูแลรักษายาก ใช้งานได้ง่ายสำหรับ 2-3 ภาษา แต่จะยากขึ้นเมื่อคุณมีคอลัมน์จำนวนมากหรือมีหลายภาษา
• ยากที่จะเพิ่มภาษาใหม่ การเพิ่มภาษาใหม่จำเป็นต้องเปลี่ยนโครงสร้างข้อมูล สำหรับแต่ละตารางที่มีเนื้อหาหลายภาษา
• เรียกใช้ข้อมูลยาก SQL ที่เขียนยากจะสะท้อนให้เห็นในเวลาการพัฒนาและอาจทำให้ต้องเสียค่าใช้จ่ายในการบำรุงรักษา

3. แบบหลายแถวตามจำนวนภาษา

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

// ตัวอย่าง SQL

SELECT * FROM Products WHERE lang = "th" AND id = 1

• ความเรียบง่าย ง่ายต่อการนำไปใช้
• สืบค้นง่าย ไม่จำเป็นต้อง JOIN

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

4. แบบเพิ่ม 1 ตารางสำหรับการแปลภาษาทั้งหมด

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

// ตัวอย่าง SQL

SELECT Products.*, title_translate.value as title, detail_translate.value as detail FROM Products
JOIN Translate title_translate ON Products.title_translate_id = title_translate.id
JOIN Translate detail_translate ON Products.detail_translate_id = detail_translate.id
WHERE title_translate.lang = "th"
AND detail_translate.lang  = "th"
AND Products.id  = 1

SELECT Blog.*, title_translate.value as title, detail_translate.value as detail FROM Blog
JOIN Translate title_translate ON Blog.title_translate_id = title_translate.id
JOIN Translate detail_translate ON Blog.detail_translate_id = detail_translate.id
WHERE title_translate.lang = "th"
AND detail_translate.lang  = "th"
AND Blog.id  = 1

• การทำให้เป็นมาตรฐานที่เหมาะสม ดูเหมือนเป็นแนวทางที่สะอาดและสัมพันธ์กัน
• เพิ่มภาษาใหม่ได้ง่าย ไม่ต้องเปลี่ยนโครงสร้างข้อมูล
• การแปลทั้งหมดในที่เดียว ฐานข้อมูลที่อ่านได้/บำรุงรักษาได้

• การเรียกข้อมูลที่ซับซ้อน จำเป็นต้องมีการรวมหลายรายการเพื่อดึงคำอธิบายผลิตภัณฑ์ที่ถูกต้อง
• ดูแลรักษายาก การเรียกข้อมูลที่ซับซ้อนมากเกินไปในการดำเนินการทั้งหมด การแทรก การลบ และการอัปเดต
• การแปลทั้งหมดในที่เดียว ตารางที่หายไปหนึ่งตารางนำไปสู่ปัญหากับตารางทั้งหมด

5. แบบเพิ่มตารางการแปลภาษาสำหรับตารางนั้นๆ

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

// ตัวอย่าง SQL

SELECT * Products
JOIN ProductsTranslate ON Products.id = ProductsTranslate.product_id
WHERE lang = "th" AND Products.id = 1

• การทำให้เป็นมาตรฐานที่เหมาะสม ดูเหมือนเป็นแนวทางที่สะอาดและสัมพันธ์กัน
• เพิ่มภาษาใหม่ได้ง่าย ไม่ต้องเปลี่ยนโครงสร้างข้อมูล
• ชื่อคอลัมน์ ไม่ต้องใช้ "_lang" ต่อท้ายหรืออย่างอื่น
• สืบค้นง่าย ต้องการ JOIN เดียวเท่านั้น

• อาจเพิ่มจำนวนตารางเป็นสองเท่า คุณต้องสร้างตารางการแปลสำหรับตารางทั้งหมดของคุณที่มีคอลัมน์ที่ต้องแปลภาษา

สรุป

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