19/03/2007
Подойдет вообще любая CMS.
Все равно нужен нормальный программер который переделает (добавит функциональности).
Где-то проще сделать, где-то сложнее. Все зависит от того, на сколько CMS дружелюбная к определенному функционалу.
...
Посмотрите на Avalon Shop (это переделанный PhpShop). Очень грамотный интернет-магазин.
Если брать как для вашего примера 003.ru - то я бы построил на AvalonShop-е
Демка тут:
_http://avalonshop.net/demo/index.html
И стоит всего 30 уе (правда с привязкой к домену (зазендено)).
Также его можно скачать и потестить локально. На "дружелюбность" переделки.
Есть правда косяки, но любой даже программер-новичек их исправит.
Ну а Smarty - вообще вещь! Очень сильно упрощает жизнь.
Либо посмотрите на PhpShop (_http://demo.phpshop.ru)
Все равно нужен нормальный программер который переделает (добавит функциональности).
Где-то проще сделать, где-то сложнее. Все зависит от того, на сколько CMS дружелюбная к определенному функционалу.
...
Посмотрите на Avalon Shop (это переделанный PhpShop). Очень грамотный интернет-магазин.
Если брать как для вашего примера 003.ru - то я бы построил на AvalonShop-е
Демка тут:
_http://avalonshop.net/demo/index.html
И стоит всего 30 уе (правда с привязкой к домену (зазендено)).
Также его можно скачать и потестить локально. На "дружелюбность" переделки.
Есть правда косяки, но любой даже программер-новичек их исправит.
Ну а Smarty - вообще вещь! Очень сильно упрощает жизнь.
Либо посмотрите на PhpShop (_http://demo.phpshop.ru)
19/03/2007
QTB:
Тех. поддержка у них на уровне. А со смарти любой дизайн интегрируется без проблем.
На зарубежных сайтах сильно серчают на их поддержку.
Тех. поддержка у них на уровне. А со смарти любой дизайн интегрируется без проблем.
19/03/2007
CMS - это только малая часть того, что нужно для супермаркета, такого как 003.ru.
Если в супермаркете планируется большой объем продаж, необходима мощная поддержка обработки заказов, складского учета, логистики, документооборот, штрихкодирование товаров и документов, статистика, учет продаж, финансовый учет и многое другое.
Едва ли можно назвать супермаркетом Интернет-магазин, в котором обработка заказов сводится к просмотру списоков заказов, установке статуса заказа, выписке счета и другим простейшим действиям.
Такой сложный комплекс стоит хороших денег, для его сопровождения мало одного-двух программистов.
Но при правильном продвижении, выборе товаров, поставщиков, ценовой политике и налаженной логистике он может принести и немалую прибыль.
Если в супермаркете планируется большой объем продаж, необходима мощная поддержка обработки заказов, складского учета, логистики, документооборот, штрихкодирование товаров и документов, статистика, учет продаж, финансовый учет и многое другое.
Едва ли можно назвать супермаркетом Интернет-магазин, в котором обработка заказов сводится к просмотру списоков заказов, установке статуса заказа, выписке счета и другим простейшим действиям.
Такой сложный комплекс стоит хороших денег, для его сопровождения мало одного-двух программистов.
Но при правильном продвижении, выборе товаров, поставщиков, ценовой политике и налаженной логистике он может принести и немалую прибыль.
20/03/2007
slavick:
Сейчас занимаюсь поиском cms для будущего интернет гипермаркет. Сумма вложений в cms и дизайн - 3000-5000$
Требования - чтобы в будущем систему можно было дописывать изменять, под свои нужды. Вообще она должна быть гибкая...
Сейчас занимаюсь поиском cms для будущего интернет гипермаркет. Сумма вложений в cms и дизайн - 3000-5000$
Требования - чтобы в будущем систему можно было дописывать изменять, под свои нужды. Вообще она должна быть гибкая...
Маловато требований для выбора. Под "изменять под свои нужды" и "гибкая" попадает, наверное, 80% всех CMS. Поэтому получить адекватный совет по этим требованиям - невозможно. Посмотрите на магазины конкурентов, прикиньте что потребуется в бэк-офисе и составьте список возможностей, которые совершенно необходимы и которые желательны. Опишите для себя примерно в каком виде Вы бы хотели видеть их реализацию - и вперед, штудировать демки, описания, мучить разработчиков (или участников форума).
А так получается как обычно:
- Петька, приборы!
- 200
- Что 200?
- А что приборы?
Только смотреть надо внимательно, а то часто бывает - выбросишь систему из списка по невнимательности - посмотрел получше, а нужная возможность просто хорошо спрятана.
X-cart - да, миленькая системка, поддержка (~2 года назад) была вполне "на уровне", отвечали очень быстро. Единственное, там были не очень контентные модули (новости, форумы и т.д.) - не знаю как сейчас. Правда, для гипермаркета надо сразу искать и программиста, который будет адаптировать готовое решение. У самих X-Cart цены были вполне "западные".
Александр Фролов:
Если в супермаркете планируется большой объем продаж, необходима мощная поддержка обработки заказов, складского учета, логистики, документооборот, штрихкодирование товаров и документов, статистика, учет продаж, финансовый учет и многое другое.
Если в супермаркете планируется большой объем продаж, необходима мощная поддержка обработки заказов, складского учета, логистики, документооборот, штрихкодирование товаров и документов, статистика, учет продаж, финансовый учет и многое другое.
Обычно большую часть этих задач выполняет учетная система предприятия. Всё равно тут по возможностям никакой более-менее стандартный интернет-магазин ("Озоны" и их вложения в разработку не берем) с ней не сравнится. Вот чем мне, кстати, всегда нравилась OSG - так это тесной связью с 1С.
20/03/2007
Павел Коротов:
Обычно большую часть этих задач выполняет учетная система предприятия. Всё равно тут по возможностям никакой более-менее стандартный интернет-магазин ("Озоны" и их вложения в разработку не берем) с ней не сравнится. Вот чем мне, кстати, всегда нравилась OSG - так это тесной связью с 1С.
Обычно большую часть этих задач выполняет учетная система предприятия. Всё равно тут по возможностям никакой более-менее стандартный интернет-магазин ("Озоны" и их вложения в разработку не берем) с ней не сравнится. Вот чем мне, кстати, всегда нравилась OSG - так это тесной связью с 1С.
Существует две возможности автоматизации и учета продаж. Первая - это совместная работа Интернет-магазина с какой-нибудь внешней учетной системой, вторая - интегрированное решение, когда вся учетная функциональность встроена непосредственно в Интернет-магазин.
Мы предлагаем второе решение (оно уже успешно эксплуатируется более двух лет), при котором требуется только одна внешняя учетная программа - бухгалтерская.
Мне было бы интересно узнать, какие по мнению владельцев Интернет-магазинов, существуют преимущества и недостатки в первом и втором случае.
20/03/2007
Как я понял выбор cms - процесс творческий.
Одни говорят что cms за 3-5к - это хорошо.
Другие требуют минимум 15к.
надо думать и выбирать. спасибо за предложения в письмах. я просмотрю...
Одни говорят что cms за 3-5к - это хорошо.
Другие требуют минимум 15к.
надо думать и выбирать. спасибо за предложения в письмах. я просмотрю...
23/03/2007
Александр Фролов:
Существует две возможности автоматизации и учета продаж. Первая - это совместная работа Интернет-магазина с какой-нибудь внешней учетной системой, вторая - интегрированное решение, когда вся учетная функциональность встроена непосредственно в Интернет-магазин.
Мы предлагаем второе решение (оно уже успешно эксплуатируется более двух лет), при котором требуется только одна внешняя учетная программа - бухгалтерская.
Мне было бы интересно узнать, какие по мнению владельцев Интернет-магазинов, существуют преимущества и недостатки в первом и втором случае.
Существует две возможности автоматизации и учета продаж. Первая - это совместная работа Интернет-магазина с какой-нибудь внешней учетной системой, вторая - интегрированное решение, когда вся учетная функциональность встроена непосредственно в Интернет-магазин.
Мы предлагаем второе решение (оно уже успешно эксплуатируется более двух лет), при котором требуется только одна внешняя учетная программа - бухгалтерская.
Мне было бы интересно узнать, какие по мнению владельцев Интернет-магазинов, существуют преимущества и недостатки в первом и втором случае.
Не владелец, но недостатки (и, соответственно, преимущества) очевидны. В первом случае - издержки, связанные с постоянным перекидыванием информации из одной базы в другую (хотя есть решения, где это не требуется), во втором:
- как уже говорил выше, всё равно отдельно стоящая учетная система будет функциональнее. Просто за счет того, что и разработчиков ресурсов больше, и это - их основной продукт;
- если речь об интернет-магазине существующего предприятия, в компании обычно уже используется какая-то система. Менять ее на нечто экзотическое вряд ли кто-то будет;
- система с управлением через веб-браузер не очень удобна, а отдельный Windows-клиент нивелирует преимущества единой базы данных.
Хотя, у второго варианта может быть и некоторый плюс - если он уже изначально адаптирован к специфике именно интернет-торговли.
25/10/2007
Вставлю свои три копейки..
Многократно слышал мнения, что при базе номенклатуры более чем 10тыс становится невозможным работать с единой бд с интернет-доступом для администрирования товаров. В частности, была произнесена фраза "посмотрите на озон- их проблемы с базой исчезли только после того как они перешли на двухбазную работу"..
Имеется в виду наличие "основной" базы и базы "онлайн" которая обновляется из "основной".
Сам я с таким высказыванием согласен.
Хотелось бы услышать комментарии сведующих товарищей здесь.
Сам пользуюсь самописной системой и могу сказать следующее- при росте номенклатуры- сейчас 2500 товаров - впервую очередь встают проблемы отнюдь не технических "тормозов", а юзабилити- сложно модерировать базу, выползают некоторые огрехи в юзабилити административного интерфейса, которые были абсолютно неважными при малом количестве товара.
Сейчас я выбираю систему для магазина и впервую очередь буду смотреть именно на "вменяемость" интерфейса. На нагрузку на движок БД - естественно, тоже буду смотреть..
Из решений мне пока приглянулась система фирмы i-media, совладелец которой владеет также еще инетмагазинами, под которые и была сделана эта система. Типичный представитель магаза на этом движке- rumag.ru. В нем при взгляде снаружи вроде все логично. Большой минус- контора-производитель совсем неклиентоориентированная- демок нет, посмотреть ничего не дают, а только зовут в офис.
Также, общаясь на прошедшей конференции Оборота с различным народом, выяснил, чтто при некотором упорстве можно юзать и Битрикс, однако надо положить прилично сил на фиксацию багов. В сыром виде Битрикс юзать нельзя- в этом многие люди сходятся.
Многократно слышал мнения, что при базе номенклатуры более чем 10тыс становится невозможным работать с единой бд с интернет-доступом для администрирования товаров. В частности, была произнесена фраза "посмотрите на озон- их проблемы с базой исчезли только после того как они перешли на двухбазную работу"..
Имеется в виду наличие "основной" базы и базы "онлайн" которая обновляется из "основной".
Сам я с таким высказыванием согласен.
Хотелось бы услышать комментарии сведующих товарищей здесь.
Сам пользуюсь самописной системой и могу сказать следующее- при росте номенклатуры- сейчас 2500 товаров - впервую очередь встают проблемы отнюдь не технических "тормозов", а юзабилити- сложно модерировать базу, выползают некоторые огрехи в юзабилити административного интерфейса, которые были абсолютно неважными при малом количестве товара.
Сейчас я выбираю систему для магазина и впервую очередь буду смотреть именно на "вменяемость" интерфейса. На нагрузку на движок БД - естественно, тоже буду смотреть..
Из решений мне пока приглянулась система фирмы i-media, совладелец которой владеет также еще инетмагазинами, под которые и была сделана эта система. Типичный представитель магаза на этом движке- rumag.ru. В нем при взгляде снаружи вроде все логично. Большой минус- контора-производитель совсем неклиентоориентированная- демок нет, посмотреть ничего не дают, а только зовут в офис.
Также, общаясь на прошедшей конференции Оборота с различным народом, выяснил, чтто при некотором упорстве можно юзать и Битрикс, однако надо положить прилично сил на фиксацию багов. В сыром виде Битрикс юзать нельзя- в этом многие люди сходятся.
02/11/2007
Понятно, что решения на базе PHP и MySQL невозможно достичь хороших показателей производительности и устойчивости.
Озон изначально сделал правильную ставку, выбрав решение на базе .NET платформы, с использованием MS SQL как сервера базы данных. И дело не в том, что они разделяют офф-лайн и он-лайн версии.
Это больше автоматизация бизнес-логики, чем ускорение работы их магазина.
Если Вы изначально сориентировались на серьезное решение нужно либо писать что-то под заказ либо использовать решения другого уровня, например ASP.NET + MS SQL Server ( пример такого решения для создания интернет-магазина)
Также, одной из альтернатив является магазины написанные на чистом C++, откомпилированные на сервере, но трудоемкость таких разработок очень высокая.
Озон изначально сделал правильную ставку, выбрав решение на базе .NET платформы, с использованием MS SQL как сервера базы данных. И дело не в том, что они разделяют офф-лайн и он-лайн версии.
Это больше автоматизация бизнес-логики, чем ускорение работы их магазина.
Если Вы изначально сориентировались на серьезное решение нужно либо писать что-то под заказ либо использовать решения другого уровня, например ASP.NET + MS SQL Server ( пример такого решения для создания интернет-магазина)
Также, одной из альтернатив является магазины написанные на чистом C++, откомпилированные на сервере, но трудоемкость таких разработок очень высокая.
04/11/2007
2 buxler
в чем принципиальное различия между решениями на базе mysql+php и ASPdotNet+MSSQL ?
хотел бы получить разумное обоснование, почему "на базе PHP и MySQL невозможно достичь хороших показателей производительности и устойчивости", а на плптформе, на которой предлагется ваш движок- возможно.
в чем принципиальное различия между решениями на базе mysql+php и ASPdotNet+MSSQL ?
хотел бы получить разумное обоснование, почему "на базе PHP и MySQL невозможно достичь хороших показателей производительности и устойчивости", а на плптформе, на которой предлагется ваш движок- возможно.
04/11/2007
2 stanislas
Принципиальные отличия:
1. Платформа .NET (удобная среда разработки, начиная от среды разработки(MS Visual Studio), готовые библиотеки, подключение и использование различных языков программирования). Плюс поддержка и продвижение платформы Microsoft-ом.
2. База данных MS SQL. Можно конечно спорить, но MS SQL - более серьезная СУБД, чем mysql. Единственное преимущество, которое было у mysql - бесплатность, есть и в последних экспресс-версиях MS SQL.
3. Более удобные средства распределенной разработки проектов(несколько разработчиков), в следствии этого меньше ошибок, когда решение разрастается. Можно отнести этот пункт к фактору устойчивости.
4. Функциональные возможности языков.
Если подитожить мысль -
php + mysql удобен для малых и средних проектов,
расширять проект на php достаточно трудоемко.
если же рост кода в проекте очевиден - желательно разрабатывать проект например на .NET, MS SQL.
Принципиальные отличия:
1. Платформа .NET (удобная среда разработки, начиная от среды разработки(MS Visual Studio), готовые библиотеки, подключение и использование различных языков программирования). Плюс поддержка и продвижение платформы Microsoft-ом.
2. База данных MS SQL. Можно конечно спорить, но MS SQL - более серьезная СУБД, чем mysql. Единственное преимущество, которое было у mysql - бесплатность, есть и в последних экспресс-версиях MS SQL.
3. Более удобные средства распределенной разработки проектов(несколько разработчиков), в следствии этого меньше ошибок, когда решение разрастается. Можно отнести этот пункт к фактору устойчивости.
4. Функциональные возможности языков.
Если подитожить мысль -
php + mysql удобен для малых и средних проектов,
расширять проект на php достаточно трудоемко.
если же рост кода в проекте очевиден - желательно разрабатывать проект например на .NET, MS SQL.
06/11/2007
Цитата:
Сам пользуюсь самописной системой и могу сказать следующее- при росте номенклатуры- сейчас 2500 товаров - впервую очередь встают проблемы отнюдь не технических "тормозов", а юзабилити- сложно модерировать базу, выползают некоторые огрехи в юзабилити административного интерфейса
Сам пользуюсь самописной системой и могу сказать следующее- при росте номенклатуры- сейчас 2500 товаров - впервую очередь встают проблемы отнюдь не технических "тормозов", а юзабилити- сложно модерировать базу, выползают некоторые огрехи в юзабилити административного интерфейса
Если система устраивает, то может быть имеет смысл поковыряться в админке? Сделать ее поудобнее. Но тут могут быть камни, все зависит как (в каком виде) данные, например, о заказах хранятся в БД. Так как один раз видел что все данные просто в двух ячейках. В первой номер заказа, второй - весь html счет который высылался покупателю. И чтобы оттуда выдернуть что-нить, например, для статистики, надо было распарсивать эту вторую ячейку.
Цитата:
php + mysql удобен для малых и средних проектов
php + mysql удобен для малых и средних проектов
Что считать за малый или средний проект?
Цитата:
расширять проект на php достаточно трудоемко
расширять проект на php достаточно трудоемко
Опять же - что считать за расширяемость.
Также все зависит от того какой движок. Как все организовано. Где-то делается за пять минут, где-то недели две надо ковыряться.
Цитата:
если же рост кода в проекте очевиден
если же рост кода в проекте очевиден
Обычно если проект сразу создавался будучи продуманым, он не так часто правится и дополняется.
19/11/2007
stanislas:
Вставлю свои три копейки..
Многократно слышал мнения, что при базе номенклатуры более чем 10тыс становится невозможным работать с единой бд с интернет-доступом для администрирования товаров. В частности, была произнесена фраза "посмотрите на озон- их проблемы с базой исчезли только после того как они перешли на двухбазную работу"..
Имеется в виду наличие "основной" базы и базы "онлайн" которая обновляется из "основной".
Сам я с таким высказыванием согласен.
Хотелось бы услышать комментарии сведующих товарищей здесь.
Вставлю свои три копейки..
Многократно слышал мнения, что при базе номенклатуры более чем 10тыс становится невозможным работать с единой бд с интернет-доступом для администрирования товаров. В частности, была произнесена фраза "посмотрите на озон- их проблемы с базой исчезли только после того как они перешли на двухбазную работу"..
Имеется в виду наличие "основной" базы и базы "онлайн" которая обновляется из "основной".
Сам я с таким высказыванием согласен.
Хотелось бы услышать комментарии сведующих товарищей здесь.
Аналогичное же архитектурное решение в Melbis Shop - двухбазная система.
Цитата:
Сам пользуюсь самописной системой и могу сказать следующее- при росте номенклатуры- сейчас 2500 товаров - впервую очередь встают проблемы отнюдь не технических "тормозов", а юзабилити- сложно модерировать базу, выползают некоторые огрехи в юзабилити административного интерфейса, которые были абсолютно неважными при малом количестве товара.
Сам пользуюсь самописной системой и могу сказать следующее- при росте номенклатуры- сейчас 2500 товаров - впервую очередь встают проблемы отнюдь не технических "тормозов", а юзабилити- сложно модерировать базу, выползают некоторые огрехи в юзабилити административного интерфейса, которые были абсолютно неважными при малом количестве товара.
Попробуйте скачать Melbis посмотреть админку на юзабилити. Смотреть полнофункциональную версию можно абсолютно бесплатно. Управление большим ассортиментом товаров - это собственно та ключевая особенность которой мелбис отличается от других.
19/11/2007
Не забывайте о готовых офф-лайн системах ведения каталога товаров ИМ, которые можно подвязать практически к любой CMS, главное чтобы был хоть какой-то механизм импорта данных. Такаие решения уже есть и для 1С. Подобный вопрос обсуждался например вот сдесь:
http://www.oborot.ru/forum2/viewtopic.php?t=10477
http://www.oborot.ru/forum2/viewtopic.php?t=10477
Ответить
Читайте также
18/05/2017