Улыбнул :)

green_mcДоброго времени суток!
Мне трудно дается файербердовский сиквел, не могли бы вы покритиковать запрос.
Задача такая. Есть две таблицы S1 и T1 связанные по ID, в каждой из этих таблиц есть поле DATA1, которое имеет вид
"dd.mm.yyyy hh:mi:ss". так вот нужно выкатить разницу времени S1.data1 и T1.data1 по общему ID.
в документации прочитал про возможность преобразования CAST, прикинл запрос такого вида




подскажите в какую сторону копать?

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

и старайся избавляться от скрытых джоинов
from s1,t1
в разы быстрей будет выполнятся

DarkMasteranpl,

Ну тут ты погорячился. Почитай, как дата хранится.

каст добавить не проблема!)))

m7manplи старайся избавляться от скрытых джоинов
from s1,t1
в разы быстрей будет выполнятся



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

WildSeryПерестаньте уже писать

Пишите

Ну или хотя бы


Неявные преобразования вас когда-нибудь подставят.

Согласен! =)
WildSeryНу то есть все функции SQL-сервера, под которые собственно он заточен, нафиг, лучше на клиенте в гигабайтах ковыряться.
буду спорить :) Особенно по поводу ковыряния в гигабайтах! Где от за сотню конектов...
Если такой бред запустит один пользователь, пол беды... Но как показывает практика, если на уровне сервера все это решать... и десяток человек запустит подобные отчеты, остальные 90 человек это на себе почувствуют! :) Это факт... Так же как и то, что 10 отчетов выкрутятся намного быстрей с относительно легкими селектами и обработкой на клиенте чем все 10 отчетов будет маслать сервер!
По этому обращение к серверу лучше делать легкими селектами, а на клиенте ковырять эти данные. Хотя опять же таки в зависимости от того какая задача, далеко не всегда получается все делать на уровне клиента...

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

Как всегда, начали за здравие, а кончили за упокой.
Я не говорил за отдельные базы которые хранятся на отдельных серверах и т.д... Что касается куба, реализовать OLAP систему никто не мешает на уровне реалиционной бд и клиента. Опять же таки по тому же принципу. Но здесь нужно понимать что данные должны хранится в некой таблице в развернутом виде. И получать доступ к этим данным обычной выборкой легко и быстро! А на уровне клиента обрабатывать эти данные в зависимости от того, что пользователь хочет увидеть. Я веду к тому что никто не запрещает создать на уровне клиента некий модуль который будет формировать и отправлять запросы на сервер к некой таблице в зависимости от того что хочет юзер, возвращать данные и обрабатывать данные. Не буду углубляться в подробности, так как от основной темы это уже ушло далеко :)