Cơ sở dữ liệu đơn lẻ hoặc riêng biệt cho các tài khoản khách hàng riêng biệt?

Question

Tôi đang làm việc trên một ứng dụng thu thập dữ liệu từ các thẻ thông minh. Tôi muốn có thể chạy ứng dụng dưới dạng dịch vụ web cho nhiều tài khoản khách hàng. Câu hỏi đặt ra là, tôi có nên tạo một cơ sở dữ liệu riêng biệt cho mỗi tài khoản hay tôi nên thiết kế một cơ sở dữ liệu duy nhất chứa tất cả dữ liệu của tài khoản? Đầu tiên, tôi nghĩ rằng một cơ sở dữ liệu duy nhất là câu trả lời rõ ràng, nhưng kết quả là AccountID phải được sử dụng ở mọi nơi, trong bảng, chỉ mục, ràng buộc, truy vấn, kiểm tra, v.v.

Trong ứng dụng này, không có một byte dữ liệu được chia sẻ giữa các tài khoản.

Đầu tiên, chúng ta hãy nhìn vào một cơ sở dữ liệu riêng biệt cho một tài khoản sẽ trông như thế nào:

CREATE TABLE CardHolder ( 
    CardHolderID int, -- primary key 
    CardHolderUniqueName nvarchar(30)); 

CREATE TABLE SmartCard (
    SmartCardID int, -- primary key 
    CardHolderID int, 
    CardUniqueName nvarchar(30)); 

Thêm vào đó một vài ràng buộc duy nhất,

ALTER TABLE CardHolder ADD CONSTRAINT UQ_CardHolderName UNIQUE (CardHolderUniqueName); 
ALTER TABLE SmartCard ADD CONSTRAINT UQ_CardName UNIQUE (CardUniqueName); 

Bây giờ, nếu tôi đặt tất cả mọi thứ trong một cơ sở dữ liệu , nó có nghĩa là một số tài khoản có thể xử lý cùng một CardHolders và SmartCards, nhưng các tài khoản sẽ không nhìn thấy dữ liệu của nhau. Bởi vì điều này, một SmartCard là duy nhất trong một tài khoản, nhưng không phải trong toàn bộ cơ sở dữ liệu. Vì vậy, mỗi chế phải bao gồm một AccountID,

CREATE TABLE CardHolder ( 
    CardHolderID int, -- primary key 
    CardHolderUniqueName nvarchar(30), 
    AccountID int); 

CREATE TABLE SmartCard (
    SmartCardID int, -- primary key 
    CardHolderID int, 
    CardUniqueName nvarchar(30) 
    AccountID int); 

ALTER TABLE CardHolder 
    ADD CONSTRAINT UQ_CardHolderName UNIQUE (AccountID, CardHolderUniqueName); 
ALTER TABLE SmartCard 
    ADD CONSTRAINT UQ_CardName UNIQUE (AccountID, CardUniqueName); 

Trong DB thực tế, sẽ có vô số bảng hơn, cột và một số chỉ số (niêm yết bởi expirydate etc etc) và cột AccountID phải được bao gồm ở khắp mọi nơi .

Dường như một chút lộn xộn với tôi, trước tiên đặt tất cả các tài khoản vào một cơ sở dữ liệu, sau đó tách chúng bằng cột AccountID trong mỗi bảng và chỉ về mọi ràng buộc và chỉ mục. Tôi cũng cần tìm hoặc phát minh một số loại bảo mật mức hàng để giữ cho người dùng truy cập dữ liệu của các tài khoản khác. Vì vậy, tôi có một lý do hợp lệ để tạo ra một cơ sở dữ liệu riêng biệt cho mỗi tài khoản, hoặc làm "nhà thiết kế db thực" luôn giữ mọi thứ trong một cơ sở dữ liệu duy nhất?

Answer 1

Có một số điều cần lưu ý khi thiết kế ứng dụng nhiều bên thuê, bao gồm, như trạng thái câu hỏi của bạn, thiết kế lược đồ, nhưng những thứ như chi phí giấy phép, khả năng mở rộng, v.v. This article describes the three most common approaches for designing a multi-tenant application, bao gồm ưu và nhược điểm. Kiểm tra nó ra.

Answer 2

IMHO chỉ có một cách. Nhiều cơ sở dữ liệu.

1. Không chỉ dữ liệu hoàn toàn an toàn này mà không bao giờ được chia sẻ
2. Nó cũng cho phép các lược đồ để thay đổi độc lập với nhau. Bởi điều đó tôi ngụ ý rằng theo thời gian, có thể một người thuê nhà lớn hơn tất cả những người cai trị khác, và do đó nhu cầu đặc biệt phải được phục vụ.
3. Sao lưu, phục hồi các hoạt động và chiến lược có thể dễ dàng được xây dựng cho cơ sở dữ liệu độc lập
4. hạn chế và độc đáo được dễ dàng hơn và tự nhiên hơn bày tỏ

Answer 3

Chúng tôi đã đi xuống cả các tuyến đường ở đây. Chúng tôi có cơ sở dữ liệu được chia sẻ cho các khách hàng nhỏ hơn, những người không cần tùy chỉnh và cơ sở dữ liệu riêng (và mã cơ sở ứng dụng cho vấn đề đó) cho các khách hàng Enterprise làm việc.

Cả hai đều có điểm cộng và nhược điểm của chúng. Trong cơ sở dữ liệu được chia sẻ, tất cả những gì nó cần là một truy vấn không hợp lệ khi một người nào đó quên sử dụng clientid và dữ liệu được tiếp xúc với các máy khách khác.Trong năm năm, tôi đã thấy điều này xảy ra chỉ một lần nhưng đó là một cơn ác mộng lớn mà chi phí cho chúng tôi một khách hàng. Nếu bạn đi tuyến đường này, hãy đảm bảo bạn có nhóm QA tốt để kiểm tra chính xác điều đó trước khi phát hành mã cho sản phẩm. Nếu cơ sở dữ liệu của bạn có lược đồ, bạn có thể sử dụng các khung nhìn trong lược đồ để ngăn chặn truy cập dữ liệu của dữ liệu khách hàng khác. Nếu khách hàng chỉ có quyền đối với quan điểm của họ thì họ không thể xem dữ liệu của bất kỳ ai khác. Đây là công việc nhiều hơn để thiết lập mặc dù.

Nhưng cơ sở dữ liệu riêng biệt có thể trở thành cơn ác mộng để thực hiện thay đổi bảo trì. Tuy nhiên, nếu bạn bán nâng cấp của bạn, đây là cách để đi vì không phải mọi khách hàng sẽ mua từng nâng cấp. Chỉ cần đảm bảo bạn có cơ chế theo dõi tốt để biết phiên bản nào của từng khách hàng và bạn sử dụng kiểm soát nguồn để theo dõi tất cả các thay đổi của cơ sở dữ liệu theo phiên bản, để bạn có thể dễ dàng nâng cấp.

Nếu bạn không có ý định có tùy chỉnh, bạn có thể thấy rằng các datbases riêng biệt dẫn theo hướng đó. Nó dễ dàng hơn nhiều để nói với họ không khi họ là một cơ sở dữ liệu được chia sẻ. Hơn nữa, chúng tôi nhận thấy rằng có các tùy chỉnh hữu ích cho các khách hàng khác nhưng vì chúng được phát triển trong một ứng dụng và cơ sở dữ liệu riêng biệt, chúng được tái phát triển bởi một nhóm khác cho một khách hàng khác và bạn kết thúc bằng 6 cách để làm điều tương tự. Điều này sau đó trở thành một nỗi đau lớn cho những người làm việc trên các khách hàng như những người nhập dữ liệu khách hàng vào cơ sở dữ liệu. Cá nhân tôi thích cách tiếp cận cơ sở dữ liệu một.

Một điểm khác liên quan đến sự cần thiết phải củng cố hoặc tách biệt các mối quan tâm báo cáo về dữ liệu. Nếu báo cáo sẽ luôn được thực hiện bởi khách hàng, thì bạn có thể tách chúng ra, nhưng nếu bạn cần báo cáo (chẳng hạn như báo cáo tài chính nội bộ của riêng bạn) với dữ liệu tổng hợp, sẽ dễ dàng hơn nhiều nếu bạn có cơ sở dữ liệu hợp nhất. Tôi mang lại điều này bởi vì mọi người có xu hướng quên báo cáo cho đến sau khi thiết kế được thiết lập và nó có thể gây ra một số vấn đề khá khó chịu khi bạn làm điều đó.