SQL запрос

[NN13]

[quote="GShapievВот этот запрос

Code: Select all

SELECT test.id, test.date,  test.house 
FROM test INNER JOIN test AS t2 ON datevalue(test.date) = datevalue(t2.date) and test.house = t2.house
GROUP BY test.id, test.date,  test.house 
having test.date = max(t2.date)
order by test.date

[/quote]

PS having will do the job, but it's the most unefficient way to use SQL

[GShapiev]

PS having will do the job, but it's the most unefficient way to use SQL

И чем же это хуже сабселекта?

[Kotkov]

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

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

[SVK]

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

Слабо?

Ну, "охотничьи рассказы"? :

см. пост выше.
Правда для Access-а

Вообще-то ON datevalue(test.date) = datevalue(t2.date) выдает сначала квадрат числа записей за каждый дом за каждый день... То есть при 100 записях в день за каждый дом сначала join создаст по 10000 промежуточных записей для каждого дома за каждый день???....

"А уж утюг я и включать не стал..." (С)Из советского анекдота

[katit]

Вот будет смешно если "стопудовость" измениться.
Согласен с SVK, что последовательность ID не всегда отображает последовательность во времени.

Надо искать легкие пути!
Человек не точно сформулировал!
Мы программисты!

[GShapiev]

[quote="SVK]Вообще-то ON datevalue(test.date) = datevalue(t2.date) выдает сначала квадрат числа записей за каждый дом за каждый день... То есть при 100 записях в день за каждый дом сначала join создаст по 10000 промежуточных записей для каждого дома за каждый день???....

"А уж утюг я и включать не стал..." (С)Из советского анекдота[/quote]

Well. Не то, чтобы я спорил и все такое.
Версия базы была без вложенных селектов. Поэтому выбора не было.
И потом чем это хуже. Сделать один Join и потом выборку или на каждую запись делать селект. Я не уверен, что будет быстрее.

[SVK]

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

Товарищ показал первые 5 или 6 строк своей таблицы. Откуда вывод про последовательное заполнение???

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

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

[GShapiev]

прям чисто Baterfly Effect

[katit]

Товарищ показал первые 5 или 6 строк своей таблицы. Откуда вывод про последовательное заполнение???

Я смотрю в корень
Он раньше писал про ихнюю аппликуху
Там вроде как по мере поступления данных они вносятся.
Я ведь написал что _я так думаю_
Поэтому если оно так и есть то это будет решение.

[SVK]

И потом чем это хуже. Сделать один Join и потом выборку или на каждую запись делать селект. Я не уверен, что будет быстрее.

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

На реальной базе из 10^6----10^9----10^12----10^15---... записей..... Хм-м... На Земле может закончиться не только нефть, но и кварцевый песок, прежде чем SQL строящий квадратичные join-ы завершится....

[GShapiev]

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

На реальной базе из 10^6----10^9----10^12----10^15---... записей..... Хм-м... На Земле может закончиться не только нефть, но и кварцевый песок, прежде чем SQL строящий квадратичные join-ы завершится....

Все конечно так
Но мне что-то не кажется что надо будет всю информацию за все время выдавать
Там же сразу уже условия на дома, да и наверняка на дату.

[Flying Hen]

Создать еще одну таблицу. Заполнять ее триггером или встроенной процедурой.

[shadow7256]

чтобы народ не догадывался что происходит. объясню подробнее.

Каждые 15 минут в таблицу дампятся данные для 15 разных домов.

Первое поле (id) - это primary key. Соответственно он создается автоматически и инкрементится тоже автоматически.

ID домов известны заранее. Поле datetime тоже генерится автоматически функцией getdate ().

Дамп заканчивается в какое то определенной время (вставляются последние записи за день).

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

Спасибо

[Vik_NJ]

А вот извращенное решение...
select * from whateverTable
where id in
(select convert(integer, substring(
max( convert (char( 8 ), dateField, 112)+
convert (char ( 12 ), dateField, 114)+
convert(char, id)),
21,12))
from whateverTable
group by convert (char( 8 ), dateField, 112)
)