Nhiều cơ sở dữ liệu V / s

Tôi đã xây dựng ứng dụng web này (php & mysql) để lưu trữ thông tin cho các tổ chức khác nhau (hiện có khoảng 20 khách hàng).

Kịch bản hiện tại lưu trữ thông tin liên quan đến máy khách trong các cơ sở dữ liệu riêng lẻ, do đó, có 20 cơ sở dữ liệu khách hàng và 1 cơ sở dữ liệu chính.

Một trong những lợi thế chính ở đây là khi mỗi db máy khách bị cô lập, việc đánh số các tạo phẩm của khách hàng (báo cáo, kiểm toán), vv được sắp xếp theo thứ tự; mang lại cho khách hàng của chúng tôi một cảm giác an toàn.

Mỗi DB có khoảng 15 bảng và nhiều hàng nhất trong một bảng là khoảng 2000. Điều này dự kiến ​​sẽ được tăng tối đa 5000 bản ghi.

Quản lý một thay đổi ở mức db có nghĩa là thay đổi 20 cơ sở dữ liệu, nhưng trong trường hợp hiếm hoi mà tôi cần thực hiện thay đổi đó, tôi sử dụng một tập lệnh thực hiện điều này trong một lệnh gọi hàm duy nhất.

Chúng tôi đang sắp xếp dịch vụ lưu trữ được chia sẻ và ISP cung cấp cho chúng tôi không giới hạn. của cơ sở dữ liệu; và đó là điều khiến tôi suy nghĩ về việc tập trung cơ sở dữ liệu; để TẤT CẢ dữ liệu khách hàng có thể được lưu trữ trong cơ sở dữ liệu chủ.

Tất nhiên, một số vấn đề quan trọng tăng lên là:

a. Duy trì chuỗi tạo tác, (điều này có thể được giải quyết bằng cách tạo khóa tham chiếu bổ sung) b. Tốc độ và hiệu suất (trong trường hợp đó tôi có thể tạo các chỉ mục để tăng tốc mọi thứ) c. Bảo mật: Điều này sẽ được quản lý khi mỗi truy vấn tìm nạp thông tin khách hàng. cũng sẽ theo dõi client_id của họ

Trong tương lai, chúng ta có thể cần xem xét so sánh các bộ dữ liệu của một tổ chức với một tổ chức khác, nhưng tôi tin rằng điều đó cũng có thể đạt được trên một db tập trung. Tôi hơi nghiêng (vì lý do hiệu suất và khả năng bảo trì) để chuyển sang cơ sở dữ liệu tập trung.

Bạn có nghĩ rằng việc chuyển sang một cơ sở dữ liệu tập trung có ý nghĩa hơn là ở lại như chúng ta (trên các cơ sở dữ liệu riêng lẻ) không?

Cảm ơn lời khuyên của bạn.

Có những rủi ro và phần thưởng kế thừa cho cả hai hệ thống. Tôi đã làm việc cho một công ty tài chính hỗ trợ khoảng 40 khách hàng (ngân hàng quốc gia) trên 1 cơ sở dữ liệu. Sau đó, chúng tôi đã mua một công ty khác bán phần mềm tương tự và đã đi kèm với 1 cơ sở dữ liệu cho mỗi khách hàng. Cuối cùng, công ty đã phá sản và chúng tôi đã phải xuất tất cả dữ liệu người dùng. Đây là những gì tôi đã làm việc cùng và tôi tìm thấy:

Chuyên nghiệp của DB đơn:

1. Cập nhật phần mềm và sửa lỗi dễ dàng hơn.
2. Dễ dàng quản lý và báo cáo về tất cả dữ liệu khách hàng.
3. Cập nhật dữ liệu trở nên dễ dàng hơn.
4. Dễ dàng tạo chức năng mô-đun mà 1 khách hàng muốn, tắt nếu cho các khách hàng khác và sau đó bật chức năng này khi họ muốn trong tương lai.

Con của DB đơn:

1. Tính toàn vẹn dữ liệu - Chúng tôi đã có 2 hoặc 3 trường hợp trong đó người dùng của 1 ngân hàng nhìn thấy dữ liệu của một ngân hàng khác. Đây là một cơn ác mộng. Đặc biệt là vì người dùng trang web không chỉ là nhân viên ngân hàng mà còn là khách hàng nắm giữ tài khoản thực tế của ngân hàng! Đây là vấn đề lớn nhất với 1 cơ sở dữ liệu
2. Xuất dữ liệu khách hàng - Khi chúng tôi phải làm điều này, nó thường không phải là một vấn đề lớn. Bạn kết thúc với 1 bảng có tất cả các máy khách trong đó và bạn tắt bảng đó để lấy dữ liệu cụ thể của khách hàng.

Pro của nhiều DB:

1. Không có mối quan tâm về ô nhiễm dữ liệu khách hàng chéo hoặc vi phạm
2. Xuất dữ liệu khách hàng là dễ dàng chết.

Con của nhiều DB:

1. Cập nhật và sửa lỗi - Đây là cơn ác mộng thực sự. Khi bạn có 20 máy khách trên 20 cơ sở dữ liệu khác nhau, bạn sẽ nhanh chóng gặp phải trường hợp 1 khách hàng muốn sửa lỗi và một người khác nghĩ rằng lỗi là một tính năng hoặc không muốn mạo hiểm cập nhật. Hơn nữa, bạn sẽ có những trường hợp trong đó 1 khách hàng muốn tăng cường thay đổi trò chơi nhưng các khách hàng khác thì không. Khi điều này xảy ra, cơ sở dữ liệu của bạn sẽ bắt đầu phân kỳ. Đột nhiên, bạn sẽ phải cập nhật máy khách 1-15 với 1 tập lệnh 16-19 với tập lệnh khác và 20 tập lệnh thứ ba. Chúng tôi thấy điều này trở thành một vấn đề đến nỗi việc sửa lỗi sẽ kéo dài gấp 15 đến 20 lần cho công ty chúng tôi đã mua so với chúng tôi vì họ phải chạy tất cả các thử nghiệm cho mọi khách hàng và xử lý từng mã khách hàng đặc biệt. Thực tế, họ cần một người hỗ trợ mới cho mọi khách hàng mới,
2. Quản lý DB - Khi bạn nhận được một số lượng lớn khách hàng quản lý tất cả các cơ sở dữ liệu sẽ trở thành một rắc rối thực sự. Bạn chắc chắn sẽ cần thêm thời gian DBA để quản lý chúng.

Cuối cùng, khuyến nghị của tôi đã thấy và thực hiện cả hai là phải có "kỷ luật"! Tôi nghĩ rằng lựa chọn đa db tốt hơn một chút vì nó bảo vệ bạn nhưng bạn không bao giờ có thể để khách hàng đưa ra lựa chọn khiến bạn chỉ thêm chức năng cho họ hoặc bạn sẽ tự đặt mình vào con đường thất bại.

Tôi có cơ sở dữ liệu riêng cho các khách hàng riêng biệt. Một khách hàng có thể yêu cầu điều này vì lý do bảo mật - tức là chỉ trang web của họ có quyền truy cập vào dữ liệu của họ. Điều đó cũng có nghĩa là nếu khách hàng muốn di chuyển dữ liệu của họ thì việc quản lý sẽ dễ dàng hơn nhiều .

Điều đó cũng có nghĩa là nếu có vấn đề với cơ sở dữ liệu của một khách hàng thì nó không ảnh hưởng đến tất cả các cơ sở dữ liệu khác.

Nếu bạn muốn so sánh dữ liệu giữa các khách hàng thì bạn nên làm điều đó một cách riêng biệt.

Nếu bạn đang dùng hết cơ sở dữ liệu mà bạn có thể có thì có lẽ bạn nên xem xét thay đổi nhà cung cấp máy chủ của mình.

Lý do duy nhất tôi không có cơ sở dữ liệu riêng cho từng khách hàng là nếu bạn sẽ có 100 hoặc 1000 khách hàng / cơ sở dữ liệu. Điều này có thể thực sự có lông để quản lý bao gồm thay đổi cơ sở dữ liệu hoặc thực hiện một cái gì đó trên tất cả các cơ sở dữ liệu. Các hành động xảy ra trên một số lượng lớn cơ sở dữ liệu cũng có thể bị chậm khi bạn cần mở (và do đó đóng) rất nhiều bảng.

Nhưng ngoài trường hợp này, tôi nghĩ rằng nhiều cơ sở dữ liệu là tốt hơn.

Một lợi thế, có thể không quan trọng nhưng có thể hữu ích, đó là mỗi khách hàng có được ID tuần tự của riêng họ (thay vì có thể bỏ qua một bó vì các khách hàng khác đã thêm hồ sơ).

Ngoài ra, nhiều cơ sở dữ liệu cho phép các bảng phụ (như loại điện thoại) có thể dễ dàng tùy chỉnh cho mỗi khách hàng mà không cần id hồ sơ gốc trong các bảng này.

Đầu tiên trình tự tạo tác. Tôi giả sử bạn đang sử dụng các khóa chính số nguyên để cung cấp điều này. Thực sự bạn nên có một cột "số giả" riêng biệt. PK nên là PK và không có gì khác. Mọi người nói về "chìa khóa tự nhiên" và những thứ tương tự và tôi co rúm lại. Bất cứ khi nào bạn dựa vào PK không chỉ là một định danh, nó sẽ quay lại cắn bạn. Nếu bạn muốn biết trình tự của một cái gì đó lưu trữ một ngày hoặc một số thứ tự.

Tôi nghĩ rằng trong trường hợp quản lý cấu hình của bạn sẽ đưa bạn đến một cơ sở dữ liệu duy nhất. Nhìn vào những gì nó chi phí bạn trong thời gian để duy trì và nâng cấp cơ sở dữ liệu. Những chi phí liên quan đến mỗi lần phát hành phần mềm? Ngoài ra, hãy suy nghĩ về chi phí khi bạn có một khách hàng mới và phải tạo một DB và định cấu hình ứng dụng cho nó. Bất cứ điều gì có thể được tự động, câu hỏi là, nó sẽ có giá trị khi bạn có 100 cơ sở dữ liệu?

Về cơ bản, việc mở rộng quy mô (phân vùng, phần cứng, shending, v.v.) sẽ dễ dàng hơn so với cơ sở dữ liệu đơn lẻ so với 100 cơ sở dữ liệu.

Tôi nghĩ rằng các áp phích khác đã làm cho một số điểm xuất sắc vì vậy tôi sẽ không đi qua những điểm đó.

Để thêm vào pro / con được liệt kê cho đến nay:

Pro của nhiều cơ sở dữ liệu:

1. Vấn đề khóa được tránh; chúng tôi có cơ sở dữ liệu nơi khách hàng có thể kích hoạt thay đổi DDL trên một số bảng. Đối với các bảng lớn hơn (> 2m bản ghi), điều này sẽ khóa bảng trong một khoảng thời gian đáng kể. Những người duy nhất gặp bất lợi là người dùng của chính họ, vì vậy đây là loại có thể chấp nhận được.

2. Tính linh hoạt - một số khách hàng có mong muốn cụ thể về dữ liệu họ muốn lưu trữ; đa cơ sở dữ liệu cho phép chúng tôi linh hoạt thay đổi cơ sở dữ liệu của họ một cách cụ thể mà không phải làm lộn xộn mô hình dữ liệu cho các máy khách khác.

Nhược điểm:

1. Con lừa chính: Tham gia vào các bảng khác thì cồng kềnh hơn rất nhiều. Chúng tôi đã có một cơ sở dữ liệu chính chứa hầu hết dữ liệu meta. Người dùng cơ sở dữ liệu dành riêng cho khách hàng không có quyền truy cập vào cơ sở dữ liệu này, vì vậy tất cả các phép nối giữa các bảng trong cơ sở dữ liệu đó và cơ sở dữ liệu dành riêng cho khách hàng được xử lý trong ứng dụng thay vì trong cơ sở dữ liệu. Bạn có thể giải quyết vấn đề này bằng cách cấp cho người dùng cụ thể của khách hàng quyền truy cập vào cơ sở dữ liệu chính, nhưng sau đó ứng dụng có thể / có thể rò rỉ thông tin lại.

Chúc may mắn trong việc lựa chọn!

Tôi biết bạn đã chọn một câu trả lời, nhưng có vẻ như có một giải pháp khác không được đề xuất:

Di chuyển mọi thứ sang một cơ sở dữ liệu, nhưng tạo các bảng cho mỗi khách hàng, sử dụng tiền tố, như sau:

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

Đó là loại tốt nhất của cả hai thế giới.

• Rất dễ dàng để di chuyển từ thiết lập hiện tại của bạn sang thiết lập mới.
• Bạn có thể tạo 1 người dùng cho mỗi khách hàng và giới hạn các đặc quyền của nó đối với các bảng của công ty anh ta và không có gì khác
• Bạn có thể tạo một siêu người dùng và dễ dàng tổng hợp dữ liệu nếu bạn cần làm như vậy.
• Chỉ sử dụng một cơ sở dữ liệu