用户操作历史useroperationhistory表的设计及思路

用户图像需要处理用户操作历史，因此一张合适的操作历史表对处理精度有很大的影响。

表的结构如下

DROP TABLE IF EXISTS `operationhistory`;
CREATE TABLE `operationhistory`  (
  `operationID` int(11) NOT NULL AUTO_INCREMENT COMMENT '操作id',
  `userid` int(11) NOT NULL COMMENT '用户id',
  `articleid` int(11) NOT NULL COMMENT '文章id',
  `operation` int(255) NOT NULL COMMENT '操作说明1为阅读0为喜欢2为不喜欢',
  `time` datetime(0) NOT NULL COMMENT '操作时间',
  PRIMARY KEY (`articleid`, `userid`) USING BTREE,
  INDEX `operation`(`operation`) USING BTREE,
  INDEX `userid`(`userid`) USING BTREE,
  UNIQUE INDEX `operationID`(`operationID`) USING BTREE,
  CONSTRAINT `articleid` FOREIGN KEY (`articleid`) REFERENCES `news` (`ID`) ON DELETE NO ACTION ON UPDATE NO ACTION,
  CONSTRAINT `operation` FOREIGN KEY (`operation`) REFERENCES `operation` (`operationid`) ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `userid` FOREIGN KEY (`userid`) REFERENCES `userinfo` (`ID`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE = InnoDB AUTO_INCREMENT = 29 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

SET FOREIGN_KEY_CHECKS = 1;

 

几点说明：

1.  operationID需要设计，这是一个自动增长的unique键，原因是后续步骤可能会用到这个id。

2. userid，articleid作为外键并成为联合主键，这么做的处理是为了避免出现同一用户对同一文章做出两种不同的操作。例如：

     userid 1 articleid 1 operation 1 已经存在，后来因为userid 1点击了喜欢按钮，往operationhistroy中追加了一条

     userid 1 articleid 1 operation 0，这个影响还不大，但如果又点了一个不喜欢，往operationhistroy中追加了一条

     userid 1 articleid 1 operation 2，这个影响就很大，既喜欢又不喜欢那究竟是喜欢还是不喜欢？

3. 不再使用insert into operationhistory。改用replace into operationhistory。replace 根据联合主键判断是否存在同一用户对同一文章做出不同操作，如果有不同操作则修改为最新的操作。