Форум пользователей MySQL

SELECT coeff FROM tablename WHERE period < :period ORDER BY period DESC LIMIT 1;

Не то немного... Если период меньше, чем 3, то ничего не вернёт... :-(

Артём Н. написал:

Не то немного... Если период меньше, чем 3, то ничего не вернёт... :-(

А в базе есть данные за период меньше, чем три месяца?

Артём Н. написал:

И, если, 3.5 месяца, например, он вернёт 3, а не 4...(

Если вы подразумеваете, что при вводе периода за 3.5 месяца вы хотите получить данные за 4 месяца, то используйте period <= round(PERIOD_USE)
А лучше проводите обработку на клиенте до формирования запроса, чтобы PERIOD_USE имел не дробный вид, а округленный в нужную вам сторону.

Артём Н. написал:

А в базе есть данные за период меньше, чем три месяца?

Это "период сезонного использования". Например, ТС используется 3 месяца в году или менее.
К тому же, это только пример. Там сходных запросов несколько.

Не понял. Если ТС используется менее 3 месяцев, то как выглядит запись о ней в базе?

В первом случае, он ничего не выбирал, если значение превышает максимум в таблице.
В вашем запросе (в запросе от paulus) не выбирает, если значение меньше минимума.
Конечно, возможно два запроса использовать, но, наверное, имеется возможность сделать одним запросом?

Отредактированно Артём Н. (30.03.2010 10:06:40)

Да, если 2 месяца, то коэффициент должен быть 0,4. Если 11 месяцев, то 1.
Т.е., при меньшем/большем значениях периода - крайние коэффициенты.
Хм... В принципе, логично.
Но, что нехорошо. Ведь справочники возможно править. Если там будет стоять 0 в периоде использования... Неочевидно для пользователя.
Это первое.
Второе, и более важное - это то, что, в таком случае, при значении периода, к примеру, 3.5 он должен вернуть 0,5. Но он вернёт 0,4.

Конечно, двумя запросами сделать возможно. Но такое подозрение, что это возможно сделать как-то проще...

Отредактированно Артём Н. (31.03.2010 00:28:18)

paulus написал:

Попробуйте сделать из «маркетинговой» таблички «реальную». Если
в табличке написано, что 0.5 наступает *после* четырех месяцев, то
это именно так. А у Вас 0.5 наступает после *трех* месяцев.

Уф, это я погорячился, наверное. %-)

Нужно делать так, как оно на самом деле есть, а не так, как лучше
надурить людей :)

Так коэффициенты в законе определены. Тут я просто, похоже, ошибся.
Спрошу ещё...
Хм... Но идея хорошая. ;-)

К слову сказать, если в маркетинговой табличке
написать словами «больше трех месяцев» — это будет понятно и от-
крыто. Возможно, больше клиентов привлечете простой честностью.
Ну и, когда люди честны с собой, у них и запросы пишутся проще ;)

Да эту табличку будет видеть только администратор, и то - редко. :-)
Когда меняются коэффициенты и нужно изменить их в справочнике. Это нечасто бывает.
Администратор меняет их через интерфейс, естественно, а не через запрос UPDATE в клиенте mysql. :-)
Представьте лёгкое удивление, когда вместо ожидаемых двух месяцев там будет стоять ноль...
Плюс ещё, охота сделать, чтобы число периодов тоже возможно было менять.
Зачем на практике - не знаю. Ради универсальности.

P.S.: Спасибо, что заметили ошибку с коэффициентами. Буду ещё перепроверять.
Может, где ещё напортачил. :-\

Хм... Нет, я не ошибся. Действительно, если 3.5 месяца, то коэффициент уже 0.5.
Не знаю так/не так, но как мне сказали, так я и делаю.
Так что запрос не проходит. Ничего в голову не идёт, да и запарился уже порядком...
Может, всё-таки, возможно одним запросом сделать?

Очень жаль, что Вам не нравится идея честности

Идея хорошая, но меня тут не спрашивают. :-) По идее, если ТС страхуется на период более 3-х месяцев, то считается, что оно страхуется на 4 месяца. Потому и коэффициент такой берётся. Вы меня слегка смутили, я посмотрел закон.
Не нашёл где об этом говорится. Наверное, смотрел плохо. Но делать-то мне, по-любому, придётся, как говорят.

paulus написал:

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

Вот и вопрос. А без этого возможно сделать?

Компьютеры работают по тому алгоритму, которому их научили. Вы можете
научить их врать, но каждое правило вранья надо описывать отдельно. Ну
и в MySQL не предусмотрено варианта быстрого вранья, поэтому прийдется
описывать через IF. Или сделать так, как я сказал раньше, — описать все
вранье в одном модуле, сделать честную табличку, а с честными данными
уже работать быстро

Ну, если вы будете вдаваться в филосософию... С точки зрения диалектического материализма... %-)
Помните анекдот:

Как-то спросил  (после пятой) Чапаев у Фурманова о том что же такое философия.
Отвечает ему Фурманов:
- Ну как бы тебе объяснить, Василий Иваныч... Вот например: два мужика, один чистый, другой грязный, какой в баню пойдёт?
- Ну конечно грязный.
- Эээ, нет, Василий Иваныч.
Вот чему нас учит диалектика: грязный - он как есть по жизни грязный, ему в баню не хочется. А вот чистый - он так и будет к чистоте стремиться, значит он в баню пойдёт
- Надо же.. Вот люди-то умные какие. Так что же такое философия-то?
- Ну вот опять: два мужика, чистый и грязный, какой в баню пойдёт?
- Ну сам же сказал - чистый пойдёт.
- А вот логика нас учит: чистый - он и так чистый, зачем ему в баню? А вот грязному - мыться надо, он в баню пойдёт.
- Ох, и правда, наука, понимаешь. Ну, дальше что?
- Ну вот опять: два мужика, чистый и грязный, какой в баню пойдёт?
- Эх, совсем ты меня запутал. Хрен его знает!
- Вот, Василий Иваныч, вот это и есть - философия!

Даже геометрий совсем "честных" не существует, а вы говорите... ;-)
Что же касается меня. Для меня - это не враньё. Мне это надо сделать.
Поскольку:
1.) Есть люди, которые требуют именно это.
2.) Есть закон, который об этом говорит. Но утверждать я этого не могу, поскольку я не юрист, а сам лично не увидел. :-)

не предусмотрено варианта быстрого вранья, поэтому прийдется
описывать через IF.

IF возможно применять только в хранимых процедурах? :-(

Или сделать так, как я сказал раньше, — описать все
вранье в одном модуле, сделать честную табличку, а с честными данными
уже работать быстро

Вот представьте себе: штук двадцать справочников. Не так много. Но хватает.
Отображаются эти справочники в DBGrid'е. Одна форма на все.
Мне проще сделать через два запроса и функцию, чем для некоторых справочников делать отдельную обработку, а, тем более, интерфейс.
К тому же, времени нет. А лени много. :-)

После того, как они нажали «сохранить», вы делаете
хитрую подпольную операцию: сохраняете эти данные, как есть *и* переписыва-
ете честную табличку так, чтобы по ней можно было делать выборки.

Теоретически, конечно, подход неплохой... Но как я буду делать "хитрую подпольную операцию"?
Во-первых, я не вижу очевидных путей для этого.
Во-вторых, мне сложно самому будет, "вручную" разбираться где какой период.
В-третьих, но самое важное, чтобы делать преобразование нужны ещё какие-то данные.
К примеру, если я поставлю 0, вместо 2-х, откуда я буду знать, что там период 2, а не 1, например? Опять же: надо где-то хранить... Менять структуру таблицы.
А хочется, чтобы таблица максимум соответствовала "бумажной".
В данном случае, это вполне возможно и оправданно (всего-то два столбца).

Я думаю, что лучше так:
1.) Получить коэф. для минимума (ну или максимума).
2.) Получить коэф.
3.) Если NULL, то использовать коэф., полученный в (1).

Причём, есть возможность сделать это на базе процедуры. На скорость выполнения, думаю, это не сильно повлияет.

Ну, в общем, я разобрался.
Спасибо.

P.S.:

- Люди считают, что Вы пишете хорошие быстрые программы, даже если они
внаглую врут во входных данных;

Ага, и кроют меня матом за то, что программа считает себя умнее их. :-\

Отредактированно Артём Н. (03.04.2010 10:47:05)

По крайней мере, возвращает нужный ID. :-\
Мда... Придётся подзапросом, всё равно, делать.
Примерно так:

select KS from ins_koefs_ks where PERIOD_USE = (select ifnull(min(if(PERIOD_USE >= :period), PERIOD_USE, NULL), max(PERIOD_USE))
from ins_koefs_ks);

Отредактированно Артём Н. (03.04.2010 13:20:56)