Какими способами осуществляется выгрузка и поддержка большой (от 5000 позиций) БД в интернет-магазине?
Вопрос достаточно общий, хочется для начала понять какие существуют подходы с их плюсами и минусами.
Дано:
Есть прайсы нескольких поставщиков, в каждом по несколько тысяч позиций.
Есть CMS магазина, например opencart (полагаю особой разницы в конкретной платформе нет, если БД в нем на MySQL).
Задача: загрузить в БД товары, включая категории, цены, характеристики и т.п.
Плюс дальнейшая поддержка в актуальном состоянии.
Для себя я нашел решение - одна из программ для обработки номенклатуры товаров (с функционалом импорта из прайс-листов, заливки непосредственно в БД магазина, привязки категорий и т.п., в общем целый "комбайн"). Название писать не буду, дабы не было рекламой. Темболее что прогой я относительно доволен.
Она удобна тем, что большинство функций работает "из коробки" - не нужно писать отдельные программы. Но с другой стороны я сильно привязан к этой программе и у неё бывают некоторые глюки.
Аналоги я бегло искал - но не нашел.
Какие варианты наполнения и поддержки БД товаров в магазинах бывают? Какие подходы практикуются, как это делается в интернет-магазинах с базой товаров в 5-10-30-50 тысяч товаров?
***Речь не о простой заливке в базу, а о создании полноценной базы. С категориями, с различными характеристиками товара (цвет, вес, форма, материал и т.п.). Обычная загрузка из exel проблему создания полноценной БД не решает. Кроме того, что если у поставщика изменится сразу сотни-тысячи позиций в прайсе - в ручную менять не вариант.***
P.S. поменял заголовок с "загрузки" на "выгрузку", то возникала путаница.
50к - не так уж и много записей. Я бы сказал мало. У меня устройства кидают свои GPS координаты, там только с устройства по 10-50к точек В ДЕНЬ. База 200-1000Gb.
Собственно как загонять позиции в базу - вариантов вагон.
Можно тем же Excel - если верно помню, он это напрямую конектить умеет, но если нет, то можно сохранить в CSV и подсунуть в базу через PHPMyAdmin.
MS Access точно умеет соединятся с базами через ODBC. Т.е. можно сделать достаточно лояльный к пользователю Front-End.
Тут скорее вопрос предпочтений. Можно ведь и через нотпад забить SQL-файл.
Также есть Navicat, ToadSQL, MySQL-овский GUI.
Вопрос не в самой заливке, многие CMS из коробки (или с помощью модулей) могут импортировать exel файлы, некоторые даже с категориями.
Но проблему создания хар-к товара это не решает, если в прайсе поставщика они не прописаны в отдельных колонках (как обычно и бывает).
Плюс это не решает вопрос поддержки последующей. Изменения цен, наличия, добавление новых характеристик. Или группировка товаров по типу "с этим часто покупают это" и т.п.
MS Acces не пользовался никогда, интересно. Почитаю на эту тему.
Сделать Front-End - т.е. написать свой?
@Mist8 Access позволяет делать формы для заполнения, а также импортировать/экспортировать из формато MS (ну и не только).
На самом деле не очень ясна проблема. Вам для автоматического заполнения нужен некий стандартизованный источник данных. Вариантов исполнения много - начиная от Excel-файла и заканчивая MSSQL базой или экспортом из 1С. Договоритесь с поставщиком и стандартизации прайса - пусть дает его в определенной форме. Наверняка они его тоже из чего-то генерируют (если у них столько позиций). Если поставщиков много, то один фиг это будут костыли. Как вариант - импорт из 1С, т.к. как правило у всех в нем что-то да ведется.
Если все от поставщиков то просто скприт импорта + синхронизация
ничего удивительного вроде нет
так работает чуть ли не каждый второй магазин в интренете
Скрипт, который парсит прайс лист и переносит/синхронизирует с базой данных магазина? Про этот вариант я знаю. Но у него есть минус - под каждое изменение придется переписывать скрипт. Мне интересно, какие есть готовые решения, не требующие написание скрипта для каждной новой базы целиком.
При этом понятно, что какие-то скрипты (те что будут парсить непосредственно прайс-лист) написать придется.
про прогу - понятно (7 букв в названии))
ну там можно и плагины писать в ней свои...
а так - обычное кэширование предыдущих запросов парсинга XML/YML/sitemap структуры файла или каждой из страниц и последующее сравнение для обнаружения новых позиций для их дальнейшей заливки с периодичностью 4-6 часов (в среднем).
@xmoonlight Это парсер - им я тоже пользовался. Как парсер - хорошее решение. Но мой вопрос о другом совсем. О заливке БД на сайт интернет-магазина. Datacol заточен именно под парсинг, вопрос организации в категории, создания взаимосвязей в БД он не решает же.
@Mist8
1. Пишется wrapper (прокладка/коннектор) из формата поступающего прайса в формат вашей БД.
2. Настраивается кэширование по дате/размеру входящих данных: не изменился - пропускаем загрузку.
В принципе - все...
Средний
Простой
