Cygapb-007,

Ну вы тоже предложили свой вариант - получается это ваши догадки в чужой теме.

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

tanglirв 99% случаев это свидетельство того, что были переданы ошибочные показания.
Хорошо, но только если так считать, оставшийся 1% - это ложка дегтя в бочке меда.
И вероятность, что это ошибка ввода тем меньше, чем ближе к концу диапазона счетчика мы приближаемся. Например, если счетчик шестизначный, и после 120000 ввели 110000 - то наверное это ошибка (ну или был аванс), а если после 999100 ввели 10 - то это не ошибка и не аванс, а переполнение.

tanglirСпасибо, подняли настроение с утра.
под "на этапе ввода" подразумевалась и серверная часть тоже - с проверкой валидности.


tanglirchabapokТопикстартер допустил неоднозначностьвгде он допустил "неоднозначность"?
Вот тутЖеня32человек может ошибиться и записать неверные показания. Например, 1-й месяц = 11; 2-й месяц (ошибся, и записал не верные показания) = 22; 3-й месяц = 18всё описано предельно ясно, никаких домысливаний не требуется (по крайней мере, большинству присутствующих в теме).

Во-первых, один пример не обязан покрывать все возможные случаи. Во-вторых, топикстартер, судя по вопросу, имеет мало опыта, поэтому некоторые проблемы просто еще не видит. Но это как суслик - его не видно, а он есть.
В его идеях еще есть такие моменты.
1. Показания вводятся "на текущий момент". Это значит, что во 2й месяц туда введут 22, и только через месяц, когда туда введут 18 станет ясно, что где-то есть ошибка. Но где - все еще не ясно. А на протяжении всего месяца система будет работать, как будто ошибки нет. Через месяц возникнет подозрение на ошибку, но оно равновероятно для строк с числом 18 и 22. И только по последующим строкам можно как-то попытаться понять в какой строке была ошибка и корректировать, например, заменив это 22 интерполированным значением. Но это будет возможно только через время - когда последующие строки появятся. Но считать надо сейчас, с теми данными что есть.

2. Когда происходит замена счетчика, то никто не отматывает показания нового счетчика, чтобы они равнялись старому. При этом в базе, например, может появится еще 1 строка с отрицательным компенсирующим числом. И тогда вместо LIMIT 4 уже надо будет уже делать LIMIT 5, а если 1 месяц показания записать забудут - то надо делать LIMIT 3. Т.е. в общем случе LIMIT не годится, поэтому я бы делал выбор строк через WHERE.

3. Как-то реагировать на ошибки - это вообще не вопрос базы, это скорей уже вопрос алгоритмов.

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