Хранение данных из таблицы в таблицу «трендов»

Question

У нас есть таблица, для которой мы должны представить множество счетов для разных комбинаций полей. Это занимает довольно много времени, чтобы делать «на лету» и не предоставляет исторических данных, поэтому я думаю, что лучше всего сохранить эти счета в другой таблице с отметкой времени, чтобы мы могли быстро их запросить и получить исторические тенденции , Для каждого счета нам нужно 4 части информации, чтобы идентифицировать его, и есть около 1000 различных показателей, которые мы хотели бы сохранить. Я думаю о трех разных стратегиях, имеющих счет и временную метку, но различающихся тем, как идентифицировать счетчик для поиска.

1. 1 таблица с 4 полями для определения количества, 4 поля не будут нормализованы, так как они содержат данные из разных внешних таблиц.
2. 1 стол с полем «тег», который будет содержать 4 части информации в виде тега. Эти теги могут быть обогащены и сохранены в другой таблице, возможно, с полем для каждой части тега и привязкой их к внешним таблицам.
3. Различные таблицы для разных групп счетчиков, чтобы иметь возможность нормализовать одно или несколько полей, но для этого потребуется от 6 до десятков таблиц.

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

Пример значения: статус, установленный, все, виртуальный, 1234,01/05/2015

• Первое поле, статус, может иметь до 10 значений
• Второе поле, установлено, может иметь до 10 баллов за разное поле 1
• Третье поле может иметь до 10 различных значений, но они одинаковы для всех категорий
• Четвертое поле, виртуальное, может иметь до 30 значений, а также быть одинаковым для всех предыдущих категорий.
• Последние два поля будет номер и отметку времени

Спасибо, Исаак

Answer 1

Когда у вас есть много метрик, и вы не должны использовать их, чтобы сделать интра-метрики расчета вас может пойти на 1. решение.

я бы, вероятно, построить таблицу как этот

Satus_id | Installed_id | All_id | Virtual_id | Date | Value 

Или, если комбинация первых четырех столбцов имеют собственное имя, я бы, вероятно создать две таблицы (я думаю, что вы смотрите на эту возможность в качестве второго решение с 2):

Metric Table 
Satus_id | Installed_id | All_id | Virtual_id | Metric_id | Metric_Name 

Values Table 
Metric_id | Date | Value 

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

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

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

Satus_id | Installed_id | Date | All1_Virtual1 | All1_Virtual2 | ... | All10_Virtua30 

С 10 значений для всех и 30 для Virtual вы будете иметь 300 столбцов, не очень просты в обращении, но они будут стоить, чтобы иметь, если вы должны сделать что-то вроде:

(All1_Virtual2 - All5_Virtual23) * All6_Virtual12 

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