Tại sao việc tách dữ liệu người dùng và hồ sơ được coi là tốt?

Question

Tôi đã đọc số question và cảm thấy rằng tôi không hoàn toàn đồng ý với tuyên bố Separation of user and profile data is a nice touch.

Như tôi thấy, dữ liệu hồ sơ, chẳng hạn như, ví dụ: quốc gia hoặc bất kỳ thứ gì thuộc về đối tượng người dùng, trong khi tách dữ liệu đó thành hồ sơ sẽ dẫn đến việc tạo một đối tượng mới (và bảng) với mối quan hệ 1 đến 1 đối với đối tượng người dùng. Sự tách biệt này được coi là một thực hành tốt chỉ vì lý do thẩm mỹ? (Bạn chỉ thấy dữ liệu đầu vào của người dùng trong một bảng và dữ liệu được tạo ở một bảng khác)

Answer 1

Vâng, đó là chỉ khi bạn cho rằng người dùng và tiểu sử có mối quan hệ 1-1.

Nếu điều này luôn được đảm bảo, hơn lý do tách biệt có thể hoàn toàn mang tính thẩm mỹ, tuy nhiên vẫn có thể có lý do hiệu suất để tách hai.

Ví dụ, dữ liệu hồ sơ có thể được truy cập bởi người dùng khác, thường có thể được lưu trữ mà không cần xem xét nhiều cho huỷ bỏ hiệu lực nhanh chóng vv

Họ là loại khái niệm khác nhau của dữ liệu - ngay cả khi họ có 1-to-1 mối quan hệ. Tôi sẽ không bao giờ lưu trữ chi tiết đăng nhập của người dùng - nhưng sau đó tôi sẽ không tiết lộ nó theo chương trình cho các mô-đun chỉ yêu cầu dữ liệu hồ sơ.

Đó là lý do nếu mối quan hệ 1-1 có thể được đảm bảo giữ. Có thể không?

Nếu bạn cho phép nhiều thông tin xác thực đăng nhập (hoặc nhiều phương thức đăng nhập) cho mỗi người dùng, thì giờ đây nó trở nên thú vị hơn. Ví dụ, các phiên dựa trên cookie thường được lưu trữ trong một kho lưu trữ dễ bay hơi ở phía máy chủ (hiếm khi có nhu cầu lưu giữ dữ liệu đó). Bạn có thông tin đó trỏ đến đối tượng người dùng hay đối tượng cấu hình không?

Bạn có thể có mối quan hệ một chiều - có một con trỏ từ Người dùng đến Hồ sơ, nhưng không phải từ Hồ sơ đến Người dùng. Bằng cách này, các mô-đun giữ dữ liệu Tiểu sử không thể thay đổi chi tiết đăng nhập.

Cuối cùng, nếu bạn sử dụng giải pháp như facebook, cho phép nhiều email đăng nhập cho mỗi người dùng và nói thêm thông tin đăng nhập qua OpenID và thông qua ứng dụng iPhone/Android? sau đó bạn có đồng ý rằng Hồ sơ và Người dùng vẫn giống nhau không?

Answer 2

Ưu điểm:

1. Bạn có thể tự do thay đổi schema bảng cấu hình và không bận tâm nếu nó phá vỡ người dùng.
2. Bạn có thể sử dụng lại logic xác thực/ủy quyền trong các ứng dụng khác.
3. Bạn có thể liên kết một người dùng với các cấu hình khác nhau và thậm chí đến các ứng dụng khác.
4. Hiệu suất tốt hơn do lượng dữ liệu nhỏ trong thực thể người dùng (áp dụng cho bộ nhớ DB, trong đó ít cột trong bảng tốt hơn) trong khi hoạt động xác thực và các thao tác chỉ người dùng khác không yêu cầu dữ liệu hồ sơ.

Nhược điểm:

1. Thêm một DB bảng hoặc tổ chức các dữ liệu khác để lưu trữ hồ sơ
2. Bạn cần phải duy trì mối quan hệ giữa dữ liệu hồ sơ và người dùng.
3. Mã khác.
4. Việc giảm hiệu suất có thể xảy ra khi truy cập dữ liệu hồ sơ.

Ví dụ: Django (khung web Python) cung cấp cơ chế xác thực và bạn có thể thêm cơ chế hồ sơ rất riêng của mình.

Nói chung nếu tiểu sử nhỏ và sẽ không bao giờ bị sửa đổi, bạn có thể lưu nó cùng với dữ liệu người dùng. Nếu lược đồ hồ sơ có thể được thay đổi trong tương lai hoặc nếu nó chứa nhiều dữ liệu thì tốt hơn là tách riêng người dùng và hồ sơ.

Answer 3

Có một vài lý do tôi có thể nghĩ đến để chia tay dữ liệu người dùng:

1. Tách uỷ quyền từ các thông tin. Đây là điều tôi muốn giới thiệu. Khi người dùng được xác thực, bạn chỉ xem xét hồ sơ người dùng. Bằng cách tách phần ủy quyền, bạn có thể dễ dàng đi từ đăng nhập mật khẩu, để thêm Kết nối Facebook, xác thực OpenID, v.v. mà không phải thực hiện bất kỳ thay đổi nào đối với các đối tượng hồ sơ người dùng.
2. Tách dữ liệu công khai và riêng tư. Trong cơ sở dữ liệu bảo mật cao, bạn có thể muốn mã hóa dữ liệu cá nhân bằng cách sử dụng khóa riêng (vì vậy chỉ người dùng có thể đọc dữ liệu), trong khi vẫn có thể truy cập dữ liệu công khai với tư cách người dùng khác.
3. Vì lý do hiệu suất. Nếu bạn có một lượng lớn dữ liệu trên người dùng, bạn có thể muốn đặt dữ liệu hiếm khi được truy cập bởi chính nó, để các chỉ mục có thể được tối ưu hóa cho dữ liệu thường được tra cứu.

Answer 4

Nếu bạn có API công cộng (ví dụ: twitter hoặc facebook), bạn chỉ muốn trả về chi tiết người dùng chứ không phải đối tượng người dùng (chứa dữ liệu được bảo vệ). Điều đó có thể được thực hiện bằng cách có các thực thể riêng biệt hoặc bằng cách có DTO.

Answer 5

Đối với tôi, người dùng là: Đăng nhập (Tên người dùng), Mật khẩu, Vai trò và được sử dụng để thực hiện tất cả các nội dung liên quan đến bảo mật.

"Hồ sơ" là thông tin bổ sung cho người dùng, cần được đặt trong đối tượng tách biệt.

Và xem xét: trong một số trường hợp người dùng có thể có nhiều hơn một hồ sơ ...

Answer 6

Chủ yếu là vì hồ sơ dữ liệu là không cần thiết nếu người ta muốn chỉ biết ai đã tạo ra một số thực thể. Nơi thực sự duy nhất cần một hồ sơ người dùng chủ yếu là khi hệ thống muốn tùy chỉnh một cái gì đó cho người dùng đó khi họ đang ở trên hệ thống. Hãy tưởng tượng hồ sơ có màu người dùng yêu thích, điều này không quan trọng đối với nhiều hoặc tất cả các ứng dụng khác của ứng dụng.