Thực tiễn tốt nhất trong việc xây dựng các ứng dụng hỗ trợ nhiều người thuê nhà như Phần mềm dưới dạng Dịch vụ là gì?Các phương pháp hay nhất trong việc xây dựng các ứng dụng nhiều người thuê nhà là gì?
Liên kết tới các giấy tờ trắng mở rộng về chủ đề này được đánh giá cao.
Bạn có thể tìm thấy một số tư vấn có giá trị trong một loạt bài đăng trên blog của Oren Eini.
Đây là một trong những bài viết cuối cùng trong loạt bài này, với các liên kết đến bài viết theo thời gian: http://ayende.com/Blog/archive/2008/08/16/Multi-Tenancy--Approaches-and-Applicability.aspx
Đối với cơ sở dữ liệu:
A. Đặt tất cả mọi thứ trên cơ sở dữ liệu tương tự, đặt một cột tenant_id trên bảng của bạn
Ưu điểm: Dễ dàng để làm
Nhược điểm: Rất dễ bị lỗi: thật dễ dàng để rò rỉ dữ liệu từ người thuê này sang người thuê khác.
B. Đặt tất cả mọi thứ trên cơ sở dữ liệu tương tự, nhưng đưa từng người thuê nhà ở không gian tên riêng của mình (postgresql gọi họ schemas)
Ưu điểm: Cung cấp dữ liệu tốt hơn rò rỉ bảo vệ hơn tùy chọn A
Nhược điểm: Không được hỗ trợ bởi tất cả các cơ sở dữ liệu. AFAIK PostgreSQL và Oracle hỗ trợ nó.
C. Cài đặt một cơ sở dữ liệu cho mỗi người thuê nhà
Ưu điểm: Hoàn toàn không có cơ hội dữ liệu bị rò rỉ từ một người thuê nhà khác
Nhược điểm: Thiết lập người thuê nhà mới là phức tạp hơn. Kết nối cơ sở dữ liệu là tốn kém.
Tôi chỉ học được những ý tưởng ở trên từ Guy Naor. Đây là liên kết đến bản trình bày của anh ấy: http://aac2009.confreaks.com/06-feb-2009-14-30-writing-multi-tenant-applications-in-rails-guy-naor.html
Trong #B, tất cả các lược đồ cơ sở dữ liệu hỗ trợ, nhưng với thuật ngữ khác nhau. Trong MySQL, lược đồ và cơ sở dữ liệu là đồng nghĩa. MSSQL cũng có các lược đồ hỗ trợ ngay bây giờ. Ứng dụng đa nhiệm của chúng tôi trong sản xuất chạy với ~ 4000 (hiện tại) cơ sở dữ liệu/lược đồ trên MySQL. –