Зачем использовать таблицы поиска в базе данных

Question

Это теоретический вопрос, который я задаю из-за запроса, который пришел мне недавно. Я владею поддержкой главного хранилища оперативных данных, который поддерживает набор таблиц данных (с основными данными), а также набор таблиц поиска (которые содержат список ссылочных кодов вместе с их описаниями). Недавно появилось приложение из нисходящих приложений для логического объединения двух структур (данных и поисковых значений) на уровне презентации, чтобы им было легче узнать, были ли обновления в общих данных. Хотя запрос понятен, моя первая мысль заключается в том, что он должен быть реализован на уровне интерфейса, а не в источнике. Объединение двух таблиц логически (last_update_date) на уровне ODS почти похоже на де-нормировку данных и, по-видимому, противоречит идее раздельного поиска и данных. Тем не менее, я не могу придумать, почему это не должно делаться на уровне ОРВ, кроме того факта, что оно «не кажется» правильным ... У кого-нибудь есть мысли о том, почему такой подход должен или должен не следовать?

Я приведу пример здесь для простоты.

Data table 
ID Name Emp_typ_cd Last_update_date 
1  X  E1   2014-08-01 
2  Y  E2   2014-08-01 

Code table 
Emp_typ_cd  Emp_typ_desc Last_Update_date 
E1    Employee_1  2014-08-23 
E2    Employee_2  2013-09-01 

Запрос вниз по течению, чтобы представить данные в виде

Data view 
ID Name Emp_typ_cd Last_update_date 
1  X  E1   2014-08-23 
2  Y  E2   2014-08-01 

или

Data view 
ID Name Emp_typ_cd Emp_typ_desc Last_update_date 
1  X  E1   Employee_1  2014-08-23 
2  Y  E2   Employee_2  2014-08-01 

Answer 1

Вы правильно, это деморализует базы данных, потому что кто-то хочет видеть данные в определенном путь. По-вашему, побочные эффекты - это то, что вы дублируете данные, уменьшаете гибкость, увеличиваете размер таблицы, сохраняете разные объекты вместе и т. Д. Вы также правы, что их проблема должна быть решена где-то или как-то иначе. Они не получат того, чего хотят, если они изменят базу данных так, как они хотят ее изменить. Если они хотят, чтобы «легче было узнать, были ли обновления в общих данных», но они дублируют огромные суммы, они просто открывают себе ошибки. В вашем примере обновленное значение Emp_typ_cd должно быть обновлено для всех сотрудников с этим кодом типа emp. Хорошая инструкция по обновлению будет делать это, но все же вместо обновления одной строки в таблице поиска вы обновляете каждый отдельный сотрудник с типом emp.

Мы постоянно используем таблицы поиска. Мы можем добавить новое значение в таблицу поиска, добавить сотрудников в базу данных с помощью fk к этому новому атрибуту, и любой отчет, который присоединяется к этой таблице, теперь имеет идентификатор, значение, порядок сортировки и т. Д. Скажем, мы добавляем «Ветеран 'к опыту lu_Work_Experience. Мы добавляем сотрудника с ветераном fk_Id, и теперь любой существующий запрос, который присоединяется к lu_Work_Experience, имеет это значение. Они сортируют опыт работы в алфавитном порядке или по нашему заранее определенному виду.

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

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

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