Bu çok parametreli bir konu. Veritabanları collation desteği ile birlikte bir tasarım yapılmalı. sort, uppercase/lowercase, filter gibi kullanımlarda veritabanı tarafına yıkılan süreçlerde veritabanı yeteneği önemli hale geliyor. Bu da hangi veritabanını kullandığına göre tasarım değişikliği demek.
RDBMs ve NoSQL ayrımı da var temelde ama ben bir #postgresql funı olarak NoSQL'i de onunla kullanıyorum. Dil yetenekleri kuşkusuz en iyi olan veritabanı. Genel olarak lokalizasyon konusunu veritabanım çözsün demek benim işime geliyor ve PostgreSQL'e yıkıyorum.
12 yıllık klavye tuş basıcılığı geçmişimde deneyimlediğim 3 farklı senaryo var.
1) Dil tablosu ve dil desteği gereken içerikte lang_id sütunu (Bu durumda id primary key olarak değil, sequence olarak tutulmalı ki content_id 1, lang_id 1-2-3 için olabilmeli)
2) Desteklenmesi gereken dillerin sabit olduğu durumlarda field_tr field_en field_de şeklinde tutulduğuna şahit oldum, hiç kendim dizayn etmedim, efektif gelmiyor bana.
Comments
1) Dil tablosu ve dil desteği gereken içerikte lang_id sütunu (Bu durumda id primary key olarak değil, sequence olarak tutulmalı ki content_id 1, lang_id 1-2-3 için olabilmeli)
translate_id 1, content_id 1, lang_id 1,
translate_id 2, content_id 1, lang_id 2
gibi.
```json
"title": {
"tr_TR": "Merhaba",
"en_US": "Hello"
}
```