Многоязычный каталог (с настраиваемыми полями) Дизайн структуры БД

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

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

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

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

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

Плюсы:

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

Минусы:

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

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

  • Таблица Main_Content_Items (хранящая базовые данные, которые нельзя перевести, такие как ID, Creation_date, Hit, голосов и т. д.)
  • Таблица Common_Data (хранящая общие / "статические" поля, которые могут быть переведены, но присутствуют для любого элемента каталога: | id | item_id | lang | title | desc | и так далее ...)
  • Таблица Extra_Fields_Data (хранящая данные дополнительных полей, которые могут быть переведены, но могут отличаться для пользовательских групп элементов, например: | id | item_id | lang | field_type | value | ...) Итак, мы присоедините common_data и extra_fields к main_content_items в соответствии с полем lang.

Плюсы:

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

Минусы:

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

3) То же, что и второй способ, но с таблицей Main_Content_Items, объединенной с Common_Data, в которой есть поле lang:

Плюсы:

  • ...?

Минусы:

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

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

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


mysql php multilingual custom-fields catalog
person Nickolay    schedule 12.07.2010    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

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

person DrColossos    schedule 12.07.2010
comment
Спасибо за ответ, DrColossos. Я ошибся при описании 1 метода, поэтому ПОСМОТРЕТЬ ФИКСИРОВАННЫЙ ВАРИАНТ. Что ж, основная цель (которая мне очень нравится) в первом методе состоит в том, чтобы мы не путали данные на разных языках, особенно учитывая, что таблица extra_fields может иметь много записей, связанных с элементом в таблице Main_Content_Items, то есть в 2,3 методах если у нас есть 1000 элементов в таблице Main_Content_Items и 4 языка, extra_fields будет иметь 4 * 1000 * 5 (или 10 или более ...) записей. Вот почему я считаю этот метод более производительным, чем два других ... - person Nickolay; 12.07.2010
comment
P.S. О дополнительных_полях: он используется как универсальная таблица для любого дополнительного типа поля (хранится как | id | item_id | field_type | field_value (простое текстовое поле) |), поскольку есть группы элементов, которые могут иметь определенные поля, которых нет у других элементов ( как параметры ноутбука и камеры в скриптах магазина). Таким образом, мы можем только отменить таблицу common_data, перемещая данные ее полей в extra_fields, но я не хочу этого делать, потому что в common_data каждая запись имеет данные нескольких полей, а extra_fields - только данные одного поля на запись (см. Структуру), поэтому я думаю для этого лучше иметь 2 отдельные таблицы. - person Nickolay; 12.07.2010