Преобразование проекта в SQL Server, мысли о дизайне?

Question

В настоящее время я сижу на некрасивом бизнес-приложении, написанном в Access, которое получает электронную таблицу раз в два дня и импортирует ее в MDB. В настоящее время я преобразую крупный проект, который включает это в SQL Server и .net, особенно в C #.

Для размещения этой информации есть две таблицы (здесь псевдонимы), которые я назову Master_Prod и Master_Sheet, соединенные на родительском ключе идентификатора с таблицей Master_Prod, ProdID. Есть также еще две таблицы для хранения истории, History_Prod и History_Sheet. Существуют и другие таблицы, которые выходят за пределы Master_Prod, но ограничиваются двумя таблицами для пояснения.

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

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

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

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

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

Мысли о лучшем способе реализовать это в том же направлении?

Answer 1

Использование SSIS . Используйте Источник Excel для чтения электронных таблиц, возможно используйте преобразование Lookup для обнаружения новых элементов и, наконец, используйте Назначение SQL Server , чтобы вставить поток отсутствующих элементов в SQL.

SSIS - это способ лучше подходит для такого рода работ, которые пишут что-то с нуля, независимо от того, насколько увлекательным является linq. Пакеты служб SSIS легче отлаживать, поддерживать и реорганизовать, чем некоторые библиотеки DLL с заброшенными источниками. Кроме того, вы не сможете соответствовать усовершенствованиям, которые SSIS имеет в управлении своими буферами для высокой пропускной способности Потоки данных .

Answer 2

Первоначально я надеялся поставить это процедура в какой-то CLR сборка, которая принимает IEnumerable список, так как у меня будет таблица в этой форме уже, но я недавно узнал, что это будет в паре с довольно важной базой данных сервер, который меня очень беспокоит увязая.

не работает. Любой ввод в процедуру CLR, написанную на C #, STILL должен следовать обычной семантике SQL. Все, что может измениться, это внутренняя настройка. Любое общение с клиентом должно быть сделано в SQL. Что означает выполнение / вызов метода. Невозможно напрямую передать перечисляемые объекты.

Answer 3

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

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

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

Обычно я думаю о поступающих данных (на самом деле это не объектная модель или сущность). Затем я сосредотачиваюсь на формате и семантике входных данных и смотрю, есть ли несоответствие в моей модели данных - возможно, в моей модели данных были предположения, которые были неверны. Да, я не думаю о создании объектной модели, которая проверяет электронную таблицу, хотя электронные таблицы, как известно, нестабильны. Как и Ремус, я бы просто использовал SSIS, чтобы перенести его - возможно, в промежуточную таблицу, а затем провести дополнительную проверку, прежде чем применять его к рабочим таблицам с некоторым T-SQL.

Тогда я бы подумал о клиентском инструменте, в котором объектная модель была основана на моей хорошей модели твердых данных.

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

Я могу вспомнить пример, где у меня была выбрасываемая модель внешнего объекта вроде этого. Он прочитал «главный файл», который был файлом макета, описывающим входной файл. Эта объектная модель позволяла программе создавать пакеты служб SSIS (и сценарии BCP и SQL) для импорта / экспорта / выполнения других операций с этими файлами. По сути, это была одноразовая объектная модель - она ​​не использовалась в качестве фактической модели для данных в строках или любого вида навигации между родительскими и дочерними строками и т. Д., А просто для внутреннего представления для внутренних целей - это не обязательно соответствуют сущности "домен".