Nhìn chung, tôi không thấy bất kỳ sai sót lớn nào trong thiết lập hoặc giản đồ hiện tại của bạn.
Điều tôi băn khoăn là việc bạn chia thành 3 bảng Người dùng *. Tôi hiểu những gì bạn muốn ý định của bạn là (có những thứ liên quan đến người dùng khác nhau riêng biệt) nhưng tôi không biết liệu tôi có đi cùng một điều chính xác hay không. Nếu bạn định chỉ hiển thị dữ liệu từ User trên trang web, điều này là tốt, vì thông tin khác không cần thiết nhiều lần trên cùng một trang nhưng nếu người dùng cần sử dụng tên thật và hiển thị tên thật của họ (như John Doe thay vì doe55) thì điều này sẽ làm chậm mọi thứ khi dữ liệu lớn hơn vì bạn có thể yêu cầu liên kết. Có Preferences riêng biệt có vẻ như là một sự lựa chọn cá nhân. Tôi không có lập luận ủng hộ cũng như chống lại nó.
Nhiều bảng của bạn sẽ không cần PK bổ sung (ví dụ:PostFavoriteID ). Một tài khoản chính kết hợp của cả PostID và UserID sẽ là đủ vì PostFavoriteID không bao giờ được sử dụng ở bất kỳ nơi nào khác. Điều này áp dụng cho tất cả các bảng tham gia
Như trước đây. câu trả lời, tôi không thấy một biển quảng cáo hay bất lợi. Tôi có thể đặt cả hai vào cùng một bảng vì NULL (hoặc có thể tốt hơn -1 ) giá trị sẽ không làm phiền tôi.
Tôi sẽ đặt chúng vào cùng một bảng bằng cách sử dụng trình kích hoạt để xử lý số gia tăng của ViewCount bảng
Bạn đang sử dụng một lược đồ chuẩn hóa để có thể thực hiện bất kỳ bổ sung nào bất kỳ lúc nào.
Không thể nói với bạn rằng, vẫn chưa làm được nhưng tôi biết rằng Solr rất mạnh mẽ và linh hoạt, vì vậy tôi nghĩ bạn sẽ làm tốt.
Có nhiều chủ đề ở đây trên SO thảo luận về điều này. Cá nhân tôi thích một khóa thay thế hơn (hoặc một khóa số duy nhất khác nếu có) vì nó giúp truy vấn dễ dàng hơn và nhanh hơn vì số nguyên được tra cứu dễ dàng hơn. Nếu bạn cho phép thay đổi tên người dùng / email / bất cứ điều gì-của-bạn-PK-là, thì cần có các bản cập nhật lớn. Với khóa thay thế, bạn không cần phải bận tâm.
Những gì tôi cũng sẽ làm là thêm những thứ như created_at , last_accessed tại (thực hiện tốt nhất thông qua trình kích hoạt hoặc thủ tục IMO) để có sẵn một số số liệu thống kê. Điều này thực sự có thể cung cấp cho bạn số liệu thống kê có giá trị
Các chiến lược khác để tăng hiệu suất sẽ là những thứ như memcache, bộ đệm truy cập, bảng phân vùng, ... Những thứ như vậy có thể được thảo luận khi bạn thực sự bị người dùng lấn át vì có thể có những thứ / công nghệ / kỹ thuật / ... rất cụ thể vấn đề của bạn.
