Как вы обычно импортируете данные из электронной таблицы в несколько столбцов базы данных?

Question

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

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

• Использование Excel для изменения данных, чтобы их было немного проще импортировать
• Импорт всей электронной таблицы во временную таблицу, а затем импорт с помощью SQL
• Написание скрипта и импорт данных с его помощью (я использовал VBScript, C # и теперь Ruby)

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

Но прежде чем я это сделаю, мне любопытно, есть ли способ получше?

Answer 1

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

Как только файл будет загружен, вам необходимо выполнить проверку и импорт.Для этого вы можете использовать ADO.NET, file streams, DTS / SSIS или Office Automation (если вы используете Microsoft stack).В части проверки вы должны сообщить пользователю именно так что они сделали неправильно или что нужно изменить.Это может включать в себя наличие на странице проверки фактических данных в datagrid и предоставление красных меток с ошибками в точной строке / столбце.Если вы используете Office Automation, вы можете сообщить им точный номер мобильного телефона, но Office PIA - это заноза в горле.

Как только проверка будет принята, вы сможете импортировать информацию так, как вам нравится.Я предпочитаю поместить его в промежуточную таблицу и использовать сохраненную процедуру для его загрузки, но это только у меня.Некоторые предпочитают использовать объектную модель, но это может быть очень медленно, если у вас много данных.

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

Да, это большая работа, но в долгосрочной перспективе, когда есть программа, которая работает 95% времени, выигрывают все.

Если это будет ситуация, которую просто невозможно автоматизировать, то вам, вероятно, просто нужно будет иметь промежуточную таблицу vanilla и использовать sql для импорта.Вам нужно будет загрузить данные в одну промежуточную таблицу, выполнить основные манипуляции, а затем загрузить их в промежуточную таблицу, которую ожидает ваш SQL.

Я сделал так много импорта и инструментов ETL, и на самом деле нет простого способа справиться с этим.Единственный способ - это действительно придумать разумный стандарт, придерживаться его и программировать в соответствии с ним.

Answer 2

да..это просто отстой.

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

Answer 3

Конечно, вас убьют мелкие детали, но в целом я добился успеха с экспортом данных в формате CSV из Excel, затем прочитал их с помощью rool или скрипта, обработал по мере необходимости и вставил.В зависимости от великолепия моей среды, это может быть сделано с помощью интерфейса базы данных к языку сценариев, вплоть до написания инструкций SQL INSERT в файл сценария.

Существуют хорошие CSV-пакеты, доступные для Питон, Рубин, и Perl - язык программирования.

Answer 4

DSL - это правильный путь.

Создайте модель предметной области для вашей проблемы.Вы говорите о ячейках, столбцах, строках, таблицах базы данных, разделении полей, объединении полей, сопоставлении ячеек со столбцами базы данных, так что это те концепции, которые вам нужны.Кроме того, вам, вероятно, нужны диапазоны (ячеек) и листы.

Простое представление просматривает только значения в электронных таблицах, а не лежащие в их основе формулы.Экспорт электронной таблицы в виде текста, разделенного табуляцией, дает вам доступ к этому.Если вам нужен доступ к формулам, вам лучше использовать XML-представление, либо XML-электронную таблицу, либо формат Office XML.

Возможно, вам удастся создать DSL в Excel.Это могло бы позволить вашим более умным пользователям выполнять (часть) сопоставление.