Анатолій написав:Пане fed_lviv, тестував і не проходить тому що синтаксис не правильний чи в чомусь інша проблема, можна детальніше якщо звісно не тяжко, мені цікаво в чому я був не правий.
З синтаксисом все ОК, результат невірний, якщо я правильно розумію умови в WHERE table1.val1 BETWEEN 100 AND 20000, table1.val2 BETWEEN 100 AND 20000, ... відкидають потрібні рядки, наприклад рядок:
val1 val2
123,67 99999999,99
І ось даний рядок відкидається, бо val2 значення "паскудне", але на жаль відкидається "нормальне" значення val1.
Анатолій написав:І ще, для розмови, якщо брати ситуацію, що я спостерігаю час від часу в себе на роботі в частині Програмно Технічного Комплексу то ні ні, але бувають збої в передачі даних, "підвіс" контроллер чи діагностичний блочок, і просто не передає пакети даних, як результат обладнання, що приймає дані висвітлює "недостовірні" дані, але ніяк не значення "0". Якщо ж розглядати ситуацію пана fed_lviv, то у випадку збою мені так і кортить сказати що запис в таблицю буде NULL.
І якщо все ж йти в напрямку зручності обробки даних, то цей момент також варто вказувати, що за добу вироблено стількито кКалорій енергії та зафіксовано N збоїв обладнання, де "збої" це саме й були б некоректні дані, поза межами прогнозованих показників.
Знову ж якщо брати приклад з моєї роботи то є модель обєкту і якщо реальні показники відхиляються від показників моделі, висвітлюється попереджувальне повідомлення про некоректну роботу обладнанння.
Що ж до Вашого проекту пане fed_lviv, можливо теж варто застосувати певні перевірки коректності даних?. Правда Ви й так їх виконуєте, але питання перевірка в якому обємі і чи доцільно.
Якщо це просто лабораторну роботу здати тоді питань нема, але якщо це необхідний життєвий проект, то задачка постає справді дуже цікава )
Що я тут можу сказати, вчора зіткунвся з черговим варіантом "неправильних" даних, тобто маю вже три варіанти. Припустимо реальний показник лічильника: 12345678,99.
Варіанти:
1. 99999999,99
2. 0
і новий варіант
3. 2471534,88 (тобто не максимальне і не мінімальне число), це взагалі повна ж...
А варіанту NULL, не має і хоч плач.
Тобто, таке враження, що тут жоден запит не допоможе. Оскільки, щоб побачити чи дійсно правдиве значення, потрібно подивитися всі дані за добу і побачити чи не було різкого відхилення.
Я вже казав, як на мою, думку то дані, які передаються в БД, мали б перед цим перевірятися. Чому вони не перевіряються я не знаю! Та й в принципі, як їх перевіряти я теж не знаю, оскільки я таким ніколи не займався. Знаю що для передачі даних з лічильника викоистовуюють інтерфейс RS 485 (гуглив, начебто перевірку можна робити).
Нарахунок проекту. Скажімо так, за освітою та й за посадою по бумажках, я для цієї роботи не гожусь. Але, мені цікаво + керівництво тільки ЗА, якщо кожна людина на роботі в будь-який момент буде мати можливість побачити показники лічильників, зробити звіт показників за добу, місяць. А проблема в тому, що даний проект дуже "сильно розбитий" по службах. За підключення лічильників до диспетчерезації відповідає одна служба, за проектування БД інша, за проектування сайта (десктопа) - по ідеї взагалі інша організація. І якщо виникає проблема, ніхто нічого не знає і фіг кого можна знайти.
P.S. Щойно дізнався думку людей, які безпосередньо беруть участь у даному проекті: "В БД вносяться любі значення, а далі з БД їх має перевіряти на достовірність програма вищого рівня"
P.S. Я думаю Ваш запит підійшов би, якби були зпроектовані таблиці для різних лічильників (таблиця1 - електролічильники 1 вводу; таблиця2 - електролічильники 2 вводу; таблиця3 - газові лічильники,...). А в результаті все запхано в одну таблицю, де майже 60 стовбців.