بهترین طراحی پایگاه داده برای داده های چند زبانه چیست؟

بهترین طراحی پایگاه داده برای داده های چند زبانه چیست؟

در این مقاله، چند روش برای طراحی مدل داده برای بومی سازی مورد بحث قرار می گیرد تا بتوانید محتوای خود را به زبان های مختلف مدیریت کنید.

1. روش ستونی اول

این راه حل ساده ترین است. هدف اصلی ایجاد یک ستون اضافی برای هر متنی است که باید ترجمه شود.

مزایا:

     سادگی - اجرای آسان
     پرس و جو آسان - بدون نیاز به JOIN
     بدون تکرار - محتوای تکراری نداشته باشید (فقط یک ردیف برای هر رکورد وجود دارد و فقط ستون های زبان تکراری هستند)

معایب:

     سخت است - برای 2 تا 3 زبان به روشی آسان کار می کند، اما وقتی ستون های زیادی دارید یا زبان های زیادی دارید واقعاً سخت می شود.
     افزودن زبان جدید سخت است – افزودن زبان جدید به تغییرات طرح (و حقوق دسترسی ویژه برای کاربران DB) برای هر جدول با محتوای چند زبانه نیاز دارد.
     فضای ذخیره‌سازی - اگر همه ترجمه‌ها لازم نباشد (مثلاً در برخی مکان‌ها باید همیشه از زبان پیش‌فرض استفاده شود) ممکن است باعث داده‌های اضافی یا فیلدهای DB خالی شود.
     نیاز به ساخت ساعت - بسته به زبان با چه ستونی کار می کنید.

2. روش ستونی دوم

این راه حل ساده ترین است. هدف اصلی ایجاد یک ستون اضافی برای هر متنی است که باید ترجمه شود.

مزایای

     سادگی - اجرای آسان
     پرس و جو آسان - بدون نیاز به JOIN
     بدون تکرار - محتوای تکراری نداشته باشید (فقط یک ردیف برای هر رکورد وجود دارد و فقط ستون های زبان تکراری هستند)
     عادی سازی مناسب - به نظر یک رویکرد تمیز و رابطه ای است

معایب

     سخت است - برای 2 تا 3 زبان به روشی آسان کار می کند، اما وقتی ستون های زیادی دارید یا زبان های زیادی دارید واقعاً سخت می شود.
     افزودن زبان جدید سخت است – افزودن زبان جدید به تغییرات طرح (و حقوق دسترسی ویژه برای کاربر DB) برای هر جدول با محتوای چند زبانه نیاز دارد.
     پرس و جو سخت - نوشتن پرس و جوهای دشوار در زمان توسعه منعکس می شود و همچنین می تواند هزینه تعمیر و نگهداری داشته باشد.

3. روش چند ردیفی

این راه حل مشابه راه حل بالا است، اما به جای کپی کردن مطالب در ستون، این کار را در ردیف انجام می دهد.
 

مزایای

     سادگی - اجرای آسان
     پرس و جو آسان - بدون نیاز به JOIN

معایب

     نگهداری سخت است - هر ستونی که ترجمه نمی شود باید در تمام ردیف های هر زبان تغییر کند. به عنوان مثال، تغییر قیمت برای یک محصول نیازمند تکرار این عملیات برای همه زبان‌ها است
     افزودن زبان جدید دشوار است - به تکرار عملیات درج برای هر زبان نیاز دارد (کلون کردن رکورد برای زبان پیش‌فرض)
     محتوای تکراری - برای تمام ستون هایی که ترجمه نشده اند، محتوای تکراری زیادی خواهید داشت

4. روش استفاده از جدول ترجمه واحد

به نظر می رسد این راه حل از دیدگاه ساختار پایگاه داده تمیزترین راه حل باشد. شما تمام متن هایی را که باید ترجمه شوند در یک جدول ترجمه ذخیره می کنید. این بیشتر برای وب سایت های پویا مناسب است و دارای تعداد زیادی زبان هستند یا قصد دارند در آینده زبان جدیدی اضافه کنند و می خواهند این کار را به راحتی انجام دهند.
 

مزایا

     عادی سازی مناسب - به نظر یک روش تمیز و رابطه ای است
     سهولت در افزودن زبان جدید - نیازی به تغییرات الگو ندارد
     همه ترجمه ها در یک مکان - پایگاه داده قابل خواندن/نگهداری است.

معایب

     پرس و جو پیچیده - چندین اتصال لازم برای بازیابی توضیحات محصول صحیح است
     نگهداری سخت - پرس و جوی بیش از حد پیچیده در همه عملیات: درج، حذف و به روز رسانی
     همه ترجمه ها در یک مکان - یک جدول گم شده منجر به مشکلات جهانی می شود

5. روش استفاده از جدول ترجمه اضافی

این یک تنوع از روش فوق است و به نظر می رسد نگهداری و کار با آن آسان تر باشد. برای هر جدولی که اطلاعاتی را ذخیره می کند که ممکن است نیاز به ترجمه داشته باشد، یک جدول اضافی ایجاد می شود. جدول اصلی فقط داده های غیر حساس به زبان و جدول جدید تمام اطلاعات ترجمه شده را ذخیره می کند.
 

مزایا

     عادی سازی مناسب - به نظر یک روش تمیز و رابطه ای است
     سهولت در افزودن زبان جدید - نیازی به تغییرات الگو ندارد
     ستون ها نام خود را حفظ می کنند - به پسوند "_lang" یا چیز دیگری نیاز ندارد
     پرس و جو آسان - پرس و جو نسبتا ساده (فقط یک JOIN مورد نیاز است)

معایب

     ممکن است تعداد جداول را دوبرابر کند - شما باید برای تمام جداول خود که دارای ستون هایی هستند که باید ترجمه شوند، جداول ترجمه ایجاد کنید.