Дизайн БД: данные конфигурации, фактические данные, данные журнала

Question

Я хочу знать, существует ли какой-либо типичный подход для дифференциации такого рода данных

Я должен перечислить устройства (например) в БД, и каждый будет иметь

• Данные конфигурации
• Фактические данные
• Данные журнала

Я обычно смешиваю Config / Actual Data в одной и той же таблице и другой таблице для данных журнала ,

Кажется, это обычная проблема, поэтому мне интересно, есть ли какой-нибудь стандартный способ сделать это.

EDIT:

Вот пример

Семафор на улице:

• Данные конфигурации = позиция (пересечение улиц), тип (для пассажиров, автомобили) и т.д ..
• Фактические данные = colorstate = красный, зеленый, ходить, останавливаться .. функциональность = в порядке, ремонтируется и т.
• Данные журнала = дата / время + цветное состояние + (любые другие фактические данные, которые необходимо зарегистрировать)

Спасибо

Answer 1

Вы можете разделить его следующим образом (лениво относиться к синтаксису и типам sql):

`

signal_config

id (ключ) тип позиции

signal_log

signal_id, отметка времени (составной ключ) color_stat один из (красный, желтый, зеленый) function_state `

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

Answer 2

Я думаю, что здесь есть некоторая путаница в терминологии.

То, что вы называете «данными конфигурации», звучит для меня как «бизнес-ключ» или «ключ-кандидат»: набор данных, который (вероятно) неизменен и который однозначно идентифицирует сущность: есть только одинсветофор в конце главной улицы.

То, что вы называете «фактическими данными», похоже на атрибуты сущности, которые со временем меняются.

Так что я не думаю, что есть проблема с дизайном, помещая их в одно и то жеТаблица.

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

Answer 3

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

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

Answer 4

похоже, вы бы выиграли от правильной нормализации этой информации в нескольких таблицах.