Chuẩn hóa cơ sở dữ liệu so với phụ thuộc


8

Tôi đang phát triển 3-4 chương trình phụ thuộc lẫn nhau. Gọi họ là foo bar baz và auth. Tôi muốn họ độc lập với nhau. Hãy tưởng tượng nếu tôi cấp phép cho mỗi chương trình cho các công ty khác. Một số công ty có thể muốn foo và bar, những công ty khác có thể chỉ muốn baz, v.v ... Nó cũng có vẻ giống như thực hành tốt để giữ auth độc lập là tốt.

Bối cảnh: auth đang chăm sóc xác thực cho tất cả các hệ thống. Bảng người dùng chính trong auth có user_id, email, mật khẩu, đầu tiên, cuối cùng

foo cũng có một bảng người dùng có các trường cụ thể cho ứng dụng: user_id, role_id, v.v.

Mỗi hệ thống có cơ sở dữ liệu riêng. Trong quá khứ tôi đã tạo một khóa ngoại từ mỗi ứng dụng cho db auth. Tôi đã xóa quyền cập nhật từ các dbs khác nhưng được cấp quyền truy cập vào một số trường có liên quan. Đây có vẻ là một giải pháp tồi vì nó tạo ra sự phụ thuộc chặt chẽ, nhưng nó cho phép tôi bình thường hóa db để tôi không phải lưu tên người dùng và email trong cơ sở dữ liệu foo, bar hoặc baz.

Sẽ tốt hơn để lưu trữ thông tin trong tất cả các cơ sở dữ liệu? Hoặc sẽ tốt hơn nếu lưu trữ Id Auth trong thanh foo và baz và sử dụng api để lấy thông tin người dùng bằng authId?

Tương tự, tôi có thể có khách hàng trong cả 3 hệ thống. Chắc chắn việc tạo ra một phụ thuộc vào một auth db có vẻ không tốt, nhưng còn các dbs khách hàng trên cả 3 thì sao?

Hoặc là giải pháp tốt nhất để có một db trung tâm. Một bảng người dùng.

nhập mô tả hình ảnh ở đây

Gợi ý khác?


2
Bạn nói rằng nó có vẻ là một thực hành tốt để giữ độc lập 'auth', tuy nhiên các chương trình khác có thể thực thi mà không cần auth. Điều gì xảy ra nếu hai trong số các chương trình và không xác thực được đặt trên một hệ thống. Làm thế nào là xác thực sẽ được thực hiện? Mối quan hệ đó sẽ xác định mức độ xác thực được kết hợp chặt chẽ với các quy trình khác và như vậy dữ liệu sẽ được cấu trúc như thế nào.
Gerald Davis

foo barví dụ thường quá trừu tượng để được minh họa tốt.
Robert Harvey

Câu trả lời:


4

Nếu bạn có 4 dịch vụ độc lập, thì họ phải độc lập. Không có dữ liệu nào được chia sẻ trong các DB thông thường hoặc tương tự, vì khi đó bạn chỉ cần làm cho chúng phụ thuộc!

Bây giờ, mặc dù có thể chia sẻ một DB duy nhất trong sản xuất, các dịch vụ nên sử dụng các lược đồ riêng của chúng vì DB chỉ ở đó như một thùng chứa chung, tương tự như cách một máy chủ Linux có thể chạy cả 4 dịch vụ.

Mỗi dịch vụ nên có API riêng và đây là cách duy nhất để nhận dữ liệu vào và ra từng dịch vụ. Vì vậy, dịch vụ xác thực của bạn sẽ lưu trữ người dùng và thực hiện xác thực, nhưng sẽ trả lại một số mã thông báo để xác định người dùng. Mã thông báo này là những gì các dịch vụ khác sử dụng để ghi nhớ người dùng nào - nhưng nếu không thì họ hoàn toàn không có kiến ​​thức về xác thực người dùng.

Cách dễ nhất để nghĩ đến việc thực hiện những điều này là nghĩ bạn sẽ làm gì nếu bạn quyết định sử dụng dịch vụ của bên thứ 3 thay vì dịch vụ bạn đang viết - nếu bạn đã sử dụng dịch vụ OpenID của StackExchange cho người dùng thay vì của riêng bạn. Nếu bạn có thể thay thế nó vào kiến ​​trúc của bạn thì bạn có một thiết kế độc lập, tốt.


2

Ví dụ của bạn là một chút trừu tượng, nhưng hãy để tôi chạy qua suy nghĩ của tôi.

Lựa chọn A: Theo kinh nghiệm của tôi, điều này luôn luôn xấu bất kể lý do của bạn. chắc chắn các DB như MSSQL có thể có cơ sở dữ liệu bạn bè, v.v., nhưng nếu dữ liệu được liên kết, nó sẽ nằm trong cùng một DB

Tùy chọn B: Không chắc chắn những gì đang diễn ra ở đây, bạn đang thêm một API truy vấn tất cả các DB và mang lại kết quả cùng nhau? Điều này tốt hơn, nhưng nếu bạn có Ứng dụng trên API đó thì đó là một phần của trình dữ liệu cho họ và họ thực sự chỉ sử dụng một trong các DB, vậy tại sao họ lại có các ứng dụng khác trong lớp dữ liệu mạnh hơn?

Tùy chọn C: Vâng, điều này hoạt động, nhưng thật không tốt khi có một cơ sở dữ liệu lớn với dữ liệu không liên quan trong đó. Bạn muốn các chương trình độc lập với nhau phải không? dosnt này giúp với điều đó.

Lựa chọn D

Đề nghị của tôi là trừu tượng hóa xác thực đi từ khái niệm userId. Ứng dụng Auth của bạn phải liên quan đến người dùng và vai trò (hoặc lời hứa, v.v ... nếu bạn đang hoàn toàn hiện đại) dữ liệu này sẽ tồn tại trong Auth DB

Mỗi ứng dụng cần có userId để nhóm dữ liệu theo người dùng, với một số dữ liệu liên quan để thực hiện cuộc gọi xác thực và nhận dạng người dùng với con người. đây sẽ là userId (duy nhất cho ứng dụng), tên thật, tên người dùng, dịch vụ xác thực để sử dụng. Dữ liệu này nên tồn tại trên DB ứng dụng

Các cơ sở dữ liệu không có kết nối giữa chúng, về mặt khái niệm bạn sẽ có thể sử dụng facebook làm dịch vụ xác thực thay vì Ứng dụng Auth của bạn

Bạn có thể cần thêm thông tin liên kết Người dùng nếu bạn muốn liên kết người dùng foo với người dùng thanh


0

Tôi sẽ khuyên bạn nên triển khai Đăng nhập một lần (SSO), ví dụ như với LDAP. Những khách hàng lớn hơn của bạn cũng có thể đã được hưởng lợi từ nó, vì họ sẽ có thể thay thế ứng dụng auth tích hợp của bạn bằng cơ sở dữ liệu người dùng hiện có của họ. Đối với những khách hàng nhỏ hơn không hỗ trợ SSO, bạn có thể đơn giản hóa việc triển khai bằng cách vận chuyển ứng dụng của mình bằng ứng dụng xác thực mặc định.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.