Лучший подход к обработке данных SQL - PullRequest
Новая
       30

Лучший подход к обработке данных SQL

3 голосов
/ 24 июня 2010

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

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

, поэтому у нас есть несколько таблиц, которые выглядят следующим образом. 

Dentist | Procedure1 | Procedure2 | Procedure3 | .........| Procedure?
John    | 500        | 342        | 434        | .........| 843
Dave    | 343        | 434        | 322        | NULLs....|
Mary    | 500        | 342        | 434        | .........| 843
Linda   | 500        | 342        | Null       | .........| 843

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

, как у Джона будет 001, у Дейва 002, но у Мэри будет 001, а у Линды 003 Это не так плохо, еслиМне приходилось иметь дело с этими данными один раз, но эти списки платных платежей представлены в виде простых файлов (csvs), с которыми мне в основном приходится работать в DTS до сервера SQL.и они приходят ежемесячно.Цены могут меняться от месяца к месяцу для каждого стоматолога, который затем будет внутренне присваивать им разные уникальные идентификаторы.

Может кто-нибудь пролить свет на то, как лучше всего подойти к этой проблеме, чтобы наиболее эффективно обрабатывать ежемесячно, не прибегая к куче манипуляций с данными?

  1. чтолучший подход к обнаружению дубликатов списков сборов?
  2. Как отслеживать обновление списка сборов стоматолога, если они изменят свои ставки в следующем месяце?если Мэри решит взимать другую плату за процедуру2, то у нее будет другой уникальный внутренний идентификатор.как отслеживать это ежемесячно без необходимости удалять все и вставлять заново?
  3. Есть несколько миллионов списков платежей, с которыми я работаю, и некоторые имеют стандартные правила, основанные на почтовых индексаха некоторые - просто уникальные списки гонораров, какой здесь подход?
  4. Я могу написать какую-то специальную .net-программу для работы с ней, но это много данных, и работать прямо на SQL-сервере будет прощедля меня.

любая помощь будет отличной, спасибо, ребята.

1 Ответ

1 голос
/ 24 июня 2010

Вам, вероятно, нужно отменить поворот данных, чтобы их нормализовать, чтобы в итоге вы получили: 

Doctor: DoctorID, DoctorDetails...
FeeSchedule: DoctorID, ScheduleID, EffectiveDate, OtherDetailAtThisLevel...
FeeScheduleDetail: ScheduleID, ProcedureCode, Fee, OtherDetailAtThisLevel...

Когда данные поступают для врача, они поворачиваются, создается новое расписание иСтроки подробностей создаются из непивотированных данных.

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

Эта система будет отслеживать новые расписания для врачей.Если расписание для врача идентично, вы просто не могли бы его вставить.

Если эта логика обширна, вы можете загрузить данные в промежуточные таблицы (SSIS или что-то еще) и сделать все это в SQL (T-SQL также имеет оператор UNPIVOT).Это может иметь преимущества в том, что код находится в одном месте и может выполнять все свои операции в наборах.

Что касается почтовых индексов, если у врача нет комиссии, это как обычная и обычная плата?Это может быть просто определено из почтового индекса строки доктора.В этом случае у вас есть несколько вариантов.Вы можете наложить график оплаты услуг врача на график оплаты по почтовому индексу: 

ZipCodeSchedule: ZipScheduleID, ZipCode, EffectiveDate
ZipCodeScheduleDetail: ZipScheduleID, ProcedureCode, Fee

Или вы можете сохранить это в обычном графике оплаты (возможно, с каким-то флагом, который был установлен по умолчанию в UCR).*

...