Yakında multilang içerik desteğe sahip olacak katalog (php + mysql) üzerinde çalışıyor olacağım. Ve şimdi ben veritabanı yapı tasarımı için en iyi yaklaşım olarak düşünüyorum. Şu anda ben multilang taşınması için 3 yolları bkz:

1) Her dil belirli bir veri için ayrı tablolar olması, yani schematicly bu gibi bakacağız:

• Orada, Main_Content_Items bir tablo olabilir kimliği, creation_date gibi tercüme edilemez temel veri depolama, vurur, böylece üzerinde oylama olacak - bu tek olacak ve tüm diller için sevk edecektir.

Ve burada her dil için dublicated edilecek tablolar şunlardır:

• Common_Data_LANG table(example: common_data_en_us) (tercüme edilebilir ortak / "statik" alanlar depolamak, ama ENY katalog öğe için mevcut: böylece başlık, açıklamaya ve ...)
• Extra_Fields_Data_LANG table (storing extra fields data that can be translated, but can be different for custom item groups, i.e. like: | id | item_id | field_type | value | ...) Then on items request we will look in table according to user/default language and join translatable data with main_content table.

Artıları:

• biz bir sorgu yalnızca en sık güncellenen "ana" verileri (örneğin vurur, oy ...) güncelleyebilirsiniz
• Biz 'lang' alanı ile yalnızca bir tablo kullanan yapısı ile karşılaştırıldığında 4 veya daha fazla dil varsa, biz o dublicate veri 4x veya daha fazla kez gerekmez. Yani MySQL sorguları (örneğin) 400000 veya daha ziyade katalog kayıtları 100.000 geçmesi için daha az zaman alacaktır

Eksileri:

• Her dil için +2 masalar

2) İçerik tablolarda 'lang' alanını kullanarak:

• Main_Content_Items table (ID, creation_date gibi tercüme edilemez temel veri depolama vurur, böylece on oylama ...)
• Common_Data table (tercüme edilebilir ortak / "statik" alanlar depolamak, ama ENY katalog öğe için mevcut: | id | item_id | lang | başlık | azalan | vb ...)
• Extra_Fields_Data table (storing extra fields data that can be translated, but can be different for custom item groups, i.e. like: | id | item_id | lang | field_type | value | ...) So we'll join common_data and extra_fields to main_content_items according to 'lang' field.

Artıları:

• biz bir sorgu yalnızca en sık güncellenen "ana" verileri (örneğin vurur, oy ...) güncelleyebilirsiniz
• içerik veri için biz sadece 3 tablo

Eksileri:

• biz custom_data ve tüm diller için veri ile dolu extra_fields tablo var, bu yüzden onun X zaman büyük ve sorgular daha yavaş çalışacak

2. yol olarak, ama Main_Content_Items tablo ile 3) Aynı 'lang' alanına sahiptir Common_Data, ile birleşti:

Artıları:

• ? ...

Eksileri:

• her dil için birlikte en sık güncellenen "ana" verileri (örneğin vurur, oy ...) güncelleştirmesini güncellemeniz gerekir
• biz custom_data ve tüm diller için veri ile dolu extra_fields tablo var, bu yüzden onun X zaman büyük ve sorgular daha yavaş çalışacak

"Ne iyi" ve "niçin" hakkında önerilerinizi duymak mutluluk duyacağız? Ya da daha iyi yolları vardır?

Şimdiden teşekkürler ...