Tôi nghĩ rằng cố gắng sao chép thông tin của mỗi sự kiện trong kho dữ liệu sẽ được tối ưu hóa. Nếu bạn muốn mọi thứ thì bạn sẽ kết thúc việc lưu trữ nhiều dữ liệu và tôi nghi ngờ phần lớn dữ liệu sẽ không được sử dụng.
Nếu bạn muốn lưu trữ dữ liệu để phân tích thống kê, tôi khuyên bạn nên quyết định bộ trường tối thiểu nào mà bạn muốn theo dõi và chỉ lưu trữ những trường đó. Một tập hợp các trường hợp lý có thể là: ID sự kiện, tên, thời gian, người tham dự, vị trí, mô tả và số phiên bản nội bộ cho mục đích kế toán. Tăng số phiên bản mỗi khi một trường thay đổi và bạn lưu thông tin trường mới. Để có thêm tín dụng, bạn có thể lưu băm của các trường và không lưu các phiên bản mới khi mã băm của mục nhập được truy xuất gần đây nhất khớp với những gì đã được lưu.
Vì bạn không còn lưu trữ toàn bộ sự kiện trên máy chủ của mình, câu hỏi có hay không truy vấn API trực tiếp khi bạn cần chi tiết sự kiện rõ ràng là "có".
Lịch Google cung cấp thông báo qua email khi sự kiện Lịch được tạo hoặc thay đổi. Nếu bạn quan tâm đến việc người dùng được thông báo về các sự kiện mới xuất hiện trên lịch của họ, điều này có thể dễ dàng được quan tâm bằng cách đặt trường sendNotifications (trong cuộc gọi tới insert a new event) thành true. Chức năng tương tự tồn tại để cập nhật và xóa cuộc gọi trong API (và trong giao diện người dùng Lịch khi người dùng sửa đổi sự kiện).
Phần khó nhất tôi thấy trong triển khai này là quyết định cách ứng dụng của bạn tính toán khi sự kiện thay đổi khi người dùng thực hiện sửa đổi. Nếu tất cả các sự kiện xuất hiện trên một lịch đơn, bạn có thể thăm dò ý kiến của API cho một list of events và sử dụng trường updatedMin với thời gian bạn cuối cùng được truy vấn để cập nhật. Nếu các sự kiện diễn ra trên nhiều lịch, cách tiếp cận này giống nhau, nhưng bạn sẽ cần phải thực hiện một danh sách cho mỗi lịch.
Lưu ý rằng mọi thông tin đăng nhập bạn cung cấp cho ứng dụng của mình sẽ cần phải đọc và ghi vào bất kỳ (các) lịch bạn đang sửa đổi. Là một cách tiếp cận ban đầu, tôi khuyên bạn nên tạo lịch chính cho ứng dụng của bạn được liệt kê là người tham dự trên tất cả các sự kiện bạn đang theo dõi. Sự kiện bạn tạo thay mặt cho người dùng sẽ liệt kê người dùng là người tham dự. Các sự kiện mà người dùng tạo và muốn liên kết với ứng dụng của bạn sẽ cần thêm lịch chính làm người tham dự.Điểm cuối cùng này có thể yêu cầu người dùng quản trị được đào tạo một cách chính xác để tương tác với hệ thống. Thay vào đó là phải có tất cả người dùng ủy quyền truy cập vào lịch của họ cho ứng dụng của bạn, nhưng bạn sẽ phải quản lý nhiều bộ thông tin xác thực và có thể loại bỏ bất kỳ sự kiện nào trên lịch của người dùng mà bạn không quan tâm theo dõi .
Nguồn
2012-05-29 22:37:46
Tôi sẽ sớm bắt đầu vấn đề tương tự nhưng chúng tôi quyết định chỉ tạo sự kiện trong ứng dụng và đẩy các thay đổi ra khỏi lịch và không đọc các thay đổi ngoài lịch để tạo sự kiện trong ứng dụng. – koma
Đây không phải là một lựa chọn cho tôi vì người dùng quản trị muốn tiếp tục sử dụng Lịch Google. Cuối cùng, nó làm cho dự án dễ dàng hơn vì tôi không phải phát triển GUI quản trị cho các nhiệm vụ giống như CRUD trên Sự kiện. – mhenry