Có một triển khai tiêu chuẩn của Cơ sở dữ liệu người dùng?

Tôi cần thực hiện chức năng người dùng cá nhân cơ bản cho trang web của mình. Có một cấu trúc tiêu chuẩn cho cơ sở dữ liệu loại này? Giống như thông thường có tất cả thông tin và dữ liệu người dùng trong một bảng với mỗi người dùng có hàng riêng của mình hoặc thông tin này có nên được phân chia giữa các bảng khác nhau và được liên kết với nhau (có thể vì hiệu quả?) Tôi không quan tâm lắm đến bảo mật tại thời điểm này, nhưng rõ ràng tôi sẽ muốn mã hóa mật khẩu trước đó quá lâu.

Tôi đã cố gắng tìm những gì tôi đang tìm kiếm trên google, nhưng không có kết quả. Chỉ cần cho tôi biết nếu câu hỏi cần làm rõ thêm hoặc bất cứ điều gì.

Tôi đề nghị bạn sử dụng các tiêu chuẩn chuẩn hóa điển hình. Một người dùng mỗi hàng.

• ID người dùng (tăng số tiền lớn)
• Tên người dùng chung (sẽ được hiển thị trên trang web)
• Địa chỉ email người dùng
• Mật khẩu muối (Duy nhất cho mọi người dùng, được chèn khi tài khoản được tạo)
• Mật khẩu (Được băm bằng muối - MD5 hoặc SHA1, tùy chọn của bạn)
• Tài khoản ngày đã được tạo

Phần còn lại là tùy thuộc vào quy tắc kinh doanh của bạn.

Sẽ phải đi cho một thời trang lớn "nó phụ thuộc".

Tất nhiên bạn sẽ cần một số loại chìa khóa trên bảng này. Bạn có thể bắt đầu với một ID người dùng. Đây chỉ có thể là một INT tăng (hoặc bigint nếu bạn sẽ có hơn 2,1 triệu người dùng).

Tôi đã thấy rất nhiều cơ sở dữ liệu cũng sử dụng GUID làm UserID chính. Nhưng đó là mở ra một loạt sâu khác nhau bằng cách sử dụng GUID cho PK.

Sau đó, bạn cần phải quyết định cách bạn muốn cơ sở dữ liệu bình thường hóa. Bạn sẽ cho phép người dùng của bạn có nhiều email? nhiều số điện thoại? Nếu vậy, họ nên ở trong một bảng khác.

Tôi muốn giữ bảng người dùng chính để:

• một số loại ID hoặc PK bạn có thể sử dụng
• Tên / Họ hoặc chỉ tên người dùng
• một số loại trạng thái của người dùng (hoạt động, bị vô hiệu hóa, v.v.) - (liên kết nhỏ với bảng trạng thái)
• ngày tạo ra

Đó nên là điểm khởi đầu của bạn.

Từ đó bạn có thể thêm các cột khác dựa trên những gì bạn muốn lưu trữ. Email có thể liên kết đến một bảng email, địa chỉ đến một bảng địa chỉ, vv Mật khẩu có thể sử dụng hàm băm + muối nhưng bạn đã xem xét các openids chưa?

Tôi thật sự khuyên bạn nên đọc bài viết này - http://www.sqlservercentral.com/articles/data-modeling/71725/

Nếu đó là về xác thực người dùng, tôi sẽ sử dụng LDAP. Không tạo cơ sở dữ liệu riêng cho người dùng, nếu bạn đã sử dụng cơ sở dữ liệu và có các bảng khác (đơn hàng, sản phẩm, v.v.). Bạn có thể muốn tham gia các bảng này.