Kiến trúc phần mềm và thiết kế cơ sở dữ liệu: Một cơ sở dữ liệu/ứng dụng web cho mỗi công ty hoặc một cơ sở dữ liệu/ứng dụng web cho tất cả các công ty?

Question

Tôi đang thiết kế một ứng dụng cơ sở dữ liệu SQL được điều khiển bằng web từ đầu. Ứng dụng sẽ quản lý thông tin cho các khách hàng thuộc cùng một loại ngành. Nói cách khác, thông tin (các thực thể và quan hệ giữa chúng) liên quan đến mỗi khách hàng không thay đổi quá nhiều từ một đến tiếp theo. Tuy nhiên, khối lượng thông tin được quyết định bởi quy mô của công ty. Ứng dụng có thể được lưu trữ trên máy chủ của chúng tôi (s) hoặc bất cứ nơi nào một khách hàng lựa chọn.

câu hỏi đầu tiên của tôi là: ưu và nhược điểm cho các tùy chọn sau là gì:

• A. Quản lý nhiều khách hàng thông tin trong cơ sở dữ liệu tương tự;
• B. Quản lý một thông tin khách hàng trên mỗi cơ sở dữ liệu ; do đó, mỗi khách hàng sẽ có cơ sở dữ liệu riêng của mình ;

Câu hỏi thứ hai của tôi là: những ưu và khuyết điểm được cung cấp các phương pháp triển khai sau là gì?

• A. Mỗi khách hàng có máy chủ (nút) riêng;
• B. Sử dụng (các) ổ đĩa RAID lớn với một máy chủ mạnh mẽ có nhiều trang web;

Khi quyết định cho những lựa chọn này ảnh hưởng đến thiết kế của tôi, tôi muốn biết những ưu điểm và khuyết điểm từ các quan điểm khác nhau bao gồm bảo trì, chi phí (về mặt tài chính và thời gian) và kiến ​​trúc.

Công nghệ sử dụng:

• Cơ sở dữ liệu: MS SQL
• Hệ điều hành: ASP.NET
• Ngôn ngữ: C#

Bất kỳ ý kiến ​​đóng góp đều được chào đón nhất,

Cảm ơn ,

Cullen

Answer 1

Tôi sẽ không khuyên bạn nên cung cấp cho từng khách hàng cơ sở dữ liệu riêng của họ. Tôi dự định làm điều đó cho ứng dụng hiện tại của mình và được nói vào một cơ sở dữ liệu duy nhất. Điều tốt, vì bây giờ chúng ta có 300 khách hàng. Bạn có thể tưởng tượng quản lý 300 cơ sở dữ liệu không? Cập nhật mỗi lần bạn nâng cấp? Đảm bảo từng cập nhật đều được cập nhật, v.v.

Tuyên bố từ chối trách nhiệm: Trong thực tế, chúng tôi thực sự có một số cơ sở dữ liệu. Một vài khách hàng rất lớn có cơ sở dữ liệu riêng của họ và những người khác chia sẻ những cái còn lại. Tôi nghĩ có lẽ 7 cơ sở dữ liệu trong tất cả.

Chúng tôi có cơ sở dữ liệu trên một máy chủ SQL mạnh mẽ. Nếu bạn có nhiều cơ sở dữ liệu và đặt chúng trên các máy chủ khác nhau, bạn sẽ gặp rủi ro rằng một số máy chủ bận rộn hơn các máy chủ khác và các máy khách nhỏ đang sử dụng máy chủ của họ.

Answer 2

Vấn đề lớn là bảo trì và cập nhật ứng dụng. Nếu bạn có nhiều trường hợp chạy, bạn phải duy trì/nâng cấp tất cả các trường hợp này, điều này sẽ trở nên rắc rối hơn nếu chúng nằm ở vị trí địa lý trong các khu vực khác nhau.

Xu hướng chung trong ngành công nghiệp phần mềm doanh nghiệp hiện nay là tập trung ứng dụng của bạn vào máy chủ của riêng bạn và cung cấp phần mềm như dịch vụ cho khách hàng của bạn.

Lý do thực sự duy nhất tôi có thể thấy khi chạy ứng dụng tại trang khách hàng là: nếu nó xử lý thông tin nhạy cảm và công ty có chính sách hạn chế lưu trữ từ xa dữ liệu đó.

Nếu bạn lo ngại về chi phí phần cứng, bạn có thể xem xét các dịch vụ lưu trữ đám mây như Amazon s2, Google App Engine và Microsoft Azure.

Answer 3

Bạn thực sự muốn xem lại sau:

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-design-patterns-multi-tenancy-saas-applications

Đó là một giấy mà đi so với kịch bản thiết kế khác nhau cho một kiến ​​trúc đa người thuê nhà. Có rất nhiều điều cần xem xét từ phân vùng dữ liệu thích hợp, bảo mật và tập kỹ năng.

* được cập nhật bằng liên kết mới

Answer 4

Tôi muốn kết hợp điều này. Thiết kế nó cho khả năng sử dụng cơ sở dữ liệu riêng biệt, nhưng không tách biệt cho đến khi có một lợi ích hiệu suất rõ ràng.

Thiết kế ứng dụng của bạn để nhiều khách hàng có thể tồn tại trong cùng một cơ sở dữ liệu. (tức là xây dựng một lớp tách biệt giữa dữ liệu khách hàng). Sau đó, kế hoạch cho nó tất cả để được trong một cơ sở dữ liệu.

Bằng cách đó, bạn không khai thác triệt để giải pháp của mình để bắt đầu, nhưng nó mang lại cho bạn sự linh hoạt để tách ra các ứng dụng sử dụng rất cao với một cơ sở dữ liệu chuyên dụng. Nếu cơ sở dữ liệu của bạn tồn tại chỉ với một khách hàng trong đó, vậy thì sao? Điều này cũng sẽ tiết kiệm chi phí máy chủ để bạn có thể chắc chắn rằng bạn đang sử dụng phần cứng đầu tư một cách hợp lý trước khi thêm nhiều dung lượng hơn.

Answer 5

Tôi có kinh nghiệm chạy thiết kế một người thuê nhà với khoảng 40 khách hàng. Mỗi máy khách có các tệp ứng dụng ASP.NET riêng biệt và một cơ sở dữ liệu SQL Server. Các tệp nhị phân lõi ứng dụng giống nhau cho mỗi máy khách, nhưng các máy khách cũng có các mô-đun tùy chỉnh.

Tôi khuyên bạn nên thiết kế toàn bộ hệ thống với tư cách là người thuê nhiều người đầu tiên, nhưng vẫn giữ tùy chọn để đi một người thuê nhà nếu cần. Tôi nghĩ rằng lý do chúng tôi đi một người thuê nhà đến từ nhu cầu của khách hàng. Nhiều khách hàng của chúng tôi chạy ứng dụng bên trong mạng nội bộ của họ.

Hoạt động kinh doanh của chúng tôi trở nên rất hướng đến khách hàng, với nhiều tính năng được điều chỉnh theo từng khách hàng cụ thể. Đối với điều này, thiết lập người thuê nhà phù hợp tốt. Nhưng tôi không nghĩ rằng nó có thể quy mô này đến một mức giá thấp hơn đáng kể và một cơ sở khách hàng lớn hơn.

Ưu

• Tốt cho phần mềm doanh nghiệp. Dễ dàng tùy chỉnh, nhưng bạn vẫn nhận được lợi ích từ việc tái sử dụng
• Chúng ta có thể sử dụng một trường hợp SQL Express mỗi máy chủ miễn là mỗi cơ sở dữ liệu là dưới 4GB
• Rất nhiều tách biệt giữa các khách hàng.Ví dụ, mỗi khách hàng có thể có một hồ bơi ứng dụng IIS riêng
• an ninh tại hệ thống cấp hơn, không hoàn toàn mức ứng dụng
• phiên bản phần mềm đơn của khách hàng có thể được đông lạnh trong thời gian dài
• Bugs không thường bề mặt trên tất cả các khách hàng
• Các tính năng mới có thể được phát triển độc đáo dựa trên nhu cầu thực tế của khách hàng. khách hàng đầu tiên cho một tính năng cơ bản beta thử nghiệm

Nhược điểm

• Xấu cho phần mềm của người tiêu dùng. Đừng mong đợi để mở rộng nhiều
• Bảo trì tốn nhiều công sức: cập nhật, sao lưu, gỡ lỗi các vấn đề cụ thể cho từng khách hàng ...
• Kiểm soát chất lượng khó hơn khi các phiên bản hơi khác nhau. Những vấn đề bất ngờ xảy ra sau khi cập nhật

Answer 6

Hiệu suất và vv sang một bên, liệu nó có phục vụ tốt nhất cho khách hàng của bạn để cung cấp cơ sở dữ liệu riêng biệt không? Phần mềm này có thể tồn tại hoặc được sử dụng mà không có công ty của bạn và hoặc giấy phép không?

Ví dụ, các giải pháp thương mại điện tử đơn giản sẽ phải cung cấp cơ sở dữ liệu để nội dung và cơ sở dữ liệu có thể được chuyển từ máy chủ này sang máy chủ khác. Sử dụng phần mềm của bạn mãi mãi giả định rằng công ty của bạn không thành công. Tôi nghi ngờ công ty của tôi sẽ sử dụng một giải pháp như vậy, mặc dù chúng tôi có thể sử dụng một giải pháp lưu trữ nếu chúng tôi biết chúng tôi có thể lưu trữ nó trong nhà vào một ngày sau đó.

An ninh cũng là một mối quan tâm khác. Có một điểm thất bại duy nhất với một cơ sở dữ liệu và nếu một khách hàng bị xâm phạm và mã của bạn có lỗi trong đó, tất cả khách hàng của bạn đều có khả năng bị lộ.

Ứng dụng có bao giờ được tùy chỉnh hay không, và liệu cơ sở dữ liệu đó có gây ra vấn đề gì không?