Как правильно построить взаимодействие своей «внутренней» базы товаров с движком интернет-магазина?

Question

[Сергей Малинин]

Здравствуйте.
Подскажите, пожалуйста, как правильно построить взаимодействие своей "внутренней" базы, хранящей данные по товарам, с движком интернет-магазина, в котором эти товары продаются?
Начиналось (и сейчас продолжается) так: у владельца бизнеса есть гуглодока, в нескольких таблицах которой хранится весь каталог. Таблицы все устроены по-разному, единообразия нет.
Когда каталог обновляется, он экспортит эти таблицы в xlsx и присылает мне -> я выгружаю из движка интернет-магазина текущий каталог в csv -> загоняю в Excel, вручную правлю -> загружаю назад.
Это довольно больно, но, пока товарных позиций было немного, было терпимо. Теперь и каталог больше, и вторая площадка открывается. В самом движке, конечно, есть возможность настраивать карточки товаров, но делать это массово больше одного раза очень неудобно.
Думается, что должно быть так: товары хранятся не в таблицах, а в единой БД. Когда владелец бизнеса что-то там меняет, эти изменения автоматически распространяются в каталоги интернет-магазинов.
Как такое делают?
Спасибо!

Comments

[mayton2019]

Внутренние.. Внешние...

Храните все в одной базе.

[Одиночка Айс]

mayton2019, главное, донести до владельца бизнеса это теперь)

[Сергей Малинин]

Так вот я и хочу узнать, как всё должно быть по фэн-шую )

Answer 1

[quad69]

Думается, что должно быть так: товары хранятся не в таблицах, а в единой БД. Когда владелец бизнеса что-то там меняет, эти изменения автоматически распространяются в каталоги интернет-магазинов.
Как такое делают?

А в чём сложность? Ставите тот же Mysql, складываете в него товары, потом подключаетесь, берёте данные и выводите.

Comments

[Сергей Малинин]

Сложность в том, что задача новая, подобного раньше не делал. Можно чуть больше конкретики? MySQL ставлю на сервер. Подключаюсь по через терминал или с помощью GUI-клиента? Создаю базу, в ней таблицу. Массово загоняю товары, загружая подготовленный файл? Данные между моей базой и интернет-магазинами гоняют скрипты? Бекапят базу другие скрипты по расписанию?
Владелец бизнеса (или менеджер), конечно, не будет ходить в базу через терминал. Значит, им нужны какие-то удобные клиенты?

[Uno]

Сергей Малинин,

Бекапят базу другие скрипты по расписанию?

то ты не понимаешь как к мускулу подключиться и

подобного раньше не делал.

, то сразу за бекапы по крону заговорил.

Владелец бизнеса (или менеджер), конечно, не будет ходить в базу через терминал. Значит, им нужны какие-то удобные клиенты?

удобным клиентом в данном случае должна была быть админка с crud'oм.

Может стоит на фриланс пойти, если одно лишь слово mysql сходу 5 вопросов вызывает? Все равно даже если сам привыкнешь к пхпмуадмин, то насиловать глаза манагеру или овнеру чревато в итоге заменой нормальным спецом.

[quad69]

В идеале должно быть так: есть одна единственная база данных, в неё владелец/менеджер грузит новые товары, затем ваш интернет-магазин подключается к этой базе и берёт сразу актуальные данные.
Терминал им не нужен, должна быть отдельная вкладка в админке, или на крайний случай тот же phpMyAdmin или HeidiSQL.

Ещё бывает такой вариант: У вас и вашего владельца две разные базы данных (не гугл доки), когда владелец делает правки, его система отправляет уведомление в вашу, затем она запрашивает обновленный список товаров, грузит себе и готово.

[Сергей Малинин]

Uno, всё верно, конечно. Ну, у меня есть шанс прокачать скил, решая задачу, вот и стараюсь им воспользоваться. Самописную админку, конечно, не осилю. Но неужели у всех всегда самописная админка? Можно же, например, Libreoffice Base? Или плохо?

[quad69]

Сергей Малинин, ну... составлять те же таблицы в базе тоже нужно уметь, и иногда это ещё сложнее, чем просто слепить простую админку с 3 функциями.

Плюс самописной админки в том, что в случае чего её всегда можно подправить и доработать, а с готовыми решениями может возникнуть куча проблем.

[Uno]

Сергей Малинин,

Но неужели у всех всегда самописная админка? Можно же, например, Libreoffice Base?

если лб они освоят то и phpmyadmin. Не у всех и не всегда самописная админка, но просто сам себя представь через 3 года когда вы еще 8 интернет магазинов запустите. Когда задумаешься о правильной архитектуре тогда уже будет поздно и на плечах овнера будет сидеть 4 макаки на зп копающиеся в куче разношерстных как ты выразился xlsx. Норм?
Каков выход? приводить сейчас всю вашу информацию в единообразный вид, централизовать, наладить программный доступ. Хоть через парсинг xlsx это сделай, но если сейчас правильно не решите - захлебнетесь

[Сергей Малинин]

quad69, в смысле - нужно аккуратно продумать саму таблицу, чтобы были все нужные поля и у них были правильные типы?

[Сергей Малинин]

Uno, о том и речь.
Пока я понял, что должно быть так: на сервере MySQL, для удобной работы с ней у менеджера/оунера админка. Дальше. Как обновленные данные из этой базы попадают в базы интернет-магазинов?

[quad69]

Сергей Малинин, верно, но по мере роста магазина придётся вникать в более сложные темы (партиции, реплики, индексы и т.д). Я это к тому, что написать админку куда проще (даже на тех же костылях), и прослужить она может очень долго, а потом, в случае чего, выбросить и написать новую.

В остальном же, как написали выше - лучше заранее всё продумать хорошо, что бы в будущем избежать серьезных проблем.

[quad69]

Сергей Малинин,

Как обновленные данные из этой базы попадают в базы интернет-магазинов?

Я писал выше - либо сразу складывается всё в одну единую базу данных, либо это несколько баз данных и вы с помощью уведомлений получаете обновленный список товаров.

Answer 2

[mletov]

Проблема тут не столько программистская, сколько организационная.
И главный ключевой вопрос тут в том: на какие трудозатраты со своей стороны готов владелец бизнеса.

Когда каталог обновляется, он экспортит эти таблицы в xlsx и присылает мне -> я выгружаю из движка интернет-магазина текущий каталог в csv -> загоняю в Excel, вручную правлю -> загружаю назад.

Вот это, с точки зрения автоматизации, никуда не годится. И логично посадить девочку, которая будет через веб-интерфейс вбивать товары в базу прямо в админку магазина. А уже из одного магазина можно полностью или частично экспортировать товары в другой, особенно, если это Битрикс какой-нибудь, в котором уже есть готовый XML формат. Или часть экспортировать, часть забить руками через админку другого магазина. В общем, варианты и простор для творчества есть.

Но может владелец бизнеса эту эксельку еще где-то использует или просто принципиально не готов менять подходы со своей стороны, осваивать веб-интерфейс не захочет, "я всю жизнь через Excel делал, переучиваться не хочу".

Еще есть вариант, что эту Excel заказчик формирует из 1C, тогда логично разобраться с импортом из него прямо в базу магазинов.

В общем, я бы поговорил с заказчиком, обсудил варианты и выяснил возможности.

Comments

[Сергей Малинин]

Да, привычка вести базу в эксельке имеет место быть. Действительно, мне предстоит обосновать необходимость переезда с такого варианта...

Answer 3

[mayton2019]

Значит имеет место некий pipeline который работает в 3 фазы.

1) Скачивание из гугло-таблиц в файлы. Здесь я предполагаю что у нас есть full-structured данные xlsx
Тоесть таблицы и фиксированная шапка.

2) Конверсия xlsx-csv. Ну здесь как-бы все понятно. Это можно сделать локально уже без веба.

3) Загрузка (или merge) данных из CSV в реляционную базу данных.

Мне кажется что интересно обсуждать только пункт (3). Потому что первый и второй - это просто задачи скачивания и конверсии без изменений. Задача чисто техническая и любой "школьник-парсильщик" это делает.
Чисто утилитарная задача.

Обсуждать одновременно сразу 3 пункта - это безсмысленный флуд. Слишком много неизвестных. Поэтому лучше вот в таком вот виде когда контракт понятен.

Если в какой-то момент (например фазы 1-2) схема может быть изменена или сломана - то это надо тоже обсуждать как ветки алгоритма загрузки. Как грузить.

Что делать если новая колонка зашла?
Что делать если колонка изменила тип? Был int. Стал - string.
Что делать если колонка дропнулась? Удалять ли в БД.
Что делать если schema evolution нарушается. Был string, и пошел int. Это сужает возможности загрузки.

Вот эти все вопросы надо ответить до разработки.

UPD:

Comments

[Сергей Малинин]

Вот как раз разношерстные таблицы для разных категорий товаров стали камнем преткновения: разная структура столбцов и иногда разный формат одних и тех же данных делает очень неудобной приведение выгрузки в подходящую для загрузки форму. У владельца бизнеса там целый свой мир, не только каталог товаров.

[mayton2019]

Сергей Малинин, какую БД используете? MySQL? PG?

[Сергей Малинин]

MySQL

[mayton2019]

Сергей Малинин, я не специалист в MySQL. Но вот я смотрю что там есть поддержка JSON типа данных
https://dev.mysql.com/doc/refman/5.7/en/json.html . Это хорошо.
Можно сделать так. Ключевые поля определить как примитивы.
А все что осталось - положить в JSON документ.

Это даст возможность хотя-бы не падать от изменения схемы.