如何存儲事件期間一起發生的對象集？

我正在尋找一種有效的方式來存儲事件期間一起發生的對象集合，以這種方式我可以每天在其上生成聚合統計信息。如何存儲事件期間一起發生的對象集？

舉個例子，讓我們想象一個跟蹤辦公室會議的系統。對於每次會議，我們都記錄了多長時間以及它發生在哪個房間。

我希望統計人員和房間的統計數據。我不需要跟蹤個人會議（所以沒有meeting_id或類似的東西），我只想知道每日聚合信息。在我的真實應用程序中，每天有成千上萬的事件，因此單獨存儲每個事件是不可行的。

我希望能夠回答這樣的問題：

在2012年，多少分鐘沒有鮑勃，山姆和朱莉花費在每個會議室（不一定在一起）？

也許還不錯，要做到這一點有3個查詢：

>>> query(dates=2012, people=[Bob]) 
{Board-Room: 35, Auditorium: 279} 
>>> query(dates=2012, people=[Sam]) 
{Board-Room: 790, Auditorium: 277, Broom-Closet: 71} 
>>> query(dates=2012, people=[Julie]) 
{Board-Room: 190, Broom-Closet: 55}

在2012年，沒有薩姆和朱莉多少分鐘花費在每個會議室TOGETHER會議？鮑勃，薩姆和朱莉一起怎麼樣？

>>> query(dates=2012, people=[Sam, Julie]) 
{Board-Room: 128, Broom-Closet: 55} 
>>> query(dates=2012, people=[Bob, Sam, Julie]) 
{Board-Room: 22}

在2012年，多少分鐘沒有每個人在董事會室度過？

>>> query(dates=2012, rooms=[Board-Room]) 
{Bob: 35, Sam: 790, Julie: 190}

在2012年，多少分鐘是董事會室使用？

這實際上很困難，因爲總結每個人花費的分鐘數的天真策略會導致嚴重的重複計算。但是，我們或許可以通過存儲數量分別解決這爲元人任何人：

>>> query(dates=2012, rooms=[Board-Room], people=[Anyone]) 
865

什麼是我可以使用，使這種查詢的一些良好的數據結構或數據庫？由於我的應用程序的其他部分使用MySQL，我很想來定義保存每個人在會議（排序）的ID字符串列，但該表的規模將很快增長：

2012-01-01 | "Bob"   | "Board-Room" | 2 
2012-01-01 | "Julie"   | "Board-Room" | 4 
2012-01-01 | "Sam"   | "Board-Room" | 6 

2012-01-01 | "Bob,Julie"  | "Board-Room" | 2 
2012-01-01 | "Bob,Sam"  | "Board-Room" | 2 
2012-01-01 | "Julie,Sam"  | "Board-Room" | 3 

2012-01-01 | "Bob,Julie,Sam" | "Board-Room" | 2 

2012-01-01 | "Anyone"  | "Board-Room" | 7

我還可以做些什麼？

來源

2013-08-02 Rob Crowell

因此，爲了澄清，你有一個bajillion「會議」發生，所以你在一天之內彙總它們。這意味着你有十分鐘的時間用於房間交叉路口人行天（我們稱之爲R U P U D）。您需要R U（P1路口P2路口P3）U D，您不必存儲每次會議的方式...... – Temuz

是的！如果我們存儲了meeting_ids，我們可以抓住UNIQUE meeting_ids，然後查找每個會議的信息，但這將是MySQL聚合的大量記錄。 –

這些查詢集是固定的還是可以更改的？我的意思是，當Julia和Bob不在這個會議的Borad會議室時，可以找到所有的時間。我認爲會議ID在這裏並不重要，因爲我們可以通過組合時間和BoardRoom獲得獨特的會議。 – AKS

您的問題有點不清楚，因爲您說您不想存儲每個單獨的會議，但是您如何獲取當前的會議統計信息（日期）？另外，即使有很多記錄，任何給定正確索引的表格都可以非常快速。

您應該可以使用像log_meeting這樣的表格。我想它可能包含這樣的內容：

employee_id, room_id, date (as timestamp), time_in_meeting

凡外鍵員工ID員工表和房間ID鑰匙室的桌子

如果指數員工ID，房間ID，和日期，你應該有作爲mysql多列索引左右移動的一個非常快速的查找，以便在搜索時獲得索引（員工ID，員工ID +房間ID和員工ID +房間ID +時間戳）。這是在的多指標解釋部分更多：

http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html

來源

2013-08-06 15:01:30 Shawn

通過拒絕來存儲會議（和相關對象）單獨，你正在失去的原始信息來源。

除非您定期記住所有可能每天（或每月或每週或每月）可能需要質疑的綜合清單的廣泛列表，否則無法彌補數據的丟失！

相信我，這將是一場噩夢......

來源

2013-08-09 14:18:20

如果人數是恆定的，而不是非常大，那麼你可以分配到每個人的存在或不存在一列，存放室，日期和時間在3列以上，這可以消除字符串拆分問題。

而且通過你的問題的性質，我覺得首先你需要分配ID一切的房間，人，等無需在DB長期重複字符串。還可以嘗試減少任何字符串操作，並使用每列中的單個數據來獲得更好的交集性能。你也可以在表中存儲所有人的排列併爲它們分配一個ID，然後在實際的日期和時間表中使用這些ID中的一個。但是，所有的技術都需要人們或房間不變的東西。

來源

2013-08-11 15:55:00 puneet

我不知道你是否知道在設計時的所有「問題」或有可能在開發/生產時間增加新的 - 這種方法需要保持所有數據的所有的時間。

那麼，如果你會知道你所有的問題，這似乎是經典的「銀行系統」，它重新計算每天的基礎上的數據。

如何我想它。

好像你有有限的房間，人，天等
號收集每天的基礎上記錄數據，每天一個表。只需一個事件，一個數據庫行，所有信息（字段）就是你需要的。
開始在「午夜」使用一些crone腳本來分析數據。
人，客房，更新統計等只是增加由鮑勃在某某房間等你的所有要求，需要什麼花了幾個小時數。
作爲分析的數據是有限的和相對較小的爲您分析（壓縮）他們，你的系統還可以包含各種查詢，指標將相對較小等

您可能能夠使用可擴展的map/reduce算法。

來源

2013-08-12 06:37:00

你無法避免存放原子事實如下：（會議室，對人民，持續時間，日），這可能是隻有當同一人相遇在同一個房間裏多次弱勢盤整同一天。也許這在你的辦公室發生很多:)。

製作組可比較是一個有趣的問題，但只要你總是構成成員字符串相同，你可以用字符串比較。但這不是「正常」。爲了規範化，你需要一個關係表（多對多），並從你的查詢集合中構建一個臨時表，以便快速加入，或者使用「IN」子句和計數聚合來確保每個人都在那裏（你會看到我的意思是當你嘗試它時）。

我認爲你可以得出董事會會議室使用的會議記錄，因爲會議不應該重疊，所以一定會有效。

爲了提高存儲效率，使用整數鍵作爲查找表的所有內容。在查詢解析期間解引用整數，或者如果您感覺傳統，則只使用優秀的舊聯接。

這就是我將如何做到這一點:)。

來源

2013-09-04 16:50:26 emperorz

如何存儲事件期間一起發生的對象集？

回答

相關問題