Một câu hỏi mà tôi muốn được trả lời là bạn có bao giờ cần xem dữ liệu giữa các đối tác để báo cáo hoặc sử dụng của riêng bạn không? Trong trường hợp này, bạn cần phải đi với số một, nếu không bạn sẽ gặp ác mộng để có được báo cáo tốt.
Bạn sẽ thực hiện bất kỳ tùy chỉnh nào của khách hàng? Điều này cho thấy rằng tách mọi thứ ra có thể là một lựa chọn tốt hơn. Nếu bạn sẽ không bao giờ tùy chỉnh, thì đừng tách ra.
Tôi đã làm việc với các hệ thống trong tất cả các tùy chọn này và lựa chọn đầu tiên cho đến nay là tốt nhất để bảo trì lâu dài. Tuy nhiên, tất cả đều hoàn toàn khả thi nếu bạn sắp xếp và lên kế hoạch tốt. Nếu bạn chọn tùy chọn riêng biệt, bạn phải có thể đẩy các thay đổi cho tất cả các máy khách và do đó phải thực hiện các thay đổi đối với cơ sở dữ liệu thông qua các tập lệnh được giữ trong kiểm soát nguồn. Bạn thậm chí có thể cần phải giữ một điều khiển nguồn theo phiên bản cơ sở dữ liệu, để khách hàng có thể chọn nâng cấp hoặc không. Trong tùy chọn 1 tất nhiên không ai có tùy chọn ở lại phiên bản cũ. Nếu điều đó phù hợp hơn với nhu cầu kinh doanh của bạn, đó là một điểm cộng cho tùy chọn 1.
Tôi rất đồng ý với Ollie Jones, nếu bạn sử dụng tùy chọn một, bạn phải có một thiết kế bảo mật cơ sở dữ liệu tốt để ngăn máy khách nhìn thấy dữ liệu của các máy khách khác. Chúng tôi đã từng di chuyển một ứng dụng khách từ một máy chủ nơi họ là khách hàng duy nhất sang một cơ sở dữ liệu dùng chung và chỉ một proc không yêu cầu client_ID (Nó không cần thiết trong hệ thống cũ và các nhà phát triển đã làm việc cẩu thả) cuối cùng đã gửi email tất cả đại diện bán hàng của tất cả các khách hàng khác với thông tin về khách hàng đầu tiên. Điều này khiến công ty tiêu tốn rất nhiều tiền (cả để khắc phục sự cố, gửi email xin lỗi và kết quả là chúng tôi suýt mất khách hàng và phải chia cho họ một số chi phí để giữ họ) và nhiều lời xin lỗi khó hiểu và nhà phát triển chỉ trong gang tấc lỡ mất việc. Hãy để đây là bài học mà bạn không học được một cách khó khăn.