| |||||||||
| |||||||||
Есть идея создать единую базу товаров. Должна выглядеть как каталог товаров с классификациями по категориям и многопользовательским интерфейсом. Уникальным полем товара будет штрих-код. В идеале эту базу должны заполнять производители и обновлять ее по мере надобности. Будет очень удобно наполнять магазин и работать с каким угодно количеством поставщиков одного и того же товара. Для этого они в свою учетку должны добавить ключ соответствия номенклатуры в моей базе и в своей учетке и выгружать данные в виде: уникальный ключ|цена|остаток. Ну еще много где можно использовать. Цель - приведение к единому виду номенклатуры производителя, дистрибьютора, магазина (интернет-магазина в том числе) и т.д. и получения своевременной информации об изменениях путем обновления справочника товаров поставщиками или иными заинтересованными лицами.
Предлагаю обсудить идею в двух ракурсах:
- как сама идея
- каким образом, с помощью каких технологий удобней, проще, дешевле это можно реализовать
Предлагаю обсудить идею в двух ракурсах:
- как сама идея
- каким образом, с помощью каких технологий удобней, проще, дешевле это можно реализовать
Над этим велосипедом бьются умы во всех отраслях.
пока самые вменяемые результаты - у яндекс-маркета и mixmarket
в первом случае - жесткая модеация, использование таксонометрие
во втором случае всем пох.
проблема заключается, в том, что
1. поставщики любят свои штрихи наносить
2.не любят светить реальные артикулы (из китая к примеру)
3.не любят отдавать свои остатки и цены.
4.не пользуются таксонометрией при заведении товара
5. дают своим товарам артикула 1С, или внутрянки
и т.д. и т.п.
начать предлагаю с ограниченной таксономию, взять за основу можно гуглю таксономию или Яндекс (для рос условий) но на яндекс не нашел таксономию товаров (скрывают?)
с учетом того, что РФ рано или поздно станет частью глобального рынка через 10-20 лет, смерти ПУ, в рез. революции, путча и т.п., предлагаю исп. мировой опыт и использовать гугль таксономию.
www.google.com
только на русский перевести.
после чего можно вставлять товары в соотв. раздел.
пока самые вменяемые результаты - у яндекс-маркета и mixmarket
в первом случае - жесткая модеация, использование таксонометрие
во втором случае всем пох.
проблема заключается, в том, что
1. поставщики любят свои штрихи наносить
2.не любят светить реальные артикулы (из китая к примеру)
3.не любят отдавать свои остатки и цены.
4.не пользуются таксонометрией при заведении товара
5. дают своим товарам артикула 1С, или внутрянки
и т.д. и т.п.
начать предлагаю с ограниченной таксономию, взять за основу можно гуглю таксономию или Яндекс (для рос условий) но на яндекс не нашел таксономию товаров (скрывают?)
с учетом того, что РФ рано или поздно станет частью глобального рынка через 10-20 лет, смерти ПУ, в рез. революции, путча и т.п., предлагаю исп. мировой опыт и использовать гугль таксономию.
www.google.com
только на русский перевести.
после чего можно вставлять товары в соотв. раздел.
насчет базы поставщиков тут уже на форуме есть такой чел. Sudar
его компания это делает в своей области.
можно его попытать.
его компания это делает в своей области.
можно его попытать.
технологии тут такие:
фронтенд
1 сервер для работы сайта , поиска и т.п. для клиентов работа с сервером БД по JSON
бекэнд:
2 сервер - поставщики и работа со своими личными кабинетами
3 сервер - БД - к нему обращение идет по JSON
также желат:
4 сервер - для постоянной индексации БД по разным критериям, а также хранение бекапов.
это только кажется что на вирт. хосте + MySQL можно сделать все в одном. на деле все вываливается в скорость обработки. сделать то можно, но при кол-ве товаров более 100000 - все умрет.
требуется создание архитектуры.
можно конечно решить вопрос в лоб - Amazonaws облако, но цена будет нечеловеческая. хотя просчитывать надо.
фронтенд
1 сервер для работы сайта , поиска и т.п. для клиентов работа с сервером БД по JSON
бекэнд:
2 сервер - поставщики и работа со своими личными кабинетами
3 сервер - БД - к нему обращение идет по JSON
также желат:
4 сервер - для постоянной индексации БД по разным критериям, а также хранение бекапов.
это только кажется что на вирт. хосте + MySQL можно сделать все в одном. на деле все вываливается в скорость обработки. сделать то можно, но при кол-ве товаров более 100000 - все умрет.
требуется создание архитектуры.
можно конечно решить вопрос в лоб - Amazonaws облако, но цена будет нечеловеческая. хотя просчитывать надо.
как идея - создать что то типа OPEN TAXONOMY
и постоянно отслеживать новые товарные группы и добавлять
возможно потом кто-то из крупняков купит (тот же гугль)
с этим беда полная, стандартов нет.
Яндекс в одиночку пытается справиться, но все хранит в секрете.
и постоянно отслеживать новые товарные группы и добавлять
возможно потом кто-то из крупняков купит (тот же гугль)
с этим беда полная, стандартов нет.
Яндекс в одиночку пытается справиться, но все хранит в секрете.
у яндекса тоже есть свои категории на маркете, посмотрел классификацию гугла, она поинтереснее будет
admin: технологии тут такие:
фронтенд
1 сервер для работы сайта , поиска и т.п. для клиентов работа с сервером БД по JSON
бекэнд:
2 сервер - поставщики и работа со своими личными кабинетами
3 сервер - БД - к нему обращение идет по JSON
также желат:
4 сервер - для постоянной индексации БД по разным критериям, а также хранение бекапов.
это только кажется что на вирт. хосте + MySQL можно сделать все в одном. на деле все вываливается в скорость обработки. сделать то можно, но при кол-ве товаров более 100000 - все умрет.
требуется создание архитектуры.
можно конечно решить вопрос в лоб - Amazonaws облако, но цена будет нечеловеческая. хотя просчитывать надо.
фронтенд
1 сервер для работы сайта , поиска и т.п. для клиентов работа с сервером БД по JSON
бекэнд:
2 сервер - поставщики и работа со своими личными кабинетами
3 сервер - БД - к нему обращение идет по JSON
также желат:
4 сервер - для постоянной индексации БД по разным критериям, а также хранение бекапов.
это только кажется что на вирт. хосте + MySQL можно сделать все в одном. на деле все вываливается в скорость обработки. сделать то можно, но при кол-ве товаров более 100000 - все умрет.
требуется создание архитектуры.
можно конечно решить вопрос в лоб - Amazonaws облако, но цена будет нечеловеческая. хотя просчитывать надо.
если для своих локальных целей, то 100 000 товаров мне хватит надолго, если глобально и на будущее, то, конечно, отдельные сервера будут предпочтительнее
у Амазона есть и какой то бесплатный тариф для начала: правда не знаю на какие проекты он рассчитан
Таксономия это самая малая проблема, категории и товары должны быть в базе на сервере с уникальным индексом, у клиента они могут как угодно забиты и как угодно раскиданы по категориям, главное, чтобы уникальный код у них в базе соответствовал коду базы товара на сервере.Тогда поставщику можно выгрузку из учетки делать в CSV, YML, XML или ином формате, и выкладывать на ФТП, а оттуда скрипт забирал бы файлик и обновлял данные по цене и остаткам на сайте.
что-то подобное уже есть в EWC
теоретически можно сделать и на евц.
если в разделе тыщ 20 не более, а разделов не более 1000 - то потянет и вирт хост.
1 млн. товаров я проверял. индексирует минут 10.
но все равно лучше конечно отдельный сервак под БД
теоретически можно сделать и на евц.
если в разделе тыщ 20 не более, а разделов не более 1000 - то потянет и вирт хост.
1 млн. товаров я проверял. индексирует минут 10.
но все равно лучше конечно отдельный сервак под БД
к примеру последний модуль остатки из CSV
в нем есть и поле для синхронизации
теоретически вместе с остатками можно жрать и цену и ажаксом ее вставлять, чтобы базу не индексировать.
можно и впрямую обновлять БД, но затратная операция. не люблю БД зря трогать.
в нем есть и поле для синхронизации
теоретически вместе с остатками можно жрать и цену и ажаксом ее вставлять, чтобы базу не индексировать.
можно и впрямую обновлять БД, но затратная операция. не люблю БД зря трогать.
EWC хороша для небольших проектов, не нагруженных, так как вы понимаете, что и фронтенд и бекэнд находятся на 1 машине. и еще есть проблема с количеством файлов в папке (бывают ограничения), скорость HDD (SSD решает), количеством памяти оперативной.
Если делать на EWC - то требуется кластеризировать БД разнеся компоненты на несколько монтируемых драйвов, а лучше физ машин.
Я не ставил в облаке EWC, но думаю там будет все летать, из-за снятия ограничений файлового доступа. автокеширования и кластеризации на уровне железа.
Но нельзя не упомянуть, что при всей тормознутости MySQL на вас фактически работает 2 машины - на которой работет БД и где работает фронтенд.
Правда хорошо, если машина с БД не занята параллельными процессами соседей
Базу MySQL можно тоже в облако кинуть и тогда разница между файлами и релятивистской БД будет минимальной (ну окромя массивности самих SQL запросов) учтите также что MySQL - это ведь тоже хранение в файлах, просто фреймворк-надстройка позволяет обращаться к БД по иному чем прямой доступ.
Плюс MySQL несомненный, это что можно начинающему пользователю скрещивать носорога со слоном особо не задумываясь.
Но серьезный проект не предусматривает "не задумывавшись"?
ну и дыры MySQL - нельзя забывать. не проверил переменную. Хакер нашел это, воспользовался. база тютю. хорошо если бекап будет.
Если делать на EWC - то требуется кластеризировать БД разнеся компоненты на несколько монтируемых драйвов, а лучше физ машин.
Я не ставил в облаке EWC, но думаю там будет все летать, из-за снятия ограничений файлового доступа. автокеширования и кластеризации на уровне железа.
Но нельзя не упомянуть, что при всей тормознутости MySQL на вас фактически работает 2 машины - на которой работет БД и где работает фронтенд.
Правда хорошо, если машина с БД не занята параллельными процессами соседей
Базу MySQL можно тоже в облако кинуть и тогда разница между файлами и релятивистской БД будет минимальной (ну окромя массивности самих SQL запросов) учтите также что MySQL - это ведь тоже хранение в файлах, просто фреймворк-надстройка позволяет обращаться к БД по иному чем прямой доступ.
Плюс MySQL несомненный, это что можно начинающему пользователю скрещивать носорога со слоном особо не задумываясь.
Но серьезный проект не предусматривает "не задумывавшись"?
ну и дыры MySQL - нельзя забывать. не проверил переменную. Хакер нашел это, воспользовался. база тютю. хорошо если бекап будет.
Я это к чему?
MySQL не может быть основой серьезной БД! Разве что с плюшками в виде индекс таблиц, грамотной разводки баз и т.п.
Серьезно это вот что:
Фронтенд <- JSON <-Api Доступа к БД <- кеш <- БД индексированная <-БД реальная <-бекапы <-индексаторы
MySQL не может быть основой серьезной БД! Разве что с плюшками в виде индекс таблиц, грамотной разводки баз и т.п.
Серьезно это вот что:
Фронтенд <- JSON <-Api Доступа к БД <- кеш <- БД индексированная <-БД реальная <-бекапы <-индексаторы
и еще хорошо бы чтобы фронтенд мог по JSON общаться с запасными серваками.
По идее вся суть в базе данных. Спроектировать и заполнять, редактировать с помощью файлов от производителей и поставщиков принимаю от них файлы в формате CSV, YML или подобных. А потом в интернет-магазине привязать поля в базе данных к карточке товара. Как то так мне видится.
Какую базу данных выбрать, вот в чем вопрос...MySQL, конечно, напрашивается само собой, для начала по нагрузке будет проходить и с PHP отлично дружит...проблемы могут начаться потом, если наладится процесс и начнется масштаб...а если не начнется, то и убытки небольшие)
Пошел изучать MySQL
P.S. Вебинтерфейс для визуального добавления/редактирования базы я примерно представляю как реализуется...а как через файлы база обновляется, где рыть инфу?
Какую базу данных выбрать, вот в чем вопрос...MySQL, конечно, напрашивается само собой, для начала по нагрузке будет проходить и с PHP отлично дружит...проблемы могут начаться потом, если наладится процесс и начнется масштаб...а если не начнется, то и убытки небольшие
Пошел изучать MySQL
P.S. Вебинтерфейс для визуального добавления/редактирования базы я примерно представляю как реализуется...а как через файлы база обновляется, где рыть инфу?
Пока писал сообщение, Павел на часть вопросов ответил и одновременно еще больше запутал)) Я не хочу команду разработчиков из 20 человек нанимать)) А Вы такие страшные связки пишете, что мозг боится С чего начать то?)
базу обновлять методом парсинга CSV и XML файлов
в случае XML операция затратней в разы и требует как минимум доп модулей типа simple_xml
потоком лучше всего CSV парсить
в качестве примера можно глянуть как работает парсер склада EWC admin/index_stock.php
настройки он берет из templates/1/rus/custom_stock.inc
в случае XML операция затратней в разы и требует как минимум доп модулей типа simple_xml
потоком лучше всего CSV парсить
в качестве примера можно глянуть как работает парсер склада EWC admin/index_stock.php
настройки он берет из templates/1/rus/custom_stock.inc
начать со структуры базы.
запросы к базе рекомендую через только через фреймворки!
что то из этого:
angular.js
node.js
yii фреймворк
запросы к базе рекомендую через только через фреймворки!
что то из этого:
angular.js
node.js
yii фреймворк
admin: начать со структуры базы.
запросы к базе рекомендую через только через фреймворки!
что то из этого:
angular.js
node.js
yii фреймворк
запросы к базе рекомендую через только через фреймворки!
что то из этого:
angular.js
node.js
yii фреймворк
фреймворки не потяну, не то знание PHP...Dreamweaver подойдет?