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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

Есть хорошие пакеты CSV для Python , Ruby и Perl .

Answer 3

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

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

Answer 4

DSL - это путь.

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

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

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