К сути:
Есть поставщики, есть рестораны, есть KFC,
BugBiffin и прочее в этом роде. Мне нужно всех объединить на одном ресурсе, чтобы человек мог зайдя на сайт например заказать курицу в KFC, а салаты и прочее у Ашота, неважно.
Мне нужно разработать архитектуру![именно архитектуру, так как сайт я собрать могу].
Вопросов нет по темам подключения API оплаты, корзины, и прочей работоспособности ресурса.
У меня проблема с базой данных.
Есть колл-центры и чаты, у каждой конторы свой! Есть номера и данные клиентов [заказов], есть номера телефонов клиентов, ордера на будущее [ типа я сейчас бургер не хочу, но он мне понадобится тогда то там то, буду пролетать мимо заберу ], ордера текущие, а также ячейки с датой и временем, суммой покупки [кстати я считаю что последнее не обязательно совмещать, и разместить отдельно, чтобы избежать котовасии но не делать их совсем нельзя так как это всё учитывается при расчете моего процента] - поясню, они хотят сделать так, не оговаривать фиксу, а платить лишь по факту проданной продукции через ресурс чтобы к тому же было видно его полезность, оплачивается к примеру так - бургер допустим 100 рублей, из его стоимости мне будет уходить ну 5% к примеру, так вот, тогда получается каждый проданный товар надо учитывать и где то хранить а потом и считать. С математикой я справлюсь. Я кончено могу предложить им другие условия расчета, но дело в том что мне в принципе самому интересно как это всё лучше сделать.
Разумеется я не спрашиваю решения, но может я вообще неправильно мыслю? У меня не так много опыта в сборке подобных...решений.
Спасибо за ваше время.
Лентюй, я думаю можно сделать так, у каждого из них есть свой ресурс, именной если можно так сказать, цены можно тянуть оттуда. Но меня волнует не это, а то откуда я буду брать инфу о кол-ве уже реализованного товара, его наименовании и прочего.
Это же святая святых получается, а что ещё предложить.
Главная ошибка - у вас нет проблем с базой данных, а вообще проблема с позиционированием продукта и отсутствием архитектуры. Подстраиваться под всех невозможно и следует сделать сервис, который задает правила игры и с которым нужно будет интегрироваться. Для старта - найти несколько потенциальных партнеров, сделать proof of concept, mvp и попробовать запуститься.
Иван Шумов, дело в том что подобный ресурс будет в итоге расти горизонтально, и я попросту не могу написать на доске нормальный график с его последующим ростом потому что не знаю [ или не до конца понимаю ] как он должен строиться изначально.
Dare95, еще раз - это все следствия. Проблема в отсутствии понимании позиционирования сервиса, принципов взаимодействия с партнерами и вообще общей логики. Нет видения проекта с 10000ft. База данных вообще будет одним из последних вопросов в этой истории
Dare95, какой график, какой рост? Сделай хоть что-нибудь, что можно показывать потенциальным партнёрам. Или сразу стартап, посевы, раунды, большой burn rate, офис в Долине?
Обычно для таких проектов сначала делается пилот (на коленке собирают сайт с минимальным функционалам и отрабатывают кейсы). Потом с этим пилотом носятся по клиентам и собирают требования рынка. А вот уже потом, когда все цифры и кейсы определены, можно уже приступать к Архитектуре и пилить продакшен.
Но меня волнует не это, а то откуда я буду брать инфу о кол-ве уже реализованного товара, его наименовании и прочего.
Не беритесь за то что не понимаете и в чем не разбираетесь, у вас сейчас каша а дальше будет еще хуже. Вы хотите изобрести али экспресс в сфере общественного питания, очередной плохо продуманный агрегатор который не взлетит.
Вот мой ответ.
Не создавай фейсбук Марк, у тебя не опыта ни денег, а для общения есть электронная почта и смски, очередная хрень которая не взлетит!
Надо пробовать, прежде всего, знания придут. Задавай вопросы, читай, учи, но никогда не говорите "не делай не взлетит". Лучше попытаться и облажаться но получить хотя бы опыт, чем вообще ничего не делать.
Да и к тому же, это только в свободное от работы время.
Dare95, Фейсбук был чем то новым чего раньше не было, а ты "изобретаешь" очередной агрегатор которых уже сотни, с очень сомнительно полезностью но с кучей потенциальных проблем. Пойми - участникам рынка НЕ интересно драться за заказы на очередной площадке-аукционе, надуманная полезность не вывезет. Ты пытаешься решить проблему которой нет.
Потренируйтесь на CPA системах, где из фидов сливают товары из нескольких магазинов и делая глубокий анализ выстраивают верную архитектуру.
Если каталогизировать товары вы сможете, то самая интересная задача на мой взгляд: когда приходит заказ например из 3х вещей и каждая от разного поставщика: придется поиграться со сроками доставки каждого из них к вам, сборка и отправка клиенту и мониторить статусы всех доставка к вам и от вас.
А интересный гемор будет крыться там: где из 3х вещей - одна не понравиться и будет отказ всего заказа )) как с этим быть решать вам.
Решение есть, по поводу доставки придется один раз наладить процесс вручную, пройти все этапы и используя готовый шаблон всё это автоматизировать, конечно легче сказать чем сделать, у меня пока нет опыта автоматизации именно таких размеров, 3 заказа это ведь утрированно, что если поставщиков услуг будет 10, по 30 заказов за 4-5 часов с каждого. Это в любом случае автоматизация а не целый штат сотрудников, но с этим придется ползти на аутсорс, я думаю, самому это дело делать можно мягко говоря...длительно.
Средний
