Slastik
Новичок
многоязычность (в бд)
Прошу не отсылать в поиск, 2 часа вычитывал темы по запросам многоязычность и мультиязычность
вопрос следующий как организовать архитектуру хранения в базе
из поиска по форуму и факу выделил два приемлимых варианта
1. Согласно http://phpclub.ru/faq/multilang - архитектура
2. Согласно сообщению от Simm
http://phpclub.ru/talk/showthread.php?postid=477658#post477658
Чаще ссылаются на вариант 1.
В своем приложении я стал использовать его
Но вот какие минусы я вижу.
1. Количество таблиц практически удвоилось
2. При каждой выборке данных необходимо использовать join что скажется в дальнейшем на быстродействие, так как мой проект предпологает высокую нагрузку, кроме того при join происходит filesort (например при сортировке по дате) которого никак нельзя избежать при такой архитектуре. Что есть опять же не хорошо с точки зрения нагрузки.
Например запрос который не удается оптимизировать при такой структуре
SELECT `articles`.`id`, `articles`.`date_create`, `articles_txt`.`title` FROM `articles`
INNER JOIN `articles_txt` ON articles_txt.article_id = articles.id WHERE (is_active = '1') AND (articles.rubric_id = '1') AND (lang_id = 1) ORDER BY `date_create` DESC LIMIT 2
из за обращений к lang_id что лежит в другой таблице
Вариант два позволяет сделать выборки чисто по индексу. Но предпологает дублирование не уникальных данных.
Есть ли смысл переходить на второй вариант, какие могут вылезти неудобства при его использовании и чем может грозить избыточность
Спасибо
Прошу не отсылать в поиск, 2 часа вычитывал темы по запросам многоязычность и мультиязычность
вопрос следующий как организовать архитектуру хранения в базе
из поиска по форуму и факу выделил два приемлимых варианта
1. Согласно http://phpclub.ru/faq/multilang - архитектура
2. Согласно сообщению от Simm
http://phpclub.ru/talk/showthread.php?postid=477658#post477658
Чаще ссылаются на вариант 1.
В своем приложении я стал использовать его
Но вот какие минусы я вижу.
1. Количество таблиц практически удвоилось
2. При каждой выборке данных необходимо использовать join что скажется в дальнейшем на быстродействие, так как мой проект предпологает высокую нагрузку, кроме того при join происходит filesort (например при сортировке по дате) которого никак нельзя избежать при такой архитектуре. Что есть опять же не хорошо с точки зрения нагрузки.
Например запрос который не удается оптимизировать при такой структуре
SELECT `articles`.`id`, `articles`.`date_create`, `articles_txt`.`title` FROM `articles`
INNER JOIN `articles_txt` ON articles_txt.article_id = articles.id WHERE (is_active = '1') AND (articles.rubric_id = '1') AND (lang_id = 1) ORDER BY `date_create` DESC LIMIT 2
из за обращений к lang_id что лежит в другой таблице
Вариант два позволяет сделать выборки чисто по индексу. Но предпологает дублирование не уникальных данных.
Есть ли смысл переходить на второй вариант, какие могут вылезти неудобства при его использовании и чем может грозить избыточность
Спасибо
