это не целесообраззно

ибо потом хрен что обновишь 🙂

Зачем ядро править?

Мы ж про Бд

Нет, не вложенность. У них категории и товары в категориях по моему тоже из коробки

Ну так Бд поправишь потом что то полетит 🙂

при обновлении 🙂

Или у них нет вообще категорий и вложенности категорий?

Т.е. одна категория и туда помещаем товары и на этом ограничена CMS?

То ли я не понимаю, то ли.. ((%

Я только БД видел, саму систему не трогал. Мне хватило.

(((((((((((%

Или у них нет вообще категорий и вложенности категорий?

Они такрой связкой сделали проще вывод на странице )

Поэтому субъективно

раздела выводятся все товары порсто по id раздела )

а не собирают сначала всех родителей подразделов )

раздела выводятся все товары порсто по id раздела )

Я понимаю зачем это сделано, но на большом количестве товаров, всё ляснет

И снова же. Лучше шопкипера ((% это факт.

тоесть это по логике должно быстрее работатаь 🙂 а обьем базы x10 в таблице не так критично

БОльшой объем товара это сколько?

И снова же, не ищите решения, а субъективно говорите ((%

БОльшой объем товара это сколько?

ну от 100 млн

по опыту ОпенКарты тыс на 20 начинает уже подтормаживать хорошо так

Плохой опыт ((%

А на 100 млн товаров использовать cms это зло )

100 млн, мдя.. действительно не понимаете меня,судя по всему

А на 100 млн товаров использовать cms это зло )

Смотря как заточить.

100 млн. товаров это уже не ЦМС нужно

А так, да - зная как можно заточить любую

Смотря как заточить.

Заточить можно что угодно вопрос в целесообразности 🙂

Можно любую cms под это дело заточить, тут же слабое место не в cms, а в структуре хранения информации

Вообще, чаще всего на таких объёмах слабое место это не код, а стукртура хранения данных

Задачи разные. (((%

Был вопрос про "лучше чем ШК"

(;

Я просто сказал, что фу-фу-фу опенкарт

Вот, и субъективно (;

Потому что нет конкретной цели сравнить (;

Я вот ещё не понимаю, почему в evo до сих пор MyISAM используется, а не InnoDB

А из коробки у опенкарта ппц сколько приятностей.

А из коробки у опенкарта ппц сколько приятностей.

Все зависит от задачи если приятности без серьездных допилов перекрывают потребности то да 🙂

Сжатие данные, полноценные индексы - прелести MyISAM. Поэтому скорее всего.

Все зависит от задачи если приятности без серьездных допилов перекрывают потребности то да 🙂

Не знаю какие там "серьезные" допилы могут быть ((% Честно, за все время работы с разными ЦМС еще не встречал таких задач. Может и хорошо.

Например вывести в шапку номер телефона и email ))

Оу..дааа.. серьезное дело ((%

мы тут тролили по этому поводу что надо помойму 6 файлов править что б это сделать ))

Это MVC какие там 6 ?((%

Сжатие данные, полноценные индексы - прелести MyISAM. Поэтому скорее всего.

По моему индексы уже в innoDB нормальные впихнули, сжатие тоже не назвал бы критичной вещью. А вот преимущество от массовой вставки, а так же разбитие каждой таблицы в отдельный файл, для ускорения поиска, по моему знатно решает.

А ещё, внезапно, отсутствие блокировки всей таблицы, на время выполнения запроса

innoDB мне больше пока приятны только транзакции.

Снова же, от задачи зависит. В еволюшен таких задач пока не было.

100 млн. товаров это уже не ЦМС нужно

На 100млн товара нужно торговый центр строить, а не интернет магазин :)

А мне вот чёт везёт, один человек подкидывает задачи где таблицы ТВ получаются по 2-3 млн записей -_-

Ппц ((% сочувствую

На 100млн товара нужно торговый центр строить, а не интернет магазин :)

Ну дык чуть ли не любой автомагазин 🙂

это ж не говорит что все 100млн должны быть доступны 🙂

На 100млн товара нужно торговый центр строить, а не интернет магазин :)

Или торговля электронными платами/резисторами/кондесаторами и т.п.

вернее они есть на сайте а дальше от поставщиков собираются:)

ну да большой ассортимент мелочи

У меня такие задачи только по CRM системам ((:

а так у той же розетки пару лет назад было под 150 тыс товаров всего )

А там любые магазины могут тянуть что нужно.

Делал сайт для сименс, так у них сразу количество товаров от 1млрд.

сейчас наверное чутка по больше они расширяют ассортимент но все равно думаю даже млн нету

Дык, там сервис другой (:

Еволюшен там и не пахнет ((%

Почему нет?

Цели другие.

Управление, админка.

Такие системы не завязаны только на одном, обычно.

Просто товары выносим отдельно от категорий. Структуру каталога осталвяем на эволющине, а управление товарами и заказами выносим в админку в модули

(((% Думаю это лишь часть

И там хоть миллиард товаров. Главное отказаться от структуры хранения всего в тв

Структура БД эволюшен тоже не фонтан

Мягко говоря отказаться (((%

Вообще по хорошему для объём от 1млн, с неизвестным количеством дополнительных полей, вот 100% лучше не использовать mysql

Хотя, вообще можно все доп поля хранить в json, и это нормальный вариант, если не использовать их в поиске

Ужос.

А так же, скорей всего на таких объёмах никому не надо править товары в ручную

Поиск всегда будет (: