|
|
1
2
就我个人而言,我不会把它放在请求-响应路径中。我将把原始数据记录在一个表中(或者将其推到一个队列中),让后台任务/线程/cron作业处理这个问题。 然后,队列(或消息传递表)应该只包含pageid、userip、sessionid、useragen、ip。 只要后台任务能跟上,绝对时间就不那么重要了。由于现在单个线程将执行繁重的提升操作,因此在更新唯一的页面视图表时,它不会创建冲突的锁。 |
|
2
0
只是一些随机的想法: 我能证明独特的拜访类型背后的想法是:
对于原始性能,您可能认为2是冗余的,因为3将 可能 cover 2 i大多数情况(或是2重要,例如,如果用户随后注册,然后2可以映射到1)?(意味着会话ID可能仍然被记录,但不会用于任何访问确定) imho ip将始终存在(即使是欺骗的),并且将是索引的一个很好的候选者。用户代理可以隐藏,并且只有有限的范围(不是非常可选)。 由于可以为空的字段,并且这些字段本身都不是唯一的,所以在这个实例中我将使用代理主键。 imho您关于存储所有访问,然后通过成批输出来修剪重复项的想法是一个很好的权衡方法(而不是检查是否存在以更新或插入新的访问)。
|
|
|
developer · 带外键的SQL表设计 1 年前 |
|
|
relatively_random · 确保两个表之间一致的共同参考 1 年前 |
|
|
b126 · 在两种不同的Oracle模式上执行相同查询的速度差异很大 2 年前 |
|
|
robertspierre · 在多对多关系中自动删除未引用的行 2 年前 |
|
|
Michael Samuel · MYSQL在以下情况下自动创建索引 8 年前 |