Многоязычный каталог (с настраиваемыми полями) Разработка структуры БД - PullRequest
0 голосов
/ 12 июля 2010

Скоро я буду работать над каталогом (php + mysql), который будет поддерживать многоязыковой контент. И сейчас я рассматриваю лучший подход к проектированию структуры базы данных. На данный момент я вижу 3 способа многоязыковой обработки:

1) Наличие отдельных таблиц для каждого конкретного языка данных, то есть схематически это будет выглядеть так:

  • Будет одна таблица Main_Content_Items , в которой будут храниться основные данные, которые не могут быть переведены, например, ID, дата создания, совпадения, голоса и т. Д. - это будет только один файл, который будет относиться ко всем языкам.

А вот таблицы, которые будут дублироваться для каждого языка:

  • Таблица Common_Data_LANG (пример: common_data_en_us) (хранение общих / «статических» полей, которые могут быть переведены, но присутствуют для элемента каталога eny: title, desc и т. Д.) *
  • Таблица Extra_Fields_Data_LANG (хранение данных дополнительных полей, которые могут быть переведены, но могут отличаться для пользовательских групп элементов, например: | id | item_id | field_type | value | ...) Затем по запросу товаров мы смотрим таблицу в соответствии с языком пользователя / по умолчанию и объединяем переводимые данные с таблицей main_content .

Плюсы:

  • мы можем обновить «основные» данные (то есть хиты, голоса ...), которые обновляются чаще всего с помощью только одного запроса
  • нам не нужно дублировать данные 4x или более раз, если у нас есть 4 или более языков по сравнению со структурой, использующей только одну таблицу с полем 'lang'. Таким образом, запросы MySql потребуют меньше времени, чтобы просмотреть каталог из 100000 (например) записей, а не 400000 или более

Минусы:

  • + 2 таблицы для каждого языка

2) Использование поля «lang» в таблицах содержимого:

  • Таблица Main_Content_Items (хранит основные данные, которые не могут быть переведены, такие как ID, дата создания, хиты, голоса и т. Д.) *
  • Таблица Common_Data (хранит общие / «статические» поля, которые могут быть переведены, но присутствуют для элемента каталога eny: | id | item_id | lang | title | desc | и т. Д.)
  • Таблица Extra_Fields_Data (хранит данные дополнительных полей, которые могут быть переведены, но могут отличаться для пользовательских групп элементов, например: | id | item_id | lang | type_type | value | ...)) Поэтому мы присоединим common_data и extra_fields к main_content_items в соответствии с полем 'lang'.

Плюсы:

  • мы можем обновить «основные» данные (то есть хиты, голоса ...), которые обновляются чаще всего с помощью только одного запроса
  • у нас всего 3 таблицы для данных контента

Минусы:

  • у нас есть таблицы custom_data и extra_fields, заполненные данными для всех языков, так что его время X больше и запросы выполняются медленнее

3) То же, что и 2-й способ, но с таблицей Main_Content_Items, объединенной с Common_Data, которая имеет поле 'lang':

Плюсы:

  • ...

Минусы:

  • нам нужно обновить «основные» данные (т. Е. Хиты, голоса ...), которые обновляются чаще всего для каждого языка
  • у нас есть таблицы custom_data и extra_fields, заполненные данными для всех языков, так что его время X больше и запросы выполняются медленнее

Будем рады услышать предложения о "что лучше" и "почему"? Или есть лучшие способы?

Заранее спасибо ...

1 Ответ

0 голосов
/ 12 июля 2010

Я дал аналогичный ответ в этом вопросе и выделил преимущества этого метода (для меня было бы, например, важно, чтобы приложение определилось с языком и соответственно построило запрос)изменив только параметр lang в предложении WHERE SQL-запроса.

Это довольно близко к вашему второму решению. Я не совсем понял "extra_fields", но если это имеет смысл,Вы могли бы (!) объединить ее с таблицей common_data. Я бы посоветовал вам не прислушиваться к первой идее, поскольку таблиц будет слишком много, и будет легко потерять отслеживание элементов в них.

К вашему редактированию: я по-прежнему считаю второй подход лучшим (это мое мнение, поэтому оно относительно;)) Я не эксперт по оптимизации, но я думаю, что при правильных индексах и правильной структуре таблицы скорость не должна бытьпроблема.Как всегда, лучший способ найти самый эффективный способ - это использовать оба метода и посмотреть, какой из них лучший, поскольку скорость будет зависеть от данных, структуры, ....

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...