Женя32,

select MAX(cold_water)-MIN(cold_water) FROM table WHERE date>=дата_начала AND date<=дата_конца

Женя32chabapokЖеня32,

select MAX(cold_water)-MIN(cold_water) FROM table WHERE date>=дата_начала AND date<=дата_конца
Дело в том, что начальная и конечная дата не фиксированные...

Не фиксированные на этапе компиляции или на этапе выполнения? Если на этапе выполнения - значит, вы неверно обьяснили что вам нужно. Возможно даже вы сами недоконца понимаете что хотите. Что значит не фиксированные? Как можно выбрать разницу показаний по непонятно_каким месяцам?

Если на этапе компиляции - то это нормально. Значит на этапе выпонения начало и конец известны, вот и конструируете нужный запрос и выполняете его.

tanglirпо последним четырём на текущий момент.

SELECT MAX(cold_water)-MIN(cold_water) FROM (select cold_water FROM table ORDER BY date DESC LIMIT 4)

1. вашего вопроса я не понял

2. программа, устойчивая ко ошибкам которые ввел ей человек - это нобелевка, и возможно не одна. Частично ошибки можно выловить, например если ожидается ввод месяца, а ввели 22 - это ошибка, т.к. должно быть число меньше или равное 12. Но если ввели число в рамках ожидаемого диапазона - ни одна программа никогда не скажет что это ошибка.

3. запрос постом выше не подходит?

"ТС же ясно написал (таки заглянул, похоже, в спойлер): в месяц N передали 11, в месяц N+1 передали 22, а в месяц N+2 передали 18"

что значит "передать в месяц"? 11,22,18 - это расходы? Или это месяцы? непонятно.
вобщем, пока нормально задача не сформулирована.

Тогда, имхо, при помощи только mysql это не решить. Надо вытягивать эти строки в свою программу, и анализировать их. потому что появление 18 после 22 - это переполнение, (и строго говоря - не факт что перепеолнение однократное) то есть реальный расход зависит от колиества разрядов в счетчике.

tanglirchabapokпереполнениеразверните мысль

http://ru.wikipedia.org/wiki/Арифметическое_переполнение

Переполнение происходит в любом счетчике, где кол-во разрядов фиксированно. Например, в автомобильном одометре как правило шесть разрядов. Если поехать 999999км а потом проехать еще 2км, то показывать будет 000001. Тоже самое со счетчиком воды. 18 после 22, это свидетельство того, что было переполнение. (или что поставили новый счетчик, но будем этот случай не учитывать) Тогда реальный расход зависит от количества разрядов в счетчике. Например, если в нем 3 разряда, то это скоерй всего значит, что от 22 он досчитал до 999 потом сбросился в 0 и досчитал до 18. Ну то есть на самом деле это 22->1018, но единичка в самый старший разряд утерян.

Cygapb-007Давайте все же определимся с невнятностями терминологии :)

Насколько я понял, задачу можно сформулировать так: обрабатывабются показатели счетчиков воды по разным лицевым счетам. Каждый л/счет содержит 2 строки (т.к. даты ввода показаний могут различаться) - тип счетчика (хол/гор вода), дата снятия показаний и значение счетчика воды. Значение счетчика со временем может только возрастать (или как минимум неубывать). Если ошибочно введено большее значение, чем на счетчике, это считается авансом, потому как потом все равно нарастет до ранее введенного. Однако все же есть возможность исправить явно ошибочное значение (например, введено 2200 вместо 22.00) - но неясно на какую дату относить это исправление, если расчет стоимости уже произведен.


определиться с невнятностями - идея хорошая, только какое вы имеете отношение к топикстартеру?

"Если ошибочно введено большее значение, чем на счетчике, это считается авансом" -- програмно этот факт не вычислить. Или нужна еще галочка "данное значение больше чем на счетчике" или галочка "это значение введено ошибочно". Ну или что-то вроде этого. Вобщем, так не бывает. Хотите чтоб было без ошибок - делайте электронную систему сьема показаний счетчика в несколько каналов ввода. Это явно не случай топикстартера.

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

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

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. Как-то реагировать на ошибки - это вообще не вопрос базы, это скорей уже вопрос алгоритмов.

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