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

Суть проблемы заключается в следующем: необходимо импортировать неструктурированные данные из Excel в несколько таблиц на Sql Server.

Импорт будет производится путем запуска приложения на VBA.
Приложение одновременно будет и записывать данные и формировать из уже записанных данных отчёт.

Объем загружаемых данных не больше 10000 строк за 1 запуск приложения. Одновременно работать с базой могут работать до 10 пользователей.

Сейчас я сделал реализацию несколькими способами:

1) На сервере создана таблица для импорта данных с нужными форматами, но без ключей. Проверка форматов происходит на стороне клиентского приложения , далее идет импорт данных в загрузочную таблицу с указанием @@spid пользователя.
Далее клиентское приложение вызывает хранимую процедуру, в которой вызывается транзакция, которая распределяет данные по таблицам, делая проверки на уникальность ключей. После этого процедура стирает данные из загрузочной таблицы, используя как ключ @@spid пользователя.
В этом подходе меня смущает проблема контроля данных в загрузочной таблице, когда одновременно несколько пользователей будут работать.

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

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

AkinaStarDestroyer89На стороне приложения создается временная таблица , туда происходит импорт данных , а далее приложением вызывается хранимая процедура, которая ссылается в коде на временную таблицу.Не понял... временная таблица на клиенте - это в Экселе, что ли?

StarDestroyer89В этом подходе меня смущает проблема контроля данных в загрузочной таблице, когда одновременно несколько пользователей будут работать.А в чём суть проблемы? Что Вы собираетесь там контролировать?

StarDestroyer89как технически лучше реализовывать механизм распределения данных по таблицам?Работу с неструктурированными или денормализованными исходниками по приведению их во вменяемый формат можно оставить клиенту. А вот работу с данными лучше поручать тому, кто предназначен для работы с данными - т.е. серверу БД.

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

StarDestroyer89импорт данных в загрузочную таблицу с указанием @@spid пользователя.Соединение может и порваться... что, начинать всё сначала?


Я просто неверно выразился: временная таблица конечно же создается на сервере, просто скрипт на ее создание я формирую на клиенте - это не очень нравится, так как код получается длинный(в таблице 30 столбцов).

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

andreymx,

процесс импорта будет постоянным .

MindВладислав КолосовStarDestroyer89,

Сделайте общую папку, в которую 10 человек будут сбрасывать файлы для загрузки.
Создайте пакет Intergation Services, который будет по расписанию смотреть в эту папку и загружать содержимое файлов на сервер.
Идите в кассу за премией.Intergation Services отчет тоже нарисует? Ну и пользователям может не понравиться что нет кнопки - "начать загрузку". Кинул файл в папку и сиди жди пока тебе отчет пришлют?

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

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

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

Ну и конечно нужно убедиться что у вас весь процессинг в одном коннекшене происходит, иначе получите "объект не найден".

Тоесть лучше остановится на первом варианте с постоянной таблицей , сделав изоляцию на уровне строк, как, например, советовал uaggster ?

PizzaPizzaStarDestroyer89необходимо импортировать неструктурированные данные из Excel

Объем загружаемых данных не больше 10000 строк за 1 запуск приложения. Одновременно работать с базой могут работать до 10 пользователей.


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

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

Не, я конечно допускаю, что есть задачи, когда пользователь ручками набивает 10000 строк, но это очень очень редкая задача имхо.

Вы все правильно подметили: у данных есть конкретный источник данных. Данные берутся из нескольких транзакций ERP системы SAP.
Потом в Excel по определенной логике преобразовываются и далее запускается импорт на SQL, а далее пользователи получают сложный отчет в Excel.

Я знаю, что решение костыльное - в силу определенных бизнес-процессов и политик безопасности я не могу напрямую работать с таблицами SAP, как и настроить регулярную выгрузку на SQL, чтобы сразу строить отчёт.

Поэтому данные уже имеют определенную структуру и форматы - требуется лишь определенная проверка на бизнес-логику.