mysql оптимизация

1.Сколько товаров ?

Я так понимаю, что данные в таком виде:

id | массив[русский], массив[английский] и т.д. |

Для выборки по номеру всё равно, можно выводить и потом элемент массива брать. А вот с поиском уже проблематично.

Идеально иметь такую таблицу

id | русский | английский | и т.д.

около 600 * до 20 языков для каждого

nat000 добавил 11.03.2009 в 16:27

php кеширование уже есть, нагрузка всеравно высокая

при 600 товарах нагрузка ?

вы смеетесь ?

600*20 = 12000 , но нагрузка не из-за количества а из-за высокой посещаемости , тоесть частоты обращения..

плюс около 25 серверов используют эту базу центрального сервера

1. в один момент времени нужно все 12000 товаров ?

2. все ровно в упор не вижу нагрузку.

3. 25 серверов одновременно долбят Вас

4. банально просто нет оптимизации мускула

5. я могу вам помоч если хотите

6. мне нужно запросы от вас или доступ.

7. я посмотрю и дам рекомендации - опыт в бд - более 8 лет.

Надо делать 3-ю атомарную форму плюс расставить правильно индексы. Если это узкое место.

Правильная атомарная форма товара будет выглядеть примерно так

/**

* Таблица языковых версий

* Тут индефикатор языков и название

**/

Language

id | name

/**

* Таблица продуктов

* Содержит индификатор продукта, и другие данные наприме код и цену не зависящие от языков

**/

Product

id | code | price

/**

* Таблица описания продуктов

* Содержит индификатор продукта на который ссылается и версии языка, а так же данные зависящие от языков

* Например короткое и полное описание

**/

id | id_product | id_lang | short_desc | full_desc

Если что, я могу Вас проконсультировать или выполнить аудит сайта.

Конкурирующяяя фирма ! )))))

но а так все правильно . иммено я это и сказал. выше.

Можно расмотреть еще идею, когда делать 20 колонок( 20 языков ЖЕ у TC) на поле с наименованием - типа prd_descr_rus, prd_descr_eng, prd_descr_ua

Тоже иногда имеет право на жизнь, хотя как знать, все таки 20 языков ( многовато.

________

>Тоже иногда имеет право на жизнь, хотя как знать, все таки 20 языков ( многовато.

Имеет, если не будут добавлятся и менятся языки, и так все таки имхо легче без хардкора в программном методе описывать. Не забивать маппинг ua => 'short_desc_ua', а просто указывать джойн по примари полю, поверте это будет очень легкий и быстрый запрос который не создаст нагрузки.

Хотя опять таки надо смотреть на архитектуру приложения.

джоин в мускуле - не очень по производительности. имхо. нужно протестировать как лучше будет на тестовом стенде Коллега.