Почему не надо редактировать данные БД через xlsx документ?

Question

[kosiv92]

Доброго времени суток. Работаю в отделе ИТ. От другого отдела моей организации поступил запрос на разработку простого веб-сервиса с возможностью CRUD-операций определенного типа документов и хранения данных в БД. Есть условие, на котором очень настаивает заказчик (по видимому в силу привычки работать с Word, Excel) - возможность не только экспортировать данных в табличный документ (xlsx), но и возможность затем загружать откорректированные в этом отчете данные обратно в программу. Т.е. существующие данные должны редактироваться, а новые добавляться в БД. Подскажите как с технической точки зрения можно обосновать, что лучше все же оставить возможность редактирования данных только через веб-интерфейс?

Answer 1

[Valentin Barbolin]

но и возможность затем загружать откорректированные в этом отчете данные обратно в программу.

Вообще, нормальная практика, но адекватные програмеры xlsx для импорта стараются не использовать. Лучше использоват CSV, его так же можно открыть через редактор Excel.

Comments

[kosiv92]

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

[Rsa97]

kosiv92, Тут поможет только естественный ключ. Ежели такового нет, то рано или поздно консистентность данных будет нарушена.

[Valentin Barbolin]

kosiv92, Ты ведь планировал написать интерфейс для импорта? Соответственно ты можешь выполнить простые проверки, соответственно добавить обязательную проверку, что бы в CSV была колонка которая являет PRIMARY key в базе.

[Valentin Barbolin]

kosiv92, Скорее всего сценарий работы предпологает не только редактирование базы по средствам экспорта и последующего импорта, но так же и добавление новых записей. В таком случае вполне логично, что Privary key может и не быть в CSV, если нет key в CSV то в базу будут добавлены новые строки.

Answer 2

[chemdev]

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

Answer 3

[Владимир Коротенко]

И что вас смущает?

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

Не находите первичного ключа просто говорите что пользователь дурак.

Answer 4

[d-stream]

Типичнейший кейс: редактирование базовых цен, групп и т.п. прайса.
Притом инструмент работающего с таковым должен уметь работать не только с excel, но и с другими форматами. И обладать достаточной гибкостью. Причина проста: средний сервис/магазин зч оперирует миллионами номенклатурных единиц (кодами з/ч), оные коды и политика ценообразования зависят от поставщика - т.е. один шлёт в excel код детали - цена - категория скидки - мин партия - срок, другой выгружает остаток склада в виде код-наименование-кол-во-цена, третий валит tab delimited прайс в у.е. и так далее.
Ручками такое никто набивать-перебивать-сверять не будет. А поставщик, особенно эксклюзивный - пошлёт искать на рынке другого поставщика)
Ну и да... зачастую ещё одни и те же запчасти могут иметь несколько разное кодирование под разные рынки-регионы)

В итоге сидит чел, тащит из зоопарка присылаемого в excel (например через мастер импорта) данные, сводит их к более-менее единообразному тасуя колонки, пересчитывая ндс и валюты. И потом хотел бы не выверять csv глазами на предмет затесавшегося "Болт М5; резьба1,5 мм" на котором импорт csv упадёт хоть с comma delimiter, хоть с semicilon ))))))))