Tôi có nên sử dụng một cơ sở dữ liệu cho mỗi ứng dụng hay chia sẻ một cơ sở dữ liệu giữa nhiều ứng dụng [đã đóng]

Tôi có nhiều ứng dụng một số sử dụng dữ liệu từ cùng một nguồn. Đây có phải là cách thực hành tốt nhất (hoặc những ưu / nhược điểm) đối với:

• để lại dữ liệu trong cơ sở dữ liệu được chia sẻ bởi nhiều ứng dụng

  1. tiết kiệm không gian vì chỉ cần một cơ sở dữ liệu
  2. làm phức tạp việc lập chỉ mục vì các ứng dụng khác nhau có nhu cầu truy vấn khác nhau

• nhập dữ liệu hàng ngày vào cơ sở dữ liệu trên mỗi ứng dụng

  1. sử dụng nhiều không gian hơn khi dữ liệu trùng lặp tồn tại trong cơ sở dữ liệu trên mỗi ứng dụng
  2. lập chỉ mục dễ dàng hơn vì mỗi ứng dụng có thể tập trung vào nhu cầu cá nhân của nó

Tôi có thể đã bỏ qua những lợi thế / bất lợi khác, xin vui lòng liệt kê nếu có, làm thế nào điều này được thực hiện tại nơi làm việc của bạn?

Dung lượng rẻ trong những ngày này, vì vậy tôi khuyên bạn nên sử dụng một cơ sở dữ liệu cho mỗi ứng dụng.

Chia sẻ một cơ sở dữ liệu cho nhiều ứng dụng có một số nhược điểm nghiêm trọng :

• Càng nhiều ứng dụng sử dụng cùng một cơ sở dữ liệu, bạn càng có nhiều khả năng gặp phải các tắc nghẽn về hiệu suất và bạn không thể dễ dàng mở rộng quy mô tải như mong muốn . Cơ sở dữ liệu SQL không thực sự mở rộng quy mô. Bạn có thể mua các máy lớn hơn nhưng chúng không có quy mô tốt trong các cụm!

• Chi phí bảo trì và phát triển có thể tăng : Phát triển khó hơn nếu một ứng dụng cần sử dụng các cấu trúc cơ sở dữ liệu không phù hợp với nhiệm vụ trong tay nhưng phải được sử dụng khi chúng đã có sẵn. Cũng có khả năng các điều chỉnh của một ứng dụng sẽ có tác dụng phụ trên các ứng dụng khác ("tại sao lại có một trình kích hoạt không cần thiết như vậy ??!" / "Chúng tôi không cần dữ liệu đó nữa!"). Thật khó khăn với một cơ sở dữ liệu cho một ứng dụng, khi các nhà phát triển không / không thể biết tất cả các trường hợp sử dụng.

• Quản trị trở nên khó hơn: Đối tượng nào thuộc về ứng dụng nào? Sự hỗn loạn gia tăng. Tôi phải tìm dữ liệu của mình ở đâu? Người dùng nào được phép tương tác với đối tượng nào? Tôi có thể cấp cho ai?

• Nâng cấp: Bạn sẽ cần một phiên bản là mẫu số chung thấp nhất cho tất cả các ứng dụng sử dụng nó. Điều đó có nghĩa là một số ứng dụng nhất định sẽ không thể sử dụng các tính năng mạnh mẽ. Bạn sẽ phải gắn bó với các phiên bản cũ hơn. Nó cũng làm tăng chi phí phát triển một chút.

• Đồng thời: Bạn có thể thực sự chắc chắn rằng không có sự phụ thuộc theo thời gian giữa các quy trình không? Điều gì xảy ra nếu một ứng dụng sửa đổi dữ liệu đã lỗi thời hoặc trước tiên phải được thay đổi bởi một ứng dụng khác? Điều gì về các ứng dụng khác nhau làm việc trên cùng một bảng đồng thời?

So với điều đó, quá trình nhập dữ liệu / quy trình ETL hầu như luôn luôn khá đơn giản và đơn giản. Tải dữ liệu thường xuyên như bạn cần, không gian là rẻ. Bạn có thể tính toán khả năng mở rộng cho từng ứng dụng một cách độc lập, điều chỉnh và điều chỉnh các cấu trúc khi bạn cần và sẽ không có vấn đề tương tranh. Tác dụng phụ có thể được truy tìm dễ dàng hơn nhiều, quá.

Chỉnh sửa: Tuy nhiên, tôi muốn chỉ ra rằng, như @Saeed đã đề cập, nếu bạn có thể gói gọn các thao tác dữ liệu trong một dịch vụ thường có sẵn, thì việc chia sẻ một cơ sở dữ liệu với nhiều ứng dụng sẽ dễ dàng hơn. Miễn là bạn không cần truy cập thô đó là một cách tiếp cận rất tốt.

Tôi đã có một tình huống tương tự một lần. Vấn đề của tôi là xây dựng 3 ứng dụng, một cho quản lý hàng tồn kho, một cho quản lý mua sắm và một cho quản lý người dùng, tức là nhân viên. Đề nghị của tôi là không phá vỡ cơ sở dữ liệu vật lý trên mỗi ứng dụng hoặc tham gia chúng trên mỗi ứng dụng. Thay vào đó, phân tách logic IMHO hoạt động tốt hơn.

Ví dụ, cả 3 ứng dụng cần thiết để làm việc với thông tin nhân viên. Cả hệ thống kiểm kê và mua sắm đều sử dụng cùng một thông tin về hàng hóa và hàng tồn kho.

Tôi đã tạo một cơ sở dữ liệu dùng chung, trong đó tôi lưu trữ thông tin của người dùng và hàng hóa. Sau đó, tôi xây dựng một lớp dịch vụ trên nó và tôi đã sử dụng các dịch vụ đó trong các ứng dụng khác. Để hiển thị một danh sách tất cả các nhân viên hiện đang ở trong công ty, tôi chỉ cần gọi một phương thức từ dịch vụ như thế nào GetOnWorkEmployees().

Tôi cũng đã tạo một giao diện người dùng chung để tương tác với người dùng và hàng hóa là một ứng dụng web riêng biệt.

Vì vậy, thêm vào những gì @Falcon đã chỉ ra, tôi nghĩ rằng bạn có thể hưởng lợi từ việc tập trung chức năng chung giữa các ứng dụng trong một cơ sở dữ liệu.

Nếu các ứng dụng này hoạt động từ cùng một dữ liệu - ví dụ, cùng một danh sách các sản phẩm và khách hàng - thì hãy giữ cơ sở dữ liệu cùng nhau. Bạn không đạt được bất cứ điều gì bằng cách tách biệt cơ sở dữ liệu. Đó hoàn toàn là vấn đề 'con người' - với máy chủ chỉ là byte trên đĩa. Nó không quan tâm nếu cơ sở dữ liệu 1 hoặc 100 của nó. Nhưng nếu bạn tách nó ra, thì bạn phải xử lý đồng bộ hóa dữ liệu. Các vấn đề về lập chỉ mục mà bạn đưa ra không phải là vấn đề thực sự - bạn sẽ sử dụng cùng thời gian xử lý để duy trì các chỉ mục nếu các db bị chia tách.

Nếu hiệu suất bắt đầu trở thành một vấn đề, hãy sao chép db vào nhiều máy chủ để cân bằng mọi thứ.

Nó có thể hoặc không đáng để đánh đổi trong tình huống của bạn, nhưng việc duy trì tính toàn vẹn dữ liệu dễ dàng hơn với một cơ sở dữ liệu. Trong MS SQL Server ít nhất, bạn không thể khóa ngoại từ một cơ sở dữ liệu vào một cơ sở dữ liệu khác. Bạn có thể mô phỏng hành vi khóa ngoại với các kích hoạt, nhưng nó không đặc biệt thanh lịch.

Ngoài ra, việc tạo các bản sao cục bộ của dữ liệu có thể gây nguy hiểm khi ghi vào hoạt động. Nếu cả AppA và AppB đều có một bản sao của một số dữ liệu được chia sẻ và AppA cập nhật nó, AppB sẽ vẫn có dữ liệu cũ. Hoặc, bạn sẽ phải thiết lập kích hoạt để giữ dữ liệu đồng bộ.

Khi tôi đã có nhiều trang web phổ biến theo thời gian. Họ đã sử dụng các cơ sở dữ liệu riêng biệt, chủ yếu là do nhà cung cấp dịch vụ lưu trữ chỉ cho phép không gian lưu trữ 1Gb. Nhưng! Ngay khi tôi phát hành một dịch vụ bao gồm tất cả các trang web này, tôi bắt đầu phải thực hiện các giao dịch giữa các trang web này và cách thuận tiện nhất để thực hiện điều này là chuyển tất cả mọi thứ vào một cơ sở dữ liệu lớn.

Vì vậy, tôi đã tối ưu hóa cấu trúc cơ sở dữ liệu và vắt các phần có liên quan vào cơ sở dữ liệu trung tâm này, nhưng bỏ qua mọi thứ khác.

Ý kiến ​​của tôi bằng cách nào đó liên quan đến các mô hình của OOP. Dữ liệu tương tự phải được lưu trữ cùng nhau, vì vậy nếu bạn xây dựng các ứng dụng khác nhau, bạn nên sử dụng các cơ sở dữ liệu khác nhau cho chúng.

Trong trường hợp trên, không thể tránh sử dụng db chung, nhưng hãy nhớ rằng tôi cũng tách một số bảng trong một db riêng biệt, đó không phải là một phần của các truy vấn phổ biến.

Hơn nữa, nếu bạn giữ chúng tách biệt, chúng sẽ dễ dàng sao lưu hơn, sẽ có ít cơ hội mất dữ liệu hơn. Nếu có sự cố xảy ra và các ứng dụng can thiệp lẫn nhau, cơ sở dữ liệu sẽ bị rối và về cơ bản bạn không muốn để ứng dụng của mình gặp nguy hiểm này.

Nói chung, bạn có thể duy trì một cơ sở dữ liệu chung cho các truy vấn chung, nhưng cũng có thể giữ một cơ sở dữ liệu cho mỗi ứng dụng của bạn.

Bạn có thể giải thích thêm về kiến ​​trúc ứng dụng của bạn?

Nếu cơ sở dữ liệu của bạn hoạt động giống như một kho lưu trữ dữ liệu mà không có logic ứng dụng như mã kích hoạt hoặc mã gói doanh nghiệp, tốt hơn là nên có một cơ sở dữ liệu duy nhất và đóng gói chức năng cấp doanh nghiệp cho các dịch vụ sử dụng cơ sở dữ liệu cho tất cả các hành động của chúng. Nếu bạn có các trình kích hoạt hoặc mã trong lược đồ cơ sở dữ liệu, bạn sẽ gặp rắc rối lớn bằng cách sử dụng một cơ sở dữ liệu duy nhất có thể gây rắc rối trong nhiều trường hợp.