Andrzej Wielski: Я так понимаю, тут на каждое локализованное поле будет 1 запись в "localization" таблице, если записей у модели "товар" будет 100 000, и у каждой записи будет по 5 локализованных поля то это уже 500 000 записей в таблице "localization". Т.е. не 100 000 моделей, а 100 000 записей :-)
Andrzej Wielski: На мой взгляд, такая реализация работоспособна на малых и средних "количествах" моделей, если их будет хотя-бы тысяча и в каждой модели 5 полей то уже будет 1000*5 полей в самой таблице локализации, а если добавить еще 1 язык то будет 1000*5*2 полей. А если будет 100 000 записей то получим медленный кошмар. Если я не прав - пожалуйста поправьте.
Раздумывал как обойти эту проблему, и решил что будет более разумно (с точки зрения быстродействия для реляционных баз, которые построчно таблицы считывают) сделать по таблице на язык, т.е. основная таблица + табл для языка 1 + табл для языка 2 , у которых будет общим primary_id и некоторые поля (какие укажем), которые желательно хранить в одном месте, либо синхронизировать средствами БД.
Подскажите пожалуйста, возможно ли тут применить полиморфную связь, и стоит ли.
Что-то мудрил - мудрил, и не понял как мне сделать так, чтоб при добавлении в основной таблице 1 записи, добавлялись записи и в остальных таблицах с таким-же primary_id.
P.S. На данный момент сделал пока дублирующие поля в той-же таблице, без полиморфных связей, переопределив методы setAttribute и getAttribute, которые сами вставляют, в зависимости от текущей локализации, значение. Например в английской локализации атрибут name будет взят из name_en поля.
P.S.S. Делал так, потому что у меня пока что актуально два языка, и вроде бы не планируется еще... но всё-же хочется научится правильно :-)
Iktash уже всё написал :-) раз $_POST у вас пустой то 100% он не доходит, если отправляете через обычную форму то не забываем там указать method="POST"
