Bạn sẽ ước mình đã sử dụng các cơ sở dữ liệu riêng biệt:
- Nếu bạn muốn tự cấp quyền truy cập cơ sở dữ liệu cho khách hàng hoặc người quản lý cấp trên.
- Nếu bạn chỉ muốn khôi phục cơ sở dữ liệu của một khách hàng mà không ảnh hưởng đến dữ liệu của những khách hàng khác.
- Nếu có những lo ngại về quy định quản lý dữ liệu và vi phạm dữ liệu của bạn và bạn phát hiện ra rằng chỉ có thể đáp ứng những quy định này bằng cách có cơ sở dữ liệu riêng biệt. (Cập nhật:hơn 4 năm sau khi viết câu trả lời này, GDPR có hiệu lực)
- Nếu bạn muốn dễ dàng di chuyển dữ liệu khách hàng của mình sang nhiều máy chủ cơ sở dữ liệu hoặc mở rộng quy mô hoặc chuyển những khách hàng lớn hơn / quan trọng hơn sang phần cứng khác nhau. Ở một nơi khác trên thế giới.
- Nếu bạn muốn dễ dàng lưu trữ và xóa dữ liệu khách hàng cũ.
- Nếu khách hàng của bạn quan tâm đến việc dữ liệu của họ được lưu trữ và họ phát hiện ra rằng bạn đã làm theo cách khác.
- Nếu dữ liệu của bạn bị trát đòi hầu tòa và thật khó để trích xuất dữ liệu của một khách hàng hoặc trát đòi hầu tòa quá rộng và bạn phải tạo toàn bộ cơ sở dữ liệu thay vì chỉ dữ liệu cho một khách hàng.
- Khi bạn quên duy trì cảnh giác và chỉ một truy vấn lướt qua không bao gồm
AND CustomerID = @CustomerID. Gợi ý:sử dụng công cụ quyền theo tập lệnh hoặc lược đồ hoặc bao bọc tất cả các bảng bằng các dạng xem bao gồmWHERE CustomerID = SomeUserReturningFunction()hoặc một số kết hợp của những thứ này. - Khi bạn nhận sai quyền ở cấp ứng dụng và dữ liệu khách hàng bị đưa cho sai khách hàng.
- Khi bạn muốn có các mức bảo vệ sao lưu và khôi phục khác nhau cho các ứng dụng khách khác nhau.
- Một khi bạn nhận ra rằng việc xây dựng cơ sở hạ tầng để tạo, cung cấp, định cấu hình, triển khai và nói cách khác là xoay chuyển lên / xuống cơ sở dữ liệu mới thì đáng đầu tư vì nó buộc bạn phải thành thạo.
- Khi bạn không cho phép khả năng một số lớp người cần quyền truy cập vào dữ liệu của nhiều khách hàng và bạn cần một lớp trừu tượng ở trên
Customerbởi vìWHERE CustomerID = @CustomerIDsẽ không cắt nó bây giờ. - Khi tin tặc nhắm mục tiêu vào các trang web hoặc hệ thống của bạn và bạn đã giúp chúng dễ dàng lấy được tất cả dữ liệu của tất cả khách hàng của bạn chỉ trong một lần, sau khi nhận được thông tin đăng nhập quản trị viên chỉ trong một cơ sở dữ liệu.
- Khi quá trình sao lưu cơ sở dữ liệu của bạn mất 5 giờ để chạy và sau đó không thành công.
- Khi bạn phải tải phiên bản Enterprise của DBMS để bạn có thể tạo các bản sao lưu nén để sao chép tệp sao lưu qua mạng mất ít hơn 5 giờ hơn .
- Khi bạn phải khôi phục toàn bộ cơ sở dữ liệu mỗi ngày vào máy chủ thử nghiệm, mất 5 giờ và chạy các tập lệnh xác thực mất 2 giờ để hoàn thành.
- Khi chỉ một vài khách hàng của bạn cần nhân rộng và bạn phải áp dụng nó cho tất cả khách hàng của mình thay vì chỉ một số ít.
- Khi bạn muốn tiếp cận một khách hàng chính phủ và phát hiện ra rằng họ yêu cầu bạn sử dụng một máy chủ và cơ sở dữ liệu riêng biệt, nhưng hệ sinh thái của bạn được xây dựng xung quanh một máy chủ và cơ sở dữ liệu duy nhất và quá khó hoặc sẽ mất quá nhiều thời gian để thay đổi .
Bạn sẽ rất vui vì đã sử dụng các cơ sở dữ liệu riêng biệt:
- Khi việc triển khai thử nghiệm cho một khách hàng hoàn toàn bùng nổ và 999 khách hàng khác hoàn toàn không bị ảnh hưởng. Và bạn có thể khôi phục từ bản sao lưu để khắc phục sự cố.
- Khi một trong các bản sao lưu cơ sở dữ liệu của bạn không thành công và bạn chỉ có thể khắc phục sự cố đó sau 25 phút thay vì bắt đầu lại toàn bộ quy trình kéo dài 10 giờ.
Bạn sẽ ước mình đã sử dụng một cơ sở dữ liệu duy nhất:
- Khi bạn phát hiện ra một lỗi ảnh hưởng đến tất cả 1000 khách hàng và việc triển khai bản sửa lỗi cho 1000 cơ sở dữ liệu là điều khó khăn.
- Khi bạn nhận sai quyền ở cấp cơ sở dữ liệu và dữ liệu khách hàng bị hiển thị cho sai khách hàng.
- Khi bạn không cho phép khả năng một số lớp người cần quyền truy cập vào một tập hợp con của tất cả các cơ sở dữ liệu (có thể là hai khách hàng hợp nhất).
- Khi bạn không nghĩ rằng việc hợp nhất hai cơ sở dữ liệu khác nhau sẽ khó như thế nào.
- Khi bạn đã hợp nhất hai cơ sở dữ liệu khác nhau và nhận ra rằng một cơ sở dữ liệu là sai và bạn đã không có kế hoạch khôi phục từ trường hợp này.
- Khi bạn cố gắng phát triển 32.767 khách hàng / cơ sở dữ liệu trên một máy chủ duy nhất và phát hiện ra rằng đây là mức tối đa trong SQL Server 2012.
- Khi bạn nhận ra rằng việc quản lý hơn 1.000 cơ sở dữ liệu là một cơn ác mộng lớn hơn bạn từng tưởng tượng.
- Khi bạn nhận ra rằng bạn không thể tiếp cận khách hàng mới chỉ bằng cách thêm một số dữ liệu vào bảng và bạn phải chạy một loạt các tập lệnh phức tạp và đáng sợ để tạo, điền và đặt quyền trên cơ sở dữ liệu mới.
- Khi bạn phải chạy 1000 bản sao lưu cơ sở dữ liệu mỗi ngày, hãy đảm bảo rằng tất cả chúng đều thành công, sao chép chúng qua mạng, khôi phục tất cả chúng vào cơ sở dữ liệu thử nghiệm và chạy các tập lệnh xác thực trên từng bản sao lưu, báo cáo bất kỳ lỗi nào theo cách sẽ đảm bảo được mọi người nhìn thấy và có thể thực hiện dễ dàng và nhanh chóng. Và sau đó 150 lỗi trong số này bị lỗi ở nhiều nơi khác nhau và phải sửa từng lỗi một.
- Khi bạn phát hiện ra, bạn phải thiết lập bản sao cho 1000 cơ sở dữ liệu.
Chỉ vì tôi liệt kê nhiều lý do hơn cho một lý do không có nghĩa là nó tốt hơn.
Một số người đọc có thể nhận được giá trị từ MSDN:Multi -Kiến trúc dữ liệu khách hàng . Hoặc có thể Mẫu thiết kế ứng dụng cho thuê nhà SaaS . Hoặc thậm chí Phát triển nhiều đối tượng thuê Ứng dụng dành cho Đám mây, Phiên bản thứ 3
