笨的会话表结构

我想明白为什么CI的会话表结构有三个主键：session_id，ip_address和user_agent。笨的会话表结构

CREATE TABLE IF NOT EXISTS `ci_sessions` (
     session_id varchar(40) DEFAULT '0' NOT NULL, 
     ip_address varchar(45) DEFAULT '0' NOT NULL, 
     user_agent varchar(120) NOT NULL, 
     last_activity int(10) unsigned DEFAULT 0 NOT NULL, 
     user_data text NOT NULL, 
     PRIMARY KEY (session_id, ip_address, user_agent), 
     KEY `last_activity_idx` (`last_activity`) 
);

请解释一下你可以的最多，我也想听听有关改善这种结构的建议。为什么是ip_address和user_agent primary_keys，而不仅仅是索引？有什么不同？

另一个信息，这张表为每个用户访问系统添加一行，所以它非常臃肿。

编辑：想到另一个问题。为什么我会关心用户代理匹配？

来源

2014-04-25 enapupe

这里的想法是每个会话都是唯一的。它如何识别会话？通过主键中的三个值：session_id,ip_address和user_agent。

如果你仔细想想，这是有道理的：

如果session_id变化，那么（显然），你所面对的是不同的（新）会话。
如果ip_addess发生变化，则有人从另一台PC登录 - 这将是一个新的会话。
如果user_agent值发生变化，那么有人使用不同的浏览器 - 同样，这将是一个新的会话。

所以，想象一下，只有session_id是主键：改变或者ip_address或user_agent只会更新为session_id现有行。如果是这种情况，只要知道session_id就可以让我在另一台PC或不同的浏览器上继续同一会话，这可能是一个安全问题。

你也写过“这个表为每个用户访问系统添加一行，所以它非常臃肿”。我不确定是否每次用户A访问系统时都会添加一行（这在我的应用程序中是错误的，我只是对其进行了测试），或者如果您的意思是每个访问系统的用户都添加一行（这是真的，以及它应该工作的方式 - 每个使用系统的用户都有一个会话）。也许你可以澄清最后的评论。

来源

2014-04-25 14:58:55 Kryten

是的，每个不同的用户都有一个行。另外，他们还有另外一些行是旧的会话数据，这是垃圾收集的，对吗？ – enapupe

所以，如果我决定在我的应用程序中我不匹配IP_ADDRESS，我应该从PK中删除它吗？ – enapupe

因为许多用户有动态的IP地址，经常变化，当你的调制解调器resyncs，重新启动等，这就是为什么我通常不会匹配IP_ADDRESSes会议。这是多少个大网站的做法，对吧？ Facebook，google .. – enapupe

“主键”是一个矛盾。一张桌子永远不可能有多于一个“主键”。正如所写的那样，只有一个主键 - 它只是一个包含3个独立字段的COMPOSITE键。

这意味着

(42, 127.0.0.1, "Chrome") 
(42, 127.0.0.1, "Firefox")

是两个完全不同的会话尽可能CI而言，即使IP和会话ID号是重复的。三元组是独一无二的，但是单个组件可以被复制。

来源

2014-04-25 14:58:46

我已添加编辑提问用户代理。感谢您的回答。 – enapupe

笨的会话表结构

回答

相关问题