Вопрос конечно интересный… Смотря какая стоит цель и от чего зависит принятие решения. В свободном доступе вряд ли в обозримом будущем появится похожее решение.
Стоит ли заморачиватся с реализацией всего этого?
Существенный недостаток ShopKeeper, как и другого имеющегося магазина (так и не названного автором), в том, что товары привязаны к документам MODx. Это, во-первых, существенно ограничивает количество товаров – при десятке тысяч могут возникнуть проблемы, а во-вторых не позволяет гибко подходить к описанию параметров товара – действительность богаче, чем возможности TV. То есть использование дополнительной таблицы для товаров может быть очень полезным, хотя и требует написания дополнительных программ. Да и логика работы ShopKeeper задана достаточно жестко и не позволяет настраивать ее в широких пределах.
Мне кажется, для сообщества было бы полезнее написать модуль управления товарами для ShopKeeper’a.
Лично я считаю, что она слишком простая. Я при создании своей программы смотрел известные магазины и прикидывал – смогу ли я описать их в рамках своей модели. В результате модель все усложнялась, хотя в итоге далеко не все варианты в ней можно описать (про реализацию сейчас не идет речи – если в базе описаны особенности товара, то хотя бы теоретически все можно реализовать). При этом цель была в том, чтобы настройку магазина можно было проводить с помощью файлов конфигурации и шаблонов, а программа работала с любым типом магазина. Мне кажется, начать лучше работу над чем-то более простым, а к магазину (или каталогу товаров) приступать, когда будет больше опыта.
В качестве некоего универсального каталога предложенная структура прокатит?
Думаю, для сайтов, на которых должны быть представлены такие большие магазины - модикс не самое удачное решение. Придется писать слишком много всего - стандартные средства не отличаются быстротой, которая требуется на известных ресурсах (а небольшим сайтам вряд ли понадобятся интернет-магазины с десятком тысяч позиций).
при десятке тысяч могут возникнуть проблемы
Есть ли пример, который данная структура не сможет описать?
Лично я считаю, что она слишком простая.
Мне кажется, начать лучше работу над чем-то более простым, а к магазину (или каталогу товаров) приступать, когда будет больше опыта.По своему опыту могу сказать: Научился крутить педали - садись на 2 колеса! Набьешь пару шишек, но научишься.
стандартные средства не отличаются быстротой, которая требуется на известных ресурсах.
Все зависит от специфики – в некоторых направлениях номенклатура очень большая, и интернет-магазин торгует товарами, которого у него нет на складе. При поступлении заказа товар берется у поставщика и продается покупателю. Так работают многие интернет-магазины, продающие различную технику, комплектующие, запчасти, мебель и другие товары. То есть при сравнительно небольшом потоке посетителей не слишком большой магазин должен работать с огромным ассортиментом. При хранении товаров в отдельной таблице проблем при нескольких десятках тысяч наименований не возникает, при этом документов MODx будет всего несколько сотен или несколько тысяч.
небольшим сайтам вряд ли понадобятся интернет-магазины с десятком тысяч позиций
Базовой функционал вы построите и на предложенной структуре, но чтобы прикрутить "с этим товаром чаще всего покупают", "похожие товары", "выбор пользователей" и прочие вкусности понадобится нечто большее.
Есть ли пример, который данная структура не сможет описать?
Например, я продаю валенки, для них заданы название модели и базовая цена. Также имеются параметры веса и типа шерсти – эти параметры взаимосвязаны, и для каждой пары задан коэффициент цены, а пар может быть много. Для любой пары возможен вариант – подшитые или неподшитые со своими коэффициентами цены, а также каждый вариант может выпускаться в одном из двадцати цветов, причем для каждого цвета должно иметься название и файл с изображением образца. И еще каждый вариант товара может быть разного размера. При этом я не хочу описывать все возможные комбинации материала, «подшитости», размера и цвета, а хочу указать, например, каждый цвет только один раз. И в этом же магазине я продаю галоши, для которых цвет и материал всегда один, а меняться может только размер и вес, связанный с размером – мне не нужны при вводе и хранении информации лишние поля. И еще я хочу иметь возможность проводить акцию, во время которой определенные товары будут продаваться по специальной цене, но при этом основная цена должна быть восстановлена по окончании акции.
Есть ли пример, который данная структура не сможет описать?