เทคนิคที่เหมาะสมสำหรับการจัดเก็บข้อมูลเหตุการณ์ของผู้ใช้


12

ฉันส่วนใหญ่เรียนรู้ด้วยตนเองเมื่อพูดถึงการออกแบบฐานข้อมูล ฉันโพสคำถามนี้เพราะฉันได้ตัดสินในโครงสร้างทั่วไปนี้ แต่ฉันสงสัยว่ามันเป็นวิธีที่มีประสิทธิภาพมากที่สุดหรือ 'มาตรฐานอุตสาหกรรม'

ฐานข้อมูลส่วนใหญ่ที่ฉันออกแบบมีตารางผู้ใช้แล้วมีการติดตามบุคคล activty ในตารางอื่น ฉันเข้าใจว่าความสวยงามของฐานข้อมูลคือการมีประสิทธิภาพเหล่านี้ แต่ตารางกิจกรรมจะรวบรวมเหตุการณ์จำนวนมากอย่างรวดเร็วจากผู้ใช้ทุกคนที่ใช้เป็นประจำอย่างรวดเร็วซึ่งจะกลายเป็นตารางขนาดใหญ่อย่างรวดเร็วด้วยการใช้ผู้ใช้ในระดับปานกลาง นี่เป็นวิธีที่ดีที่สุดที่จะปล่อยให้มันเติบโตในลักษณะนี้หรือไม่? หรือเป็นระดับของตารางหรือแยกไปตามตารางที่แตกต่างกันตามวันที่หรือต่อจำนวนผู้ใช้หรืออย่างอื่น

+--------------------+                   +------------------------+
|   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...     | 
                                         +------------------------+

ฉันแค่อยากจะรู้ว่าฉันสามารถปรับปรุงอะไรได้บ้างเพื่อช่วยให้ฉันเรียนรู้

คำตอบ:


5

หรือเป็นระดับของตารางหรือแยกไปตามตารางที่แตกต่างกันตามวันที่หรือต่อจำนวนผู้ใช้หรืออย่างอื่น

คุณอาจต้องการค้นหาแนวคิดของ 'การแบ่งพาร์ติชัน' ในฐานข้อมูลของคุณ RDBMS ส่วนใหญ่มีการสนับสนุนสำหรับพวกเขา (เช่นmysql , oracle , sql server , postgresql ) โดยพื้นฐานแล้วคุณปล่อยให้ RDBMS จัดการกระบวนการสร้าง / จัดการความจริงที่ว่าแต่ละเดือน / ปี / อะไรก็ตามจะถูกเก็บไว้ในตารางแยกต่างหากในขณะที่รหัสที่เข้าถึงมันจะถือว่าเป็นตารางขนาดใหญ่หนึ่งตาราง

คุณสามารถแบ่งพาร์ทิชันโดยใช้ชื่อผู้ใช้วันที่หรือสิ่งที่จะใช้บ่อยที่สุดในการเข้าถึงข้อมูล (มีข้อดี / ข้อเสียของการทำให้ผู้ใช้เป็นศูนย์กลางเทียบกับวันที่ centrid ... แต่ฉันไม่ทราบว่าคุณต้องการให้ฉันไปทั้งหมด)


ขอบคุณ @Joe ฉันอ่านมันใน Wikipedia ( en.wikipedia.org/wiki/Partition_%28database%29 ) และลิงค์ที่คุณโพสต์ไว้ ประเภทของการแบ่งพาร์ติชั่นที่คุณอ้างถึงคือการแบ่งพาร์ติชันแนวนอน นี่เป็นคุณสมบัติที่ฉันไม่เคยรู้มาก่อนจนกระทั่งตอนนี้ ตอนนี้ฉันจะตั้งคำถามใหม่: dba.stackexchange.com/questions/4134/ซึ่งถามวิธีการแบ่งพาร์ติชันที่เหมาะสม
CenterOrbit

6

คุณสังเกตได้ดีมาก กิจกรรมตารางจะมีการเติบโตอย่างรวดเร็วและมีขนาดใหญ่ สิ่งที่ฉันทำในอดีตคือเก็บถาวรข้อมูลเก่า (พูดมากกว่า 14 วัน) ลงในตารางActivityHistory การทำเช่นนั้นจะทำให้ตารางกิจกรรมมีขนาดที่สามารถจัดการได้และถ้าคุณต้องการทำวิจัยคุณสามารถมองย้อนกลับไปที่ตารางActivityHistoryได้ตลอดเวลา


1
ฉันชอบความคิดของคุณและมันเป็นวิธีการแก้ปัญหาที่จะพอดีกับการตั้งค่าฐานข้อมูลเกือบทุกอย่างแม้แต่สิ่งที่ไม่สนับสนุนโซลูชัน @Joe แต่สิ่งนี้จะทำให้การสืบค้นที่เกี่ยวข้องมีความซับซ้อนหากคุณต้องการเข้าถึงข้อมูลที่เก็บถาวรแบบเก่าและสร้างความจำเป็นในการเพิ่มการเข้าร่วมแบบสหภาพ แม้ว่าจะดีมากฉันไม่ได้คิดถึงวิธีการนี้ ขอบคุณ.
CenterOrbit

ไม่จำเป็นต้องซับซ้อนคุณสามารถเล่นกับสตริงการเชื่อมต่อจากแอพเพื่อเลือก db ประวัติในกรณีที่ข้อมูลเก่า .. หรือคุณสามารถใช้เซิร์ฟเวอร์ที่เชื่อมโยงในขั้นตอนและในกรณีที่ datetime บางรุ่นเก่ากว่า x วันให้ไปที่เซิร์ฟเวอร์ลิงก์ที่เก็บถาวรแทนเซิร์ฟเวอร์หลัก
แมเรียน

มันซับซ้อนน้อยลงถ้าตาราง ArchiveHistory อยู่ในฐานข้อมูลเดียวกัน
Michael Riley - AKA Gunny
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.