jess23Я бы хотел посадить менеджера которому показать как наполнять ИМ показать что нажимать и все, ограничить по максимуму лишних действий.Брррр... Опасная затея. ИМХО конечно.

jess23, а почему нельзя делать правки более-менее стандартным образом - через админку магазина?

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

Думаю, не секрет, что обычно в магазине используется несколько таблиц. Добавление товара - по сути добавление записей в одну или несколько таблиц. Притом, записи одних таблиц почти всегда ссылаются на записи других. Скрипты админки (если только админка не совсем кривая) уже заточены для обеспечения целостности данных. Через админку как заполняем... Где-то из списка выбираем значения, где-то галочку кликаем, где-то текст пишем или копипастим. А, ещё файлики с картинками приложить надо. Заполнил форму, жмакнул кнопку - данные ушли на сервер. Там данные проверились и, если нет ошибок, распихались по таблицам. Плюс, возможно, данные будут каким-то образом обработаны. Например, заменены некоторые символы или нормализованы значения каких-то полей. Если обнаружилась какая-то ошибка - то админка отобразит какое-то более-менее внятное сообщение об ошибке, и, может быть, даже укажет поле формы, которое содержит заведомо ошибочные данные. Это, в общем то, классический способ.

Теперь игнорируем админку и попробуем добавлять записи в базу с использованием стороннего ПО. Первым делом придётся сделать некоторое сопоставление полей БД и данных - что куда распихивать, что на что должно ссылаться. Схему данных нарисовать не проблема обычно. Будет ли эта схема понятной "не-программисту"? Сразу точно не поймёт. Придётся объяснять. И про "какие-то айди" тоже придётся. А если, банально, рука дрогнула и вместо айди категории 78 в базу попала несуществующая на данный момент 87 категория? Не во всяком магазине используются внешние ключи в таблицах, ошибку не увидим сразу. Данные то вполне корректны. Просто товар "пропадёт" в магазине - придётся искать его. А если сообщение об ошибке будет - то оно, скорее всего, будет каким-то не вполне понятным текстом на английском. Даже с хорошим знанием английского языка, это сообщение, скорее всего, будет понятно программисту, но не менеджеру.

С картинками - вообще отдельная тема. Нередко админка переименовывает файлы на свой хитрый лад и распихивает их по каким-то папкам, попутно нарезая всякого размера превьюшек. Этот функционал явно не свойственный ПО для работы с СУБД. Опять, значит, ручками.

Вот всё это надо менеджеру, как считаете?

Даже если и замотивировать его хорошенько, ошибок вряд ли удастся избежать. Особенно, на первых порах. Да и производительность труда из-за перепроверок вряд ли будет высокой.

jess23,

И всё же, чем не устраивают штатные средства управления магазином?
Возможно, в админке есть какие-то штатные средства импорта из CSV или XML. Смотрели?

jess23Но все стало упираться в максимальное время выполнение скрипта (шаред хостинг, товара достаточно много) есть вариант все выгружать партиями в формате csv но это чертовски неудобно (например изменять наличие и так дальше...) было принято решение найти по возможности альтернативный вариантМысли вот какие.

Возможно, есть смысл переработать систему импорта/экспорта так, чтобы время выполнения скрипта не имело значения. Довольно часто скрипт, запущенный из консоли или из крона может работать в разы дольше, чем тот же скрипт при обращении из браузера. Это первая мысль.

Вторая. Тот же скрипт можно модифицировать для обработки большого файла по частям так, чтобы обработка каждой части укладывалась в отведённое время.

Третья. В ряде случаев можно и сократить количество данных в файле. Например, для изменения наличия/количества товара в магазине в принципе достаточно отправлять всего два поля - айди товара и его количество. Ну тут исключительно в целях человекопонятности следует добавить артикул и/или наименование товара при экспорте остатков с сайта в CSV (ибо, по айди сложно понять, о каком товаре речь), а в импортируемом на сайт файле их исключить или игнорировать. Меньше данных - быстрее работает.

Четвёртая. Сделать свои узкоспециализированные странички в админке для выполнения наиболее проблемных задач. Например, для того же изменения наличия/количества вполне можно выводить сотню товаров на странице с единственным полем ввода на каждый товар. А изменения можно сохранять на сервер хоть даже асинхронным запросом, запускаемым по onchange поля ввода. Думаю, такой способ внесения правок для пользователя будет достаточно простой задачей, чтобы с ней смог справиться менеджер без специальной подготовки. Во всяком случае, не сложнее, чем поправить столбик цифирок в екселе.

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