Отчетность по историческим данным - когда использовать текущие или исторические данные (? Предупредить пользователя об изменении смысла записи)

Question

Это похоже на this question

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

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

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

В настоящее время я считаю, что это должно быть последнее, потому что я склонен полагать, что с учетом того же (основного) ключа значение , которое он однозначно идентифицирует, не должно меняться, даже если это атрибуты. Итак, любые изменения имен должны быть только для исправления или разъяснения, ИМО, почти так, как если бы само имя было основным ключом (я все для естественных ключей, но, как правило, не использовал имя чего-то из-за длины и возможной необходимости в написании коррекция - в этом случае, хотя у меня есть поле «SensorNo» (не ID), которое является уникальным для контролируемого устройства).

В любом случае - это означает, что я действительно могу использовать текущее имя, и если они изменят имя датчика от «Воздуха» до «Пища», тогда он должен сказать «Продовольствие» по всем данным отчета, даже если это показывая данные до изменения, идея заключается в том, что это изменение должно означать, что оно всегда предназначалось как «Пища», а не «Воздух» - это исправление.

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

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

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

Что представляют собой мысли людей об этом? Как вы справляетесь с этой ситуацией? Мне также интересно услышать от Catcall, который ответил на вопрос, связанный.

(Обратите внимание, что это не обсуждение того, как хранятся исторические данные, я уже отлично разбираюсь в этой стороне вещей).

Answer 1

Думаю, что вы ответили сами. Если они меняют имя поля, это исправление (и тогда им не нужно видеть старое имя в новых отчетах). Если они меняют имя датчика, потому что значение изменяется, то они должны ДОБАВИТЬ новый датчик. Я не думаю, что вы действительно можете спасти своих пользователей от таких ошибок. В некоторых приложениях я видел, что они DROP базы данных, когда они создают новый набор ввода (но вы не можете или не хотите этого делать). Возможно, они отличаются, если они хотят использовать имя поставщика/модели как имя тега (имя датчика). В этом случае он может измениться во времени и, вероятно, они захотят увидеть имя true для каждого интервала. В этом случае, если изменения ограничены именем тега, вы можете сохранить себя с помощью небольшой таблицы для отслеживания этих изменений (id, name, timestamp) и обновить гипотетическую функцию ResolveTagName (id, time) для запроса этой таблицы. У меня больше сомнений относительно исторических данных для пределов, потому что они могут меняться во времени (например, максимальная температура для части может уменьшаться во времени, потому что часть становится старше или из-за измеримого физического напряжения, в этом случае вы не можете применить текущий предел для старой меры).

Answer 2

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

Путаница всегда может возникнуть. И простые меры не могут помешать этому. Предположим, что датчик теперь называется «Воздух», но в какой-то момент его называли «Пища» (и в этот момент был еще один датчик под названием «Воздух»). Как вы думаете, что можно констатировать, что никто никогда не будет проверять журналы и придумать «эй, вы даете измерения здесь для датчика« Воздух »год назад, но я сам проверил журналы и нашел совершенно разные цифры».

Есть две вещи, которые вы можете сделать. (a) попытайтесь сделать это настолько ясно, насколько это возможно, если в отчете говорится «датчик воздуха» (2 слова), то что это на самом деле означает «датчик, который был назван« воздух »на момент создания отчета , но которые, возможно, попали под разные имена до момента создания отчета и которые даже не обязательно должны быть тем же самым датчиком, что и тот, который называется «Воздух» во время вашего рассмотрения отчета »(потерянный счет). Если вы попытаетесь объяснить это своим пользователям, то лучшее, что вы можете получить, - это пустой взгляд, если они не прячут спину на вас и уходят. Если вы напишете его в руководстве, вы обнаружите, что пользователи никогда не читают руководства.

И (b) вы можете попробовать включить в отчет указания об изменениях имени в прошлом. Сделайте это немного критически (например, предупреждающая строка, например «*»), и вы получите ответы на вопросы о том, что это означает в то время, когда вы даже забыли об этом сами. Возможно, хороший вариант - напечатать отдельный раздел с прошлыми изменениями имени, прямо под заголовком или так, но если нет истории изменений имен, тогда ничего не печатайте (даже заголовки для этого дополнительного раздела).

«Мой план состоит в том, чтобы разрешить пользователям изменять имя, но сначала предупредить их о последствиях, и указать, что он должен использоваться только для исправлений».

Это не относится к вам, чтобы решить, что «это должно использоваться только для исправлений». Многие объекты реального мира обычно идентифицируются в человеческих словах, используя имена, и многие из этих объектов реального мира переходят под разные имена в течение их жизни. Вы не можете изменить тот факт, что имена являются наиболее удобными средствами идентификации практически в любой ситуации, о которой я могу думать. Если жена Билла Гейтса хочет пойти по магазинам, она спросит: «Дорогая, могу я взять Porsche», или она спросит: «Дорогая, могу ли я взять WOL0x547832187 (который может быть правильным уникальным идентификационным номером шасси Билла Гейтса) Porsche)? ". И вы не можете изменить тот факт, что вещи могут меняться.