Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: выборка из таблицы по вычисляемому значению условия
Форумы портала PHP.SU » PHP » SQL и Архитектура БД » выборка из таблицы по вычисляемому значению условия

Страниц (1): [1]
 

1. DlTA - 08 Ноября, 2010 - 12:20:37 - перейти к сообщению
имеется таблица в которой есть поля
dd mm yyyy (день месяца, месяц и год)
как организовать выборку которая бы выгребала с указанной(1) даты по указанную(2)
может более понятней если скажу, как в sql запросах в условии произвести еще и вычисление
типа:
CODE (SQL):
скопировать код в буфер обмена
  1. WHERE (`dd`*100+`mm`*100+`yyyy`*1000)>($d1*100+$m1*100+$y1*1000) AND (`dd`*100+`mm`*100+`yyyy`*1000)<($d2*100+$m2*100+$y2*1000)
2. vitaliy_mad - 08 Ноября, 2010 - 12:28:37 - перейти к сообщению
вот. объясните, зачем так извращаться??? почему не использовать готовый тип данных дата/время??? тогда это проблема будет решаться гораздо проще, и не надо будет прибегать к куче математических операций???
3. DlTA - 08 Ноября, 2010 - 12:52:04 - перейти к сообщению
я не против что использоватние тогоже dataunix куда удобней и приятней
НО я не пишу проект я его исправляю
4. vitaliy_mad - 08 Ноября, 2010 - 12:55:30 - перейти к сообщению
я бы начал с истправления тапов данных в БД... А если исходить из вашего то надо перевести к "более нормальному" виду:

`secs`+`mins`*60+`hours`+3600+`dd`*86400+`mm`*2592000+`yy`*31104000

что то типа этого и уже с этой комбинацией работать..
5. zardoz - 09 Ноября, 2010 - 22:17:16 - перейти к сообщению
vitaliy_mad пишет:
надо перевести к "более нормальному" виду

Нет у автора ни секунд, ни минут и нет часов. Есть день/мес/год.

DlTA пишет:
`dd`*100+`mm`*100+`yyyy`*1000

Задумка возможно верная, но не с такими коэффициентами. Возьмем 03.01.2010 (3-е января) и 01.02.2010 (1-е февраля), годы считать не будем они одинаковые. Получаем по формуле: 3-е января => 300+100=400; 1-е февраля => 100+200=300. Получается что 3-е января позже чем 1-е февраля (400>300). А это не верно.
Весовые коэффициенты перед днем/месяцем/годом должны однозначно переводить dd в текущий день года (как минимум, можно пропорционально в больший по номеру день).
Т.е. в месяце максимум 31 день, в году максимум 12 мес: `dd`+`mm`*31+`yyyy`*31*12

Но при таком подходе будет жутко медленно работать выборка при большом кол-ве данных. Кроме того, тут ни в каком месте невозм. использовать индексы БД. Индексы по полям `dd`,`mm`,`yyyy` помогут если задать интервал в условии:
CODE (SQL):
скопировать код в буфер обмена
  1.  
  2.       WHERE  (`dd` BETWEEN $d1 AND $d2) AND  (`mm` BETWEEN $m1 AND $m2) AND (`yyyy` BETWEEN $y1 AND $y2)

В этом случае лучше использовать составной индекс по полям `dd`,`mm`,`yyyy`.
Ну или думать об изменении структуры данных...

С уважением.
6. vitaliy_mad - 09 Ноября, 2010 - 22:20:32 - перейти к сообщению
zardoz
zardoz пишет:
Нет у автора ни секунд, ни минут и нет часов. Есть день/мес/год.
это проблема? и делает мой вариант кардинально неверным???
7. zardoz - 09 Ноября, 2010 - 22:50:11 - перейти к сообщению
vitaliy_mad пишет:
это проблема? и делает мой вариант кардинально неверным???

Представьте себе что да. Если бы не было вопроса, то я бы и не заметил в формуле ошибку.
(`hours`+3600 не считаю ошибкой это опечатка).
Посчитайте по вашей формуле результат для полуночи (00ч:00м) 31-го марта и 1 апреля (этого года). Буду признателен если приведете результат.

С уважением.
8. vitaliy_mad - 09 Ноября, 2010 - 23:39:57 - перейти к сообщению
zardoz, если у автора нет цели привязываться к времени, то что мешает их вообще опустить, или выбрать время 12:00:00? это раз. во-вторых данный пример очень вкратце описыват суть требуемых вычислений для правильного формирования интервала в секундах.
И ничто не мешает с таким же еспехом использовать функцию mktime, которая делает все эти вычисления с учетом всех критериев(кол-во дней в месяце, высокосных годов и т.д.) только переводит она в юникстайм. с которым в данном случае проще работать.
9. zardoz - 10 Ноября, 2010 - 00:43:31 - перейти к сообщению
vitaliy_mad, вы посчитали по формуле?
vitaliy_mad пишет:
если у автора нет цели привязываться к времени, то что мешает их вообще опустить

Я уже предлагал время опустить. Улыбка Да дело и не в этом - в вашей формуле ошибка не во времени, а в 1-м дне: каждый 31-й день какого-то месяца будет совпадать с 1-м днем следующего месяца.

С уважением.
P.S. Что-то автора не видно.. Что у него получилось все же..
10. vitaliy_mad - 10 Ноября, 2010 - 00:52:34 - перейти к сообщению
если присмотреться к тому моему посту, то можно увидеть:
vitaliy_mad пишет:
что то типа

Я не спорю эта формула далка от реальности, но она дает понять суть вычислений, ане умножение на 100 каждого из параметров... Смысл той формулы был донести до автора, что надо умножать не на 100.
если по существу: еще раз повторюсь проще сконвертировать один раз все в мускульный тип данных с помощью PHP... иначе с помощью конкатенации слепливать нечто похожее на дату и используя функцию STR_TO_DATE, к примеру, конвертировать полученную строку в тип данных с которым работать...
11. DlTA - 10 Ноября, 2010 - 12:14:55 - перейти к сообщению
прям баталия началась))

я использовал следующий код в запроса
CODE (SQL):
скопировать код в буфер обмена
  1. (`orders`.`dd` + `orders`.`mm`*31 + `orders`.`yy` * 365) > $time1 AND
  2. (`orders`.`dd` + `orders`.`mm`*31 + `orders`.`yy` * 365) < $time2

и все нормально работает в приделах года
а вот на рубеже будут сбои поэтому придется заменить 365 на 372(=12*31)

по поводу скорости обработки: это дело у меня пересчитывает статистику, считает сколько единиц товара купили за период для всех наименований
общее время обработки по всей базе порядка 15 минут
если снять условие по дате то 12+-минут
так что в общем не критично

 

Powered by ExBB FM 1.0 RC1