Kỹ thuật thích hợp để lưu trữ dữ liệu sự kiện của người dùng


12

Tôi chủ yếu là một người tự học khi nói đến thiết kế cơ sở dữ liệu. Tôi đang đặt ra câu hỏi này bởi vì tôi đã giải quyết được cấu trúc chung này, nhưng tôi tự hỏi liệu đây là phương pháp hiệu quả nhất hay 'tiêu chuẩn công nghiệp'.

Hầu hết các cơ sở dữ liệu tôi thiết kế đều có bảng người dùng và sau đó hoạt động của một người được theo dõi trong một bảng khác. Tôi hiểu rằng vẻ đẹp của cơ sở dữ liệu là có các loại hiệu quả này, nhưng bảng hoạt động sẽ thu thập nhiều sự kiện khá nhanh chỉ từ mỗi người dùng sử dụng nó thường xuyên, do đó trở thành một bảng lớn khá nhanh với mức độ sử dụng vừa phải của người dùng. Đây có phải là thực hành tốt nhất để chỉ phát triển theo cách này? Hoặc là một lớp các bảng, hoặc chia thành các bảng khác nhau dựa trên ngày, hoặc trên mỗi lượng người dùng, hoặc một cái gì khác?

+--------------------+                   +------------------------+
|   UserData         |                   |   Activity             |
+-=------------------+                   +------------------------+
| ID     (auto uint) | <--1-to-many-+    | ID  (auto uint)        |
| UserName (text)    |              +--> | UserID (uint)          |
| Email    (text)    |                   | Timestamp (time)       |
| additional info... |                   | Type (ID to elsewhere) |
+--------------------+                   | additional info...     | 
                                         +------------------------+

Tôi chỉ muốn biết nơi tôi có thể cải thiện bất cứ điều gì, để giúp tôi học hỏi.

Câu trả lời:


5

Hoặc là một lớp các bảng, hoặc chia thành các bảng khác nhau dựa trên ngày, hoặc trên mỗi lượng người dùng, hoặc một cái gì khác?

Bạn có thể muốn xem xét khái niệm 'phân vùng' trong cơ sở dữ liệu của bạn. Hầu hết các RDBMS đều có một số hỗ trợ cho chúng (ví dụ: mysql , oracle , sql server , postgresql ). Về cơ bản, bạn để RDBMS xử lý quá trình tạo / quản lý thực tế rằng mỗi tháng / năm / bất cứ thứ gì được lưu trữ trong một bảng riêng biệt, trong khi mã truy cập nó coi nó như một bảng lớn.

Bạn có thể phân vùng nó theo tên người dùng, ngày tháng hoặc bất cứ điều gì sẽ được sử dụng thường xuyên nhất để truy cập dữ liệu. (có những ưu điểm / nhược điểm của việc biến nó thành trung tâm người dùng so với centrid ngày ... nhưng tôi không biết liệu bạn có muốn tôi đi sâu vào tất cả điều đó không)


Cảm ơn @Joe, tôi đã đọc nó trên Wikipedia ( en.wikipedia.org/wiki/Partition_%28database%29 ) và một số liên kết bạn đã đăng. Kiểu phân vùng mà bạn muốn nói đến sẽ là phân vùng ngang. Đây là một tính năng mà tôi không biết đã tồn tại cho đến bây giờ. Bây giờ tôi sẽ đặt ra một câu hỏi mới: dba.stackexchange.com/questions/4134/ mà yêu cầu thực hành phân vùng thích hợp.
CenterOrbit

6

Bạn đã thực hiện một quan sát rất tốt. Bảng Activity sẽ phát triển nhanh và lớn. Những gì tôi đã làm trong quá khứ là lưu trữ dữ liệu cũ hơn (giả sử cũ hơn 14 ngày) vào bảng ActivityHistory . Làm như vậy sẽ giữ bảng Activity ở kích thước có thể quản lý được và nếu bạn cần nghiên cứu, bạn luôn có thể nhìn lại bảng ActivityHistory .


1
Tôi thích ý tưởng của bạn và đó là một giải pháp sẽ phù hợp với hầu hết mọi thiết lập cơ sở dữ liệu ngay cả những giải pháp không hỗ trợ giải pháp @Joe. Tuy nhiên, điều này cũng sẽ làm phức tạp một số truy vấn có liên quan nếu bạn cần truy cập dữ liệu lưu trữ cũ hơn và tạo sự cần thiết phải thêm liên kết. Mặc dù rất tốt, tôi đã không nghĩ đến phương pháp này. Cảm ơn bạn.
CenterOrbit

Điều này không nhất thiết phức tạp, bạn có thể chơi với các chuỗi kết nối từ ứng dụng để chọn db lịch sử trong trường hợp dữ liệu cũ hơn .. Hoặc bạn có thể sử dụng các máy chủ được liên kết trong quy trình và trong trường hợp một số datetime cũ hơn x ngày, đi đến máy chủ được liên kết Lưu trữ thay vì máy chủ chính.
Mary

Nó thậm chí còn ít phức tạp hơn nếu bảng ArchiveHistory nằm trong cùng một cơ sở dữ liệu.
Michael Riley - AKA Gunny
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.