The Effect of Database Design on Querying
Database designers don’t always use date/time columns appropriately. At the time the database is designed, each date/time column should be identified as to whether it will store both dates and times, dates only, or times only. The designer, by using defaults, constraints, and triggers, can enforce these rules to prevent the accidental storage of data that are either unnecessary or not applicable.
For example, a column in an accounts payable system for the date an invoice is received is unlikely to need the time. In that case, the designer should plan to use the column solely for dates and never store the time component. A trigger could be assigned to prevent the non-integer portion of the date value from being stored when updating or inserting.
Generally, however, the programmer is forced to work with an existing database. In this case, you should examine the way in which the date/time values are being used before you assume the designer did his or her job correctly.
The simplest way to do that is to submit a query using a search condition similar to the following, where DT is the date/time column in question:
Note: The FLOOR function returns the largest integer that is less than or equal to the specified value. In this expression, FLOOR is applied to the floating-point representation of the DT column. This simply strips off the fractional portion of the number.
WHERE CAST(FLOOR(CAST(DT AS float))AS datetime) = 0 OR
DT – CAST(FLOOR(CAST(DT AS float))AS datetime) = 0
The first expression returns the date (integer) portion of the value, while the second returns the time portion. If this query returns no rows, it’s likely that the column has been used consistently to store both dates and times, since the date is never 0 and the time is never 0.
Keep in mind, of course, that if the above query returns rows, it doesn’t necessarily imply that the column has been used inconsistently. If the time happens to be exactly midnight or the date happens to be January 1, 1900, then it’ll show up in the result set. In that case, you can test for columns with time-only or date-only data by using either of these two queries:
WHERE TOnly <> Tonly – (CAST(FLOOR(CAST(TOnly AS float))AS datetime))
WHERE DOnly <> CAST(FLOOR(CAST(DOnly AS float))AS datetime)
Here, TOnly and DOnly are date/time columns that you expect contain only times or dates, respectively. If the query returns rows, then those rows don’t contain the type of data you expected.
Determining what kind of data are stored in the date/time columns of each table is important for intelligent querying. If the columns are used consistently, then your job is easier. However, even if the columns are used inconsistently, you’ll at least know which query pitfalls to watch out for as you code your queries.
Performance Considerations in Querying
A search based on an indexed column completes faster than a search based on a non-indexed column. So date/time columns that are searched frequently should be indexed. Be aware, though, that if you then use a function in the search condition, the index can’t be used in the same way, which slows performance. For searches that are executed thousands of times a day on a production database, this can cause significant performance problems. For this reason, you should avoid using functions in such search conditions whenever possible. As you’ll see in the examples that follow, this sometimes results in solutions that are less flexible than those that use functions.
In addition, keep in mind that some applications require that you search for portions of a date/time column. The portion could be date only, time only, or even a smaller portion, such as a year or hour. In that case, it may improve performance to split a single date/time column into two or more separate columns, and then index those that are searched most often.
How to Search by Date
Frequently. you’ll need to search a date/time column for a specific date, regardless of time. If the data in the column have been used consistently with the time component set to zero, that’s no problem. You just search for the date you’re looking for.
But consider the following table, called DateSample:
ID DateVal
— ———————–
1 2001-02-28 10:00:00.000
2 2002-02-28 13:58:32.823
3 2002-02-29 00:00:00.000
4 2002-02-28 00:00:00.000
As you can see, the DateVal column is used inconsistently. The third and fourth values indicate that the column might have been intended to store dates only, but the first two values indicate that this wasn’t enforced.
As a result, if you use the following query to retrieve rows with the date February 28, 2002:
SELECT * FROM DateSample
WHERE DateVal = ‘2002-02-28’
the result set includes only row 4 instead of both rows 2 and 4. That’s because the date literal is implicitly cast as a datetime value which, in this case, has a zero time component. Since this doesn’t exactly match the value in row 2, that row isn’t returned.
How can you get around the time component? If the query is run often, you should base the search on a range of values, as in:
SELECT * FROM DateSample
WHERE DateVal BETWEEN ‘2002-02-28’ AND ‘2002-02-28 23:59:59.997’
Remember that the BETWEEN clause retrieves values that are equal to the upper and lower limits, so you can’t code the upper limit as just ‘2002-02-29’. If you do, then you’ll incorrectly retrieve row 3. Another way to get the same result is to use comparison operators:
SELECT * FROM DateSample
WHERE DateVal >= ‘2002-02-28’ AND DateVal < ‘2002-02-29’
If the query is run infrequently (to produce a report only once a month, for instance), you can code an expression in the WHERE clause that strips the date/time value of its fractional component. For example, this query:
SELECT * FROM DateSample
WHERE CAST(FLOOR(CAST(DateVal AS float)) AS datetime) = ‘2002-02-28’
returns both rows 2 and 4. In addition, there are many other expressions that you can use to accomplish this same result (my SQL book, Murach’s SQL for SQL Server, covers a couple of others).
By the way, if you wished to retrieve rows with the day February 28, regardless of year, you could code the following query:
SELECT * FROM DateSample
WHERE MONTH(DateVal) = 2 AND DAY(DateVal) = 28
which retrieves rows 1, 2, and 4. Since there isn’t a way to accomplish this without using one or more functions, however, this query shouldn’t be run frequently against a production database. If you need to perform this kind of search on a query that runs often, you should change the design of the database, if possible. Then, you can create a separate, indexed column to store the portion of the date/time value that you need to search.