Due to the low volume of users and the limited availability of invite codes, this is sufficient.

Hi

NoSQL tarafında da birkaç yıldır deneyimlediğim şey her field'ın object olarak ele alınıp metin verisi olarak dillerin eklendiği senaryo var. ```json "title": { "tr_TR": "Merhaba", "en_US": "Hello" } ```

3) İçeriklerle dilleri ayrı tablolarda muhafaza edip map tablo ile; translate_id 1, content_id 1, lang_id 1, translate_id 2, content_id 1, lang_id 2 gibi.

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.

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)

Bir dönem her köşe başında çoğalıp kaybolan X işletmeleri gibi görüyorum abi. Hepsi kaybolsa da Tw*tter kaybolmuyor sanki.

Because of strict limits on both user numbers and invites, Buggysky has failed to explode.

I still do not get why you are restricting membership and giving out so few invites. Is this the way you tackle problems from the get-go?

I still do not get why you are restricting membership and giving out so few invites. Is this the way you tackle problems from the get-go?