Компания, в которой я работаю, запустила новую инициативу в HL7, где мы обмениваемся сообщениями как v2X, так и v3 (в частности, CDA). Я нахожусь в той точке, когда я могу принимать, проверять и подтверждать сообщения, которые мы получаем от наших торговых партнеров, и начал создавать модель данных для внутреннего хранилища указанных сообщений. После долгих размышлений и исследований я не знаю, как лучше всего подойти к этому в MS SQL Server 2008 R2.
В настоящее время моя идея состоит в том, чтобы по существу загружать данные в хранилище данных непосредственно из моего механизма интеграции (BizTalk), минуя резервную нормализованную операционную базу данных. Я настроил базу данных для сообщений v2X в соответствии со спецификациями v2.7, поскольку все версии HL7 v2 обратно совместимы (я могу хранить любые предыдущие версии в той же базе данных). В моем первоначальном проекте есть таблица для каждого сегмента, которая будет привязана к таблице заголовков с помощью guid, который я генерирую и сохраняю во время выполнения. Самая большая проблема с этим подходом — это количество столбцов в каждой таблице, и с этим у меня нет опыта. Например, сегмент PV1 имеет 569 столбцов для размещения всех возможных данных. В дополнение к этому мне нужно сделать все столбцы varchar и сделать их достаточно большими, чтобы вместить любой возможный сценарий настройки от наших поставщиков. Я планирую использовать varchar(1024) для достижения этой цели. Многие из этих столбцов (вероятно, большинство) были бы NULL, поэтому я бы использовал столбцы SPARSE. Это кричит мне о плохом дизайне, но полная нормализация этих таблиц потребовала бы тонны работы как в BizTalk, так и в SQL сервере, и я не уверен, что я выиграю от этого. Я пытаюсь быть прагматичным, так как у меня есть крайний срок.
В случае полной нормализации мне, по сути, пришлось бы создавать хранимые процессы, которые имели бы массу параметров ИЛИ разделяли бы эти сообщения до n-й степени, чтобы выполнять отдельные загрузки в меньшие подтаблицы и убедиться, что все они соотносятся с исходным guid. Я также хотел бы поддерживать обработку ACID, которая может стать сложной и вызвать много накладных расходов в BizTalk. Я полагаю, что третьим вариантом будет использование nHapi для создания объектов из сообщений, которые я мог бы связать с Entity Framework, но nHapi кажется мертвым проектом, и на данный момент у меня нет опыта работы с Entity Framework.
Я в основном в растерянности, и мне нужна помощь некоторых профессионалов отрасли, имеющих опыт моделирования данных HL7. Стоит ли прилагать дополнительные усилия для полной нормализации таблиц? Будет ли производительность на стороне SQL ужасной, если я буду использовать эти денормализованные таблицы сегментов с сотнями столбцов (большинство из которых будет NULL для каждой строки)? Я не администратор баз данных, поэтому я пытаюсь понять подводные камни каждого подхода. Я также смотрел на RIMBAA, но RIM HL7 кажется мне иностранным языком, поскольку я новичок в HL7, и перевод сообщений v2 в RIM, вероятно, займет гораздо больше времени, чем мне нужно для завершения этого проекта. Я надеюсь, что слишком много думаю об этом, и есть более простое решение, смотрящее мне в лицо. Надеюсь, этот вопрос не слишком открытый.
