笨的會話表結構

我想明白爲什麼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

笨的會話表結構

回答

相關問題