Giữ hồ sơ người dùng và người dùng trong các bảng khác nhau?

Tôi đã thấy trong một vài dự án mà các nhà phát triển thích giữ thông tin người dùng thiết yếu trong một bảng (email / đăng nhập, mật khẩu băm, tên hiển thị) và phần còn lại của hồ sơ người dùng không thiết yếu trong một ngày khác (ngày tạo, quốc gia, v.v.). Bởi không thiết yếu tôi có nghĩa là đôi khi dữ liệu này chỉ cần thiết. Rõ ràng lợi ích là nếu bạn đang sử dụng ORM truy vấn ít trường hơn thì rõ ràng là tốt. Nhưng sau đó, bạn có thể có hai thực thể được ánh xạ vào cùng một bảng và điều này sẽ giúp bạn tránh truy vấn những thứ bạn không cần (trong khi thuận tiện hơn). Có ai biết bất kỳ lợi thế khác của việc giữ những thứ này trong hai bảng?

Nó phụ thuộc vào quy mô và yêu cầu của dự án của bạn.

Tôi có thể thấy một cách mà dữ liệu về người dùng có thể được chia thành hai bộ, với các mục đích khác nhau và do đó yêu cầu:

• Dữ liệu nhận dạng: tên người dùng, mật khẩu băm, địa chỉ email, thời gian đăng nhập lần cuối, v.v.
• Dữ liệu hồ sơ người dùng, bao gồm tùy chọn người dùng, hoạt động mới nhất, cập nhật trạng thái, v.v.

Lưu ý rằng có một số thuộc tính về người dùng có thể thuộc một trong hai loại (ví dụ: ngày sinh của người dùng). Sự khác biệt giữa hai bộ này là bộ đầu tiên được kiểm soát chặt chẽ và chỉ thông qua các quy trình công việc nhất định, nó mới có thể được sửa đổi. Ví dụ: thay đổi mật khẩu có thể yêu cầu cung cấp mật khẩu hiện tại, thay đổi email có thể yêu cầu xác minh email và nó sẽ được sử dụng trong trường hợp người dùng quên mật khẩu.

Tùy chọn không yêu cầu ACL như vậy và về mặt lý thuyết có thể được sửa đổi bởi người dùng hoặc ứng dụng khác miễn là người dùng đồng ý với nó. Các cổ phần thấp nếu ứng dụng độc hại hoặc do lỗi làm hỏng dữ liệu hoặc cố gắng sửa đổi nó (giả sử các biện pháp bảo mật khác được thực hiện.) Tuy nhiên, thường sẽ là thảm họa nếu bất kỳ tên người dùng, mật khẩu hoặc email nào có thể được sửa đổi vì chúng có thể được sử dụng để giả định danh tính người dùng hoặc từ chối dịch vụ hoặc gây ra chi phí hỗ trợ, v.v. cho quản trị viên.

Do đó, thông thường dữ liệu được lưu trữ trong hai loại hệ thống:

• Dữ liệu nhận dạng thường sẽ đi trong một thư mục hoặc giải pháp IAM.
• Dữ liệu ưu tiên sẽ kết thúc trong một cơ sở dữ liệu.

Có nói rằng, trong thực tế, mọi người sẽ vi phạm các quy tắc này và sử dụng cái này hoặc cái kia (ví dụ: máy chủ SQL đằng sau nhà cung cấp thành viên ASP.NET).

Khi dữ liệu nhận dạng trở nên lớn hơn hoặc tổ chức sử dụng nó trở nên lớn hơn, các loại vấn đề khác nhau xuất hiện. Ví dụ, trong trường hợp thư mục, nó sẽ cố gắng sao chép mật khẩu thay đổi ngay lập tức cho tất cả các máy chủ trong môi trường nhiều máy chủ. Tuy nhiên, sở thích của người dùng chỉ yêu cầu sự nhất quán cuối cùng. (FYI: Cả hai đều là tối ưu hóa khác nhau của định lý CAPS.)

Cuối cùng, các thư mục (đặc biệt là các thư mục trực tuyến / đám mây) cũng sẽ cấp mã thông báo truy cập cho các tài nguyên khác bằng các giao thức như OAUTH (ví dụ: xem xét Facebook, Google, Tài khoản Microsoft, ADFS), trong khi cơ sở dữ liệu không có nhu cầu như vậy. Một cơ sở dữ liệu sẽ hỗ trợ các phép nối và cấu trúc truy vấn khá phức tạp, thư mục nào không cần.

Để biết thêm chi tiết, một vài tìm kiếm trên thư mục nhận dạng so với cơ sở dữ liệu sẽ giúp ích.

Cuối cùng, các kịch bản của bạn là gì và dự kiến ​​sẽ có trong tương lai, bao gồm tích hợp với bất kỳ bên thứ ba nào (và những gì họ đang sử dụng). Nếu đó là một dự án đầy đủ và bạn tự tin rằng bạn có thể bảo mật dữ liệu nhận dạng người dùng và xác thực chính xác, thì bạn có thể truy cập cơ sở dữ liệu. Nếu không, nó có thể đáng để điều tra một thư mục danh tính.

Nếu bạn chọn DB, IMO, sử dụng một DB so với hai cuối cùng sẽ đi xuống để kiểm soát truy cập, cho cả người dùng và ứng dụng.

Ít nhất, có ba trường hợp khi có một bảng người cho các thuộc tính cơ bản và bảng thứ hai cho các thuộc tính khác có mối quan hệ một đối một, là mong muốn:

• Dữ liệu BLOB như một bức tranh. Một bảng riêng biệt cho phép dữ liệu được lưu trữ riêng vì lý do hiệu suất, ví dụ như trong một không gian bảng riêng biệt.
• Dữ liệu không áp dụng cho mọi người hoặc chỉ áp dụng cho một người đóng vai trò nhất định. Hãy nghĩ về nó như các cột sẽ là null trong nhiều hàng nếu chúng là một phần của bảng chính. Trong cơ sở dữ liệu của một phòng khám, bạn có thể có một bảng người, một bảng bệnh nhân và một bảng thuốc, trong lần đầu tiên bạn sẽ có các thuộc tính cơ bản, trong phần thứ hai chỉ có các thuộc tính thích hợp khi người đó là bệnh nhân như bảo hiểm, trong bảng thứ ba (khi người đó là một bác sĩ) bạn có thể có các chuyên khoa y tế và các dữ liệu khác chỉ áp dụng cho nhân viên y tế. Rõ ràng một bác sĩ có thể là một bệnh nhân.
• Một bảng cụ thể hóa mối quan hệ với một thực thể trong một hệ thống từ xa. Trong trường hợp này, bảng thiết lập sự tương đương giữa các định danh duy nhất trong cơ sở dữ liệu riêng biệt vì lý do tương tác.

Tôi nghĩ rằng trường hợp bạn tiếp xúc phù hợp trong trường hợp thứ hai.

Lý do chính của tôi để giữ chúng tách biệt là cố gắng và tránh những gì được biết đến trong lập trình Hướng đối tượng như là một 'lớp thần'. ORM liên quan các bảng và trường với các lớp và thuộc tính, do đó, nó cũng trở nên có liên quan như cấp độ SQL (ngay cả khi không có ORM cũng có một nguyên tắc tương tự khi chơi).

Lớp Người dùng (và bằng cách liên kết bảng người dùng) thường là bảng trở thành lớp thần với hàng trăm thuộc tính / trường, hàng chục hoặc hàng trăm phương thức và định nghĩa lớp (cho các phương thức) trên 1000 dòng. Tôi đã nhìn thấy tất cả. Nhiều hơn một lần.

Vì vậy, việc tách ra khỏi người dùng cố gắng giải quyết điều đó. Có thể có người, người dùng, tài khoản và việc phân tách các mối quan tâm có vẻ hơi giả tạo nhưng đó là để thử và tránh sự phức tạp và đảm bảo rằng mỗi đối tượng chỉ quan tâm đến 1 khía cạnh của dữ liệu.