我继承了一个跟踪与时间相关的温度数据的系统。我曾经问过一个关于它的问题:(将温度值集合存储到 MYSQL 中最有效的方法是什么?)
系统有一个单独的表格,用于跟踪日期(如下所示)。它包含当天的几个描述符列。我对这种结构提供的好处犹豫不决,因为它似乎增加了额外的重量来做一些日期函数和数学可以做的事情。
系统的创建者告诉我,最好通过将 DATE_ID 与运算符一起使用而不是日期函数来选择数据范围。
例如:假设您要收集从 2012 年 6 月 1 日到 2012 年底的所有温度信息,您可以执行以下操作。
1) 获取对应于 2012 年 6 月 1 日的日期 ID。假设 id 是 23000
2) 使用以下方法获取对应于年末的日期 ID:
SELECT DATE_ID FROM DATE_REPRESENTATION WHERE DATE_ID >= 23000 AND END_YEAR_FLAG = 1 AND LIMIT 1;
假设一个是 23213
3) 现在我们将有 2 个 DATE_ID,我们可以像这样使用它们:
SELECT * FROM temperature_readings WHERE DATE_ID BETWEEN 23000 AND 23213;
我觉得正确索引“temperature_readings”表并使用日期函数可能会更好。例如:
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))
在提高整体性能方面,是否有比目前使用的更好的解决方案?在上一个问题中,我提到系统使用数据根据日期范围(每天、每周、每月、每年或用户可以指定的范围)选择的数据生成图表和警报。
当前表:
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;