Комментарии 9
Доброго Вам здоровья. Берегите себя, ни один бизнес не стОит Жизни.
НЛО прилетело и опубликовало эту надпись здесь
Будь здоров! Все остальное — мелочи, приложится.
Спасибо за добрые слова!
Постараюсь в ближайшее время написать вторую часть.
Затрону тему неконтролируемого копирования страниц в некоторых CMSках (из-за этого столкнулся со сложностью продвижения) и тему повышения конверсии без должного юзабилити (для тех кто коробку все-таки не выкупил).
Постараюсь в ближайшее время написать вторую часть.
Затрону тему неконтролируемого копирования страниц в некоторых CMSках (из-за этого столкнулся со сложностью продвижения) и тему повышения конверсии без должного юзабилити (для тех кто коробку все-таки не выкупил).
Здоровья тебе! Молодец, что не сдаешься.
Сам столкнулся с проблемой «Один в поле не воин» и сейчас магазин на «заморозке». По итогу, оказался нужен курьер, с остальным справляюсь, но из-за основной работы не успеваю развозить заказы (хоть их и не много).
В качестве CMS использую nethouse.ru. Оказалось достаточно приятной платформой, хоть и не без недостатков. Оплату е-деньгами прикрутить в пару кликов можно.
Сам столкнулся с проблемой «Один в поле не воин» и сейчас магазин на «заморозке». По итогу, оказался нужен курьер, с остальным справляюсь, но из-за основной работы не успеваю развозить заказы (хоть их и не много).
В качестве CMS использую nethouse.ru. Оказалось достаточно приятной платформой, хоть и не без недостатков. Оплату е-деньгами прикрутить в пару кликов можно.
Доброго Вам здравия!
Дополню пункт про CMS.
Основная ошибка при проектировании интернет-магазинов — положиться полностью на CMS. Большая часть CMS попросту не рассчитана на высокие нагрузки. Что и говорить, если моя любимая MODx Evo валится ближе к 100 000 ресурсов. А когда речь идёт о серьёзных проектах счёт может пойти на миллионы. И, ради всего святого и не очень, заклинаю вас, коллеги, не используйте для серьёзных проектов игрушки навроде Joomla. Это даже не смешно.
Проектировать базу данных, если таковая должна присутствовать (и скорее всего будет присутствовать) нужно отдельно от CMS. Если это каталог, тогда он не должен реализовываться штатными средствами CMS, иначе у этого каталога будет очень низкий предел нагруженности, зависящий от конкретной CMS. Реализовывать вывод каталога тоже лучше всего отдельными сниппетами.
Очень важный момент: логику проекта хорошо бы спрятать в хранимые процедуры, если СУБД позволяет такие «финты ушами». Это резко повышает нагрузочную способность проекта в целом. И, к сожалению, современные разработчики из-за обилия фреймворков забывают об этом моменте и пишут потом кучи статей про то, как разогнать асфальтовый каток до сверхзвуковой скорости. PHP — это шаблонизатор прежде всего, а уже только потом язык программирования. Так что:
Кроме того саму базу следует разрабатывать в расчёте на дальнейшее расширение. Это ещё одна причина не полагаться полностью на CMS. Далеко не все CMS используют ресурсы и связанные таблицы. Например, в настоящий момент я сопровождаю один крупный проект, написанный процедурным hard-code. Так там БД — сущий адЪ. Для добавления новой характеристики товару нужно добавлять столбец в таблицу (которая к слову содержит уже более 40 столбцов). Помните: реляционная СУБД для того и создана, чтобы проектировать системы связанных таблиц.
Хороший пример, как может быть спроектирован ИМ на PHP и MySQL:
— Отдельная база данных по товарам и каталогам
— Логика каталога в СУБД на хранимых процедурах
— Структура каталога примитивно и вкратце:
— Фронтенд сайта — MODx Evo
— Бэкенд сайта — MODx Evo
— Интеграция каталога с 1С через отдельные скрипты экспорта/импорта
Сразу оговорюсь, что приведённый пример не претендует на объективность. Тем паче, что та же база товаров и каталогов обычно куда сложнее. Например, я обычно использую для связанных характеристик несколько таблиц — целочисленные значения, строковые значения, текстовые значения, а то и больше — по специфике типа. Да и сами таблицы товаров и каталогов куда больше полей будут содержать. 1С-ка не везде есть опять таки же.
Общий итог моего дополнения: прежде всего нужно вдумчиво проектировать основную часть проекта, дабы проект мог расти.
Дополню пункт про CMS.
Основная ошибка при проектировании интернет-магазинов — положиться полностью на CMS. Большая часть CMS попросту не рассчитана на высокие нагрузки. Что и говорить, если моя любимая MODx Evo валится ближе к 100 000 ресурсов. А когда речь идёт о серьёзных проектах счёт может пойти на миллионы. И, ради всего святого и не очень, заклинаю вас, коллеги, не используйте для серьёзных проектов игрушки навроде Joomla. Это даже не смешно.
Проектировать базу данных, если таковая должна присутствовать (и скорее всего будет присутствовать) нужно отдельно от CMS. Если это каталог, тогда он не должен реализовываться штатными средствами CMS, иначе у этого каталога будет очень низкий предел нагруженности, зависящий от конкретной CMS. Реализовывать вывод каталога тоже лучше всего отдельными сниппетами.
Очень важный момент: логику проекта хорошо бы спрятать в хранимые процедуры, если СУБД позволяет такие «финты ушами». Это резко повышает нагрузочную способность проекта в целом. И, к сожалению, современные разработчики из-за обилия фреймворков забывают об этом моменте и пишут потом кучи статей про то, как разогнать асфальтовый каток до сверхзвуковой скорости. PHP — это шаблонизатор прежде всего, а уже только потом язык программирования. Так что:
мухи — отдельно, котлеты — отдельно
Кроме того саму базу следует разрабатывать в расчёте на дальнейшее расширение. Это ещё одна причина не полагаться полностью на CMS. Далеко не все CMS используют ресурсы и связанные таблицы. Например, в настоящий момент я сопровождаю один крупный проект, написанный процедурным hard-code. Так там БД — сущий адЪ. Для добавления новой характеристики товару нужно добавлять столбец в таблицу (которая к слову содержит уже более 40 столбцов). Помните: реляционная СУБД для того и создана, чтобы проектировать системы связанных таблиц.
Хороший пример, как может быть спроектирован ИМ на PHP и MySQL:
— Отдельная база данных по товарам и каталогам
— Логика каталога в СУБД на хранимых процедурах
— Структура каталога примитивно и вкратце:
1. Товары (ID, наименование, алиас, артикул, цена)
2. Каталоги (ID, Parent_ID, название, алиас)
3. Характеристики товаров (ID, алиас, тип)
4. Значения характеристик (ID товара, ID характеристики, значение).
— Фронтенд сайта — MODx Evo
— Бэкенд сайта — MODx Evo
— Интеграция каталога с 1С через отдельные скрипты экспорта/импорта
Сразу оговорюсь, что приведённый пример не претендует на объективность. Тем паче, что та же база товаров и каталогов обычно куда сложнее. Например, я обычно использую для связанных характеристик несколько таблиц — целочисленные значения, строковые значения, текстовые значения, а то и больше — по специфике типа. Да и сами таблицы товаров и каталогов куда больше полей будут содержать. 1С-ка не везде есть опять таки же.
Общий итог моего дополнения: прежде всего нужно вдумчиво проектировать основную часть проекта, дабы проект мог расти.
Непростая история. Побольше Вам здоровья и хороших людей рядом!
Относительно создания магазина: есть изобретенные велосипеды bit.ly/1sbAcAQ
Возможно будет полезным.
Облачные решения, которые интегрируют фронт-офис(продажи), бек-офис (счета, склад, обслуживание и т.д.) и по деньгам и по времени интереснее будут.
Но если у Вас заточенный свой бизнес процесс — тогда да. Только своё собственное решение.
Относительно создания магазина: есть изобретенные велосипеды bit.ly/1sbAcAQ
Возможно будет полезным.
Облачные решения, которые интегрируют фронт-офис(продажи), бек-офис (счета, склад, обслуживание и т.д.) и по деньгам и по времени интереснее будут.
Но если у Вас заточенный свой бизнес процесс — тогда да. Только своё собственное решение.
Борнет — это сущий ад. У нас была коробочная версия и мы ее пилили после покупки несколько лет. Если коротко, продают технологии 10 летней давности. Табличная верстка, каша из php и html, 100500 файлов в корне, классы типа gr01 tr24. Чпу лучше бы его вообще не было, из 1к реальных страниц, яндекс проиндексировал 400к.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интернет-магазин. Как избежать элементарных ошибок в начале и облегчить этим жизнь в будущем