Как построить оператор SELECT с датами, не учитывающими время?

Question

У меня есть сайт с оператором SELECT, подобным этому:

 SELECT * FROM MyTable WHERE MyDate >= GETDATE()

У меня есть запись со значением 24.06.2009 9:00:00 в поле MyDate.

Когда пользователь посещает эту страницу в период с 24.06.2009 до 9:00:00, эта запись отображается. Но когда пользователь заходит на эту страницу в 24.06.2009, но после 9:00:00 утра, SELECT не получает эту запись.

Как я могу построить этот оператор SELECT вне времени, чтобы эта запись действовала до 24.06.2009 12:00:00?

Спасибо.

Answer 1

Вы действительно имеете в виду 12:00 вечера? Это полдень, а не полночь. Звучит так, будто ты действительно хочешь чего-то большего:

SELECT * 
FROM MyTable 
WHERE cast(floor(cast(MyDate as float))+1 as datetime) > getdate()

Смотрите это:
Как обрезать дату и время в SQL Server?

The

Answer 2

MCardinale, у вас уже есть ответ, но я хотел дать еще один совет.

Будьте уверены, что вы хотите сделать это таким образом. Функции для строк в инструкциях SELECT никогда не масштабируются очень хорошо, так как таблицы базы данных становятся больше (не только в принятом ответе, я имею в виду любая функция на строку). Это потому, что они, как правило, нарушают способность СУБД выбирать правильный план выполнения для максимальной скорости.

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

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

Затем, имея индекс для этого нового столбца, можно выполнять запросы по дате каждой строки, не беспокоясь о производительности функций для каждой строки.

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

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

Конечно, для таблицы потребуется больше места на диске, но я редко видел место на диске в качестве узкого места в СУБД - это почти всегда грубая нагрузка на процессор.

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

Просто пища для размышлений - наслаждайтесь.

Post Scriptum: Если вы действительно храните дату и время в своем поле, вам, вероятно, следует избегать его вызова MyDate. Если это действительно дата, тип столбца неправильный (и мой совет здесь становится спорным). В противном случае его следует переименовать во что-то более наглядное. Администраторы и читатели кода, которые следуют за вами, будут вечно благодарны: -)

Answer 3

Вы можете выполнить арифметику даты в getdate (), чтобы оптимизатор запросов мог использовать любые индексы в MyDate.

SELECT * 
FROM MyTable 
WHERE MyDate >= cast(floor(cast(getdate() as float)) as datetime)