2013-08-02 25 views
6

Tôi đang tìm một cách hiệu quả để lưu trữ bộ đối tượng đã xảy ra cùng nhau trong các sự kiện, theo cách mà tôi có thể tạo thống kê tổng hợp trên chúng theo từng ngày.Làm thế nào để lưu trữ các bộ đối tượng đã xảy ra cùng nhau trong các sự kiện?

Để tạo một ví dụ, hãy hình dung một hệ thống theo dõi các cuộc họp trong văn phòng. Đối với mỗi cuộc họp, chúng tôi ghi lại số phút và thời gian diễn ra.

Tôi muốn nhận số liệu thống kê được chia nhỏ theo từng người cũng như theo phòng. Tôi không cần phải theo dõi các cuộc họp cá nhân (vì vậy không có meeting_id hoặc bất cứ điều gì như thế), tất cả những gì tôi muốn biết là thông tin tổng hợp hàng ngày. Trong ứng dụng thực sự của tôi có hàng trăm ngàn sự kiện mỗi ngày để lưu trữ từng cá nhân là không khả thi.

Tôi muốn để có thể trả lời những câu hỏi như:

Trong năm 2012, có bao nhiêu phút đã Bob, Sam, và Julie chi tiêu trong từng phòng hội nghị (không nhất thiết với nhau)?

lẽ tốt để làm điều này với 3 truy vấn:

>>> 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} 

Trong năm 2012, có bao nhiêu phút đã Sam và Julie dành gặp gỡ nhau ở mỗi phòng hội nghị? Còn Bob, Sam và Julie thì sao?

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

Trong năm 2012, có bao nhiêu phút đã mỗi người chi tiêu trong Ban-Phòng?

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

Trong năm 2012, có bao nhiêu phút là Ban-Phòng được sử dụng?

Điều này thực sự khá khó khăn vì chiến lược ngây thơ tổng hợp số phút mà mỗi người chi tiêu sẽ dẫn đến việc đếm quá mức nghiêm trọng. Nhưng chúng ta có lẽ có thể giải quyết điều này bằng cách lưu trữ các số riêng biệt như meta-người Bất cứ ai:

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

một số cấu trúc dữ liệu tốt hoặc cơ sở dữ liệu mà tôi có thể sử dụng để cho phép loại truy vấn là gì? Kể từ khi phần còn lại của ứng dụng của tôi sử dụng MySQL, tôi bị cám dỗ để xác định một cột chuỗi chứa id (sắp xếp) của từng người trong buổi làm việc, nhưng kích thước của bảng này sẽ phát triển khá nhanh chóng:

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 

Tôi có thể làm gì nữa?

+1

Vì vậy, để làm rõ, bạn có một bajillion "cuộc họp" xảy ra, vì vậy bạn tổng hợp chúng theo ngày. Điều này có nghĩa là bạn có số phút dành cho ngày giao nhau của người giao nhau trong phòng (hãy gọi R U P U D). Bạn muốn R U (giao lộ P1 P2 giao điểm P3) U D theo cách mà bạn không phải lưu trữ mỗi cuộc họp ... – Temuz

+0

Có chính xác! Nếu chúng ta lưu trữ các session_ids, chúng ta chỉ có thể lấy session_ids UNIQUE và sau đó tìm kiếm thông tin cho từng cái, nhưng đó sẽ là một tấn các bản ghi cho MySQL để tổng hợp. –

+0

Các bộ truy vấn này đã được sửa hay nó có thể thay đổi? Ý tôi là nó có thể giống như tìm mọi lúc khi Julia và Bob không ở trong phòng họp của Borad này. Tôi nghĩ rằng ID cuộc họp không quan trọng lắm ở đây, vì chúng tôi có thể có được cuộc họp độc đáo bằng cách sử dụng kết hợp thời gian và BoardRoom. – AKS

Trả lời

0

Câu hỏi của bạn có một chút không rõ ràng vì bạn nói bạn không muốn lưu trữ từng cuộc họp riêng lẻ, nhưng sau đó bạn nhận được số liệu thống kê cuộc họp hiện tại (ngày) như thế nào? Ngoài ra, bất kỳ bảng nào cho các chỉ mục phù hợp đều có thể rất nhanh ngay cả với nhiều bản ghi.

Bạn sẽ có thể sử dụng bảng như log_meeting.Tôi tưởng tượng nó có thể chứa một cái gì đó như:

employee_id, room_id, date (as timestamp), time_in_meeting 

đâu phím nước ngoài id nhân viên để bàn nhân viên, và phòng chìa khóa id để bàn trong phòng

Nếu bạn id nhân viên chỉ mục, phòng id, và ngày bạn nên có một tra cứu khá nhanh chóng như mysql nhiều cột chỉ mục đi từ trái sang phải để bạn có được chỉ mục trên (id nhân viên, id nhân viên + id phòng, và id nhân viên + phòng id + dấu thời gian) khi thực hiện tìm kiếm. Này được giải thích ở những phần đa chỉ số:

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

0

Bằng cách từ chối để lưu trữ các cuộc họp (và các đối tượng có liên quan) cá nhân, bạn đang mất nguồn gốc của thông tin.

Bạn sẽ không thể bù đắp cho sự mất mát dữ liệu này, trừ khi bạn thường xuyên ghi nhớ danh sách tất cả các tập hợp tiềm năng hàng ngày (hoặc hàng tháng hoặc hàng tuần hoặc ...) mà bạn có thể cần hỏi sau !

Tin tôi đi, nó sẽ trở thành một cơn ác mộng ...

0

Nếu số lượng người là không đổi và không phải là rất lớn sau đó bạn có thể gán một cột cho mỗi người cho hiện tại hay không và lưu trữ phòng, ngày và thời gian trong 3 cột khác, điều này có thể loại bỏ các vấn đề chia tách chuỗi.

Cũng theo bản chất câu hỏi của bạn, tôi cảm thấy trước hết bạn cần phải chỉ định Id cho mọi phòng, con người, v.v. Không cần chuỗi dài lặp đi lặp lại trong DB. Ngoài ra, hãy thử giảm bất kỳ thao tác chuỗi nào và sử dụng dữ liệu riêng lẻ trong mỗi cột để có hiệu suất giao nhau tốt hơn. Ngoài ra, bạn có thể lưu trữ một hoán vị tất cả những người trong một bảng và gán một id cho họ sau đó sử dụng một trong những id đó trong bảng ngày tháng và thời gian thực tế. Nhưng tất cả các kỹ thuật sẽ yêu cầu một cái gì đó không đổi là người hoặc phòng.

0

Tôi không hiểu liệu bạn có biết tất cả "câu hỏi" trong thời gian thiết kế hay có thể thêm các câu hỏi mới trong thời gian phát triển/sản xuất - cách tiếp cận này sẽ yêu cầu giữ tất cả dữ liệu mọi lúc.

Vâng, nếu bạn biết tất cả câu hỏi của mình, nó có vẻ như "hệ thống ngân hàng" cổ điển sẽ tính toán lại dữ liệu hàng ngày.

Tôi nghĩ thế nào về điều đó.

  1. Có vẻ như bạn đã giới hạn số phòng, con người, ngày, vv
  2. Thu thập dữ liệu đăng nhập trên cơ sở hàng ngày, một bảng mỗi ngày. Chỉ một sự kiện, một hàng cơ sở dữ liệu, tất cả thông tin (trường) những gì bạn cần.
  3. Bắt đầu phân tích dữ liệu bằng cách sử dụng một số tập lệnh crone lúc "nửa đêm".
  4. Cập nhật số liệu thống kê cho mọi người, phòng, v.v. Chỉ cần tăng số giờ dành cho Bob trong phòng xyz, v.v. Tất cả những yêu cầu của bạn cần.
  5. Như đã phân tích dữ liệu có giới hạn và tương đối nhỏ như bạn phân tích (nén) họ, hệ thống của bạn có thể chứa cũng truy vấn khác nhau như chỉ số sẽ là tương đối nhỏ vv

Bạn có thể có thể sử dụng bản đồ mở rộng/giảm thuật toán.

0

Bạn không thể tránh lưu trữ các sự kiện nguyên tử như sau: (phòng họp, con người, thời gian, ngày), có thể chỉ là một sự củng cố yếu khi cùng một người gặp nhau nhiều lần trong cùng một phòng trên cùng ngày.Có lẽ điều đó xảy ra rất nhiều trong văn phòng của bạn :).

Làm cho các nhóm có thể so sánh là một vấn đề thú vị, nhưng miễn là bạn luôn soạn các chuỗi thành viên giống nhau, bạn có thể làm điều đó với các so sánh chuỗi. Tuy nhiên, đây không phải là "bình thường". Để bình thường hóa bạn sẽ cần một bảng quan hệ (nhiều đến nhiều) và soạn một bảng tạm thời trong bộ truy vấn của bạn để nó tham gia nhanh chóng hoặc sử dụng mệnh đề "IN" và tổng số để đảm bảo mọi người ở đó (bạn sẽ thấy những gì tôi có nghĩa là khi bạn thử nó).

Tôi nghĩ bạn có thể lấy được số phút mà phòng họp được sử dụng vì các cuộc họp không nên trùng lặp, vì vậy tổng số tiền sẽ hoạt động.

Để tiết kiệm hiệu quả, hãy sử dụng các phím số nguyên cho mọi thứ có bảng tra cứu. Dereference các số nguyên trong quá trình phân tích truy vấn, hoặc chỉ sử dụng các phép nối cũ tốt nếu bạn cảm thấy truyền thống.

Đó là cách tôi sẽ làm điều đó anyway :).

Các vấn đề liên quan