2011-02-10 60 views
5

Tôi đang quản lý một cơ sở dữ liệu khá lớn đã phát triển về độ phức tạp và thiết kế từ một cơ sở dữ liệu ứng dụng đơn lẻ. Bây giờ có một kế hoạch để thêm một ứng dụng thứ năm mang theo nó lược đồ riêng và dữ liệu cụ thể của nó. Tôi đã nghiên cứu các giải pháp SSO nhưng đó không thực sự là những gì tôi đang làm. Mục tiêu của tôi là có một điểm đăng ký khách hàng, đăng nhập và ủy quyền.Một cơ sở dữ liệu người dùng phục vụ nhiều cơ sở dữ liệu ứng dụng

Lý tưởng nhất, mỗi ứng dụng sẽ yêu cầu xác thực và được cấp quyền cho nhiều ứng dụng, trong đó các ứng dụng sau đó sẽ kết nối với cơ sở dữ liệu thích hợp cho các hoạt động. Tôi không có kinh nghiệm tay đầu tiên đối phó với mức độ tách biệt này vì cơ sở dữ liệu một đã được khuấy hoàn hảo trong nhiều năm. Bất kỳ giấy tờ thực hành tốt nhất sẽ được đánh giá :)

Tôi sẽ hình dung một cơ sở dữ liệu cốt lõi mà duy trì chia sẻ dữ liệu - Khách hàng/Công ty/Sản phẩm

  1. bảng Core và phím chính -Để duy trì tính toàn vẹn tham chiếu nên tôi có một bảng nhân bản nhỏ hơn trong mỗi cơ sở dữ liệu “ứng dụng”. Một số cách để chia sẻ khóa giữa các cơ sở dữ liệu khác nhau và đảm bảo tính toàn vẹn tham chiếu là gì?

  2. Sao chép - Hai người đăng ký hiện đang lấy dữ liệu từ cơ sở dữ liệu sản xuất nơi dữ liệu sau đó được nhóm vào một giải pháp DW để báo cáo. Tôi có đi xuống một con đường có thể dẫn đến thất vọng không?

  3. toàn vẹn dữ liệu - Làm thế nào tôi có thể đảm bảo cho ví dụ: DATABASE_X.PREFERENCES.USER_ID = luôn tham chiếu a = CORE_DATABASE.USERS.USER_ID

  4. Báo cáo - Tôi sẽ vượt Loại rào cản sao chép/chuyển đổi dữ liệu từ nhiều cơ sở dữ liệu thành một cơ sở dữ liệu báo cáo?

  5. Giấy tờ trắng - Có ai có thể tìm thấy giới thiệu tốt cho chiến lược này trong thực tế không?

Cảm ơn

Trả lời

1

Một vài url cho bạn. Quy mô triển khai có thể thay đổi một cách dữ dội để phù hợp với yêu cầu nhưng hy vọng những điều này có thể giúp bạn.

http://blogs.msdn.com/b/sqlcat/archive/2008/06/12/sql-server-scale-out.aspx

này là 2005 trung tâm nhưng rất tốt http://msdn.microsoft.com/en-us/library/aa479364.aspx#scaloutsql_topic4

này một giải pháp tốt để báo cáo ... http://msdn.microsoft.com/en-us/library/ms345584.aspx

đưa cho bạn một dịch vụ phân tích một quá :) http://sqlcat.com/whitepapers/archive/2010/06/08/scale-out-querying-for-analysis-services-with-read-only-databases.aspx

+0

Cảm ơn, các bài viết tuyệt vời và chính xác những gì tôi đang tìm kiếm. –

0

Tôi tạo ra một cái gì đó như thế này một vài năm trước đây sử dụng quan điểm và thủ tục được lưu trữ để mang lại các dữ liệu từ cơ sở dữ liệu tổng thể vào cơ sở dữ liệu cấp dưới. Điều này sẽ cho phép bạn dễ dàng tham gia các bảng chính đó vào các bảng cấp dưới khác.

+0

Xin chào, cảm ơn bạn đã trả lời !! Khi bạn nói đưa vào, bạn có nghĩa là tạo một bản sao con nhỏ hơn của dữ liệu chính của cơ sở dữ liệu vào mỗi cơ sở dữ liệu cấp dưới hoặc một liên kết ảo được duy trì thông qua sp và các chế độ xem. Lý do tôi hỏi là bởi vì tôi càng nghĩ về nó càng có vẻ hợp lý để tạo ra một "bảng hoặc các khóa" cho mỗi bảng cơ sở dữ liệu chủ được sử dụng trong các cấp dưới của ref. chính trực. –

+0

Những gì tôi đã làm là để lại dữ liệu chủ trong Cơ sở dữ liệu chính và chỉ đề cập đến nơi cần thiết. Tôi không thể nhớ nếu bạn có thể làm toàn vẹn referenetial trên cơ sở dữ liệu, nhưng tôi đã sử dụng chúng như là chìa khóa foriegn. – smcdrc

0

Bạn đã xem xét sử dụng RAC chưa? Bạn có thể có nhiều cơ sở dữ liệu vật lý nhưng chỉ có một cơ sở dữ liệu logic. Điều này sẽ giải quyết tất cả các vấn đề toàn vẹn của bạn. Và bạn có thể đặt sang một bên các nút chỉ để báo cáo.

0

Đừng vứt bỏ ý tưởng của việc có các ứng dụng riêng biệt và liên kết đăng nhập/tắt chức năng thông qua webservice (esque) yêu cầu. Tôi đã thấy các hệ thống thanh toán/đăng ký người dùng được tách riêng theo cách này. Mặc dù ở quy mô rất lớn, điều này có thể không phải là một ý tưởng tốt.

Các vấn đề liên quan