2011-09-14 35 views
5

Kịch bản: Thiết kế phòng trò chuyện cho nhiều người dùng khác nhau để trò chuyện cùng một lúc. Tất cả các cuộc trò chuyện cần được lưu. Bất cứ khi nào người dùng đăng nhập, anh ấy sẽ có thể xem tất cả các cuộc trò chuyện trước đó.Thiết kế cơ sở dữ liệu cho phòng trò chuyện. Cần lưu mọi cuộc trò chuyện

Dưới đây là một ví dụ của bảng có thể được sử dụng để lưu trữ các cuộc trò chuyện:

CREATE TABLE chat 
(
    chat_id int NOT NULL auto_increment, 
    posted_on datetime NOT NULL, 
    userid int NOT NULL, 
    message text NOT NULL, 
    PRIMARY KEY (chat_id), 
    FOREIGN KEY(userid) references users(userid) on update cascade on delete cascade 
); 

Đối với lấy cuộc trò chuyện trong theo đúng thứ tự, tôi cần một số khóa chính trong bảng, trong đó tôi đang lưu trữ các cuộc trò chuyện. Vì vậy, nếu tôi sử dụng bảng trên để lưu trữ các cuộc trò chuyện thì tôi không thể lưu trữ nhiều hơn 2147483647 cuộc trò chuyện. Rõ ràng, tôi có thể sử dụng một số kiểu dữ liệu có phạm vi rộng như bigint chưa ký, nhưng nó vẫn sẽ có một số giới hạn.

Nhưng khi kịch bản nói rằng các cuộc trò chuyện được lưu có thể là vô hạn, vậy tôi nên tạo loại bảng nào? Tôi có nên tạo một số khóa chính khác không?

Vui lòng giúp tôi phân loại giải pháp. Tôi tự hỏi làm cách nào Google hoặc facebook quản lý để lưu mọi cuộc trò chuyện.

+1

Có vấn đề gì với bigint? Điều đó mang lại cho bạn phạm vi tối đa 9223372036854775807 trường hợp duy nhất. Nếu bạn có 1 tỷ cuộc trò chuyện mỗi ngày, thì sẽ mất 9 tỷ năm trước khi bạn vượt quá phạm vi đó. – selbie

+0

Nhưng tôi nghĩ rằng có một cái bàn lớn là một nhược điểm. – Paddy

+0

@selbie Ai đó đã nói với tôi khi bảng trở nên quá lớn, chỉ cần đổ dữ liệu của bảng vào một tệp và làm trống bảng và khi dữ liệu đó được yêu cầu, chỉ cần tải dữ liệu từ tệp đó vào bảng. Và đây là cách Google hoặc fb lưu dữ liệu vô hạn. Nhưng tôi không biết nếu đây là soln chính xác hoặc nếu nó là chính xác sau đó làm thế nào chính xác để thực hiện nó. – Paddy

Trả lời

0

Nếu bạn không sử dụng MySQL, khóa chính của id người dùng và dấu thời gian có thể hoạt động tốt. Nhưng dấu thời gian của MySQL chỉ giải quyết được một giây. (Xem bên dưới để biết các thay đổi gần đây ảnh hưởng đến câu trả lời này.) Có một số cách để giải quyết vấn đề đó.

  • Hãy để mã ứng dụng xử lý vi phạm chính bằng cách đợi giây, sau đó gửi lại.
  • Để mã ứng dụng cung cấp dấu thời gian chính xác cao hơn và lưu trữ dưới dạng CHAR có thể sắp xếp (n), như '2011-01-01 03: 45: 46.987'.
  • Chuyển sang một dbms hỗ trợ dấu thời gian micro giây.

Tất cả mã ứng dụng đó cần phải là mã phía máy chủ nếu bạn định viết truy vấn trình bày các hàng được sắp xếp theo dấu thời gian.

Sau

Phiên bản hiện tại của MySQL hỗ trợ fractional seconds in timestamps.

+0

MariaDB 5.3 (vẫn đang trong giai đoạn thử nghiệm) đang hỗ trợ micro giây trong các loại ngày giờ và dấu thời gian: http://kb.askmonty.org/en/microseconds-in-mariadb –

+0

Bắt đầu khóa với giá trị không tuần tự như userid sẽ gây ra dữ liệu được chèn ngẫu nhiên vào bảng tại các điểm khác nhau. Tốt nhất là tuần tự thêm dữ liệu mới vào cuối bảng. Đặc biệt giúp với các chỉ mục. –

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