Would using a table with preprocessed date conditions improve efficiency? - mysql

Question

I inherited a system that keeps track of temperature data related to time. I had asked a previous question about it: (What is the most efficient way to store a collection of temperature values into MYSQL?)
The system has a separate table which is used to keep track of dates (shown below). It contains several descriptor columns of the current day. I am hesitant of the benefits this kind of structure provides, as it seems to add extra weight to do the same thing a few date functions and math can do.
I was told by the creator of the system that it is better to select a range of data by using the DATE_ID with operators instead of a date function.
For example: Let's say you want to collect all temperature information from June 1st, 2012 till the end of 2012, you could do the following.
1) Get the date ID that corresponds to June 1st, 2012. Lets say the id was 23000
2) Get the date ID that corresponds to the end of the year by using something like:
SELECT DATE_ID FROM DATE_REPRESENTATION WHERE DATE_ID >= 23000 AND END_YEAR_FLAG = 1 AND LIMIT 1;
Lets say that one was 23213
3) Now we would have 2 DATE_IDs, which we could just use like so:
SELECT * FROM temperature_readings WHERE DATE_ID BETWEEN 23000 AND 23213;
I feel that it might be better to properly index the 'temperature_readings' table and use date functions. For example:
SELECT ...... actual_date BETWEEN DATE('2012-06-01') AND LAST_DAY(DATE_ADD(DATE('2012-06-01'), INTERVAL (12 - MONTH(DATE('2012-06-01'))) MONTH))
Is there a better solution than what is currently in use in terms of improving the overall performance? In the previous question, I mention that the system uses the data to produce graphs and alerts based on the data selected by date ranges (daily,weekly, monthly, yearly, or a range that a user can specify).
Current table:
CREATE TABLE `DATE_REPRESENTATION` (
`DATE_ID` int(10) NOT NULL,
`DAY_DATE` timestamp NULL DEFAULT NULL,
`DATE_DESC_LONG` varchar(18) DEFAULT NULL,
`MB_DATE_M_D_YYYY` varchar(18) DEFAULT NULL,
`WEEKDAY` varchar(9) DEFAULT NULL,
`WEEKDAY_ABBREV` char(4) DEFAULT NULL,
`WEEKDAY_NUM` decimal(1,0) DEFAULT NULL,
`WEEK` char(13) DEFAULT NULL,
`WEEK_NUM` decimal(4,0) DEFAULT NULL,
`WEEK_NUM_ABS` decimal(4,0) DEFAULT NULL,
`MONTH_LONG` varchar(9) DEFAULT NULL,
`MONTH_ABBREV` char(3) DEFAULT NULL,
`MONTH_NUM` decimal(2,0) DEFAULT NULL,
`MONTH_NUM_ABS` decimal(5,0) DEFAULT NULL,
`QUARTER` char(1) DEFAULT NULL,
`QUARTER_NUM` decimal(1,0) DEFAULT NULL,
`QUARTER_NUM_ABS` decimal(5,0) DEFAULT NULL,
`YEAR4` decimal(4,0) DEFAULT NULL,
`BEG_WEEK_FLAG` decimal(1,0) DEFAULT NULL,
`END_WEEK_FLAG` decimal(1,0) DEFAULT NULL,
`BEG_MONTH_FLAG` decimal(1,0) DEFAULT NULL,
`END_MONTH_FLAG` decimal(1,0) DEFAULT NULL,
`BEG_QUARTER_FLAG` decimal(1,0) DEFAULT NULL,
`END_QUARTER_FLAG` decimal(1,0) DEFAULT NULL,
`BEG_YEAR_FLAG` decimal(1,0) DEFAULT NULL,
`END_YEAR_FLAG` decimal(1,0) DEFAULT NULL,
PRIMARY KEY (`DATE_ID`),
UNIQUE KEY `DATEID_PK` (`DATE_ID`),
KEY `timeStampky` (`DAY_DATE`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Answer 1

A DATE should be stored internally as just a number, so the only thing I can imagine is that the old person used to store dates as CHAR and suffered for it :)
When MySQL calculates the BETWEEN values, it will do that once, so there will be little math to be done. Add in the standard optimizations (preparing, parameterizing, indexing, etc), and you should be fine.
The formulas might be a little illegible. Maybe you could wrap them in a stored procedure, so you could call GET_LAST_DAY_OF_QUARTER(date) instead of putting all the date math in the SELECT.