Câu hỏi MySQL - Cách xử lý nhiều loại người dùng - một bảng hoặc nhiều người?

Question

Tôi đang thiết kế cơ sở dữ liệu cho một tổ chức có nhiều "loại" người dùng. Lúc đầu, tôi chỉ tạo một bảng người dùng. Tuy nhiên, trong khi tất cả người dùng chia sẻ một số thông tin chung (tên, họ, tên người dùng, mật khẩu, v.v.), mỗi loại người dùng yêu cầu một hoặc hai trường bổ sung không áp dụng cho tất cả người dùng. Trong khi tôi có thể tạo ra các trường bổ sung và đặt chúng là NULL, tôi không muốn làm điều này, vì các trường là khóa ngoài và nó đã gây ra vấn đề cho tôi.

Tình huống này thường được xử lý như thế nào?

Cảm ơn!

Answer 1

bản năng của bạn để không tạo ra một bảng lớn với rất nhiều NULLS là phải vào. Đó là một ý tưởng tồi, từ một điểm lưu trữ/retrival/bảo trì của xem, cũng như một điểm xác nhận dữ liệu của xem (nhiều hơn về điều đó sau này).

Hai approcaches phổ biến nhất:

1) Có một bảng người dùng với tất cả các trường phổ biến trong nó, trong đó có một trường "loại người dùng". Sau đó, có một bảng riêng biệt cho từng loại người dùng có chứa các trường bổ sung. Tất cả người dùng có một hàng trong bảng người dùng và một hoặc nhiều bảng loại người dùng cụ thể. Đây là chuẩn hóa và lưu trữ nhanh nhất và hiệu quả nhất. Điều này cũng cho phép bạn sử dụng các contraints và các khóa ngoài để đảm bảo rằng tất cả các thông tin cần thiết cho từng loại người dùng có sẵn.

2) Có bảng người dùng với tất cả các trường phổ biến trong đó. Có một bảng khác có tên là UserAttributes có các trường cho userid, key và value. Bất kỳ siêu dữ liệu bổ sung nào cho một người dùng cụ thể đều có thể được lưu trữ tại đây. Điều này có lợi thế là không yêu cầu bất kỳ quản trị cơ sở dữ liệu nào để thêm các loại người dùng hoặc siêu dữ liệu mới được lưu trữ cho từng loại người dùng. Tuy nhiên, nó không cho phép bạn thực hiện bất kỳ xác nhận dữ liệu nào ở cấp DB.

Answer 2

Mô hình quan hệ, như vậy, không hỗ trợ "kế thừa", có thể giúp giải quyết vấn đề này (mặc dù một vài động cơ DB, chẳng hạn như PostgreSQL, hỗ trợ kế thừa).

Vì vậy, trước tiên tôi sẽ tự hỏi mình - các loại người dùng khác nhau có cần phải xuất hiện trong cùng một ngữ cảnh không, ít nhất trong một số trường hợp? Nếu vậy, bạn không thể chỉ sao chép và dán "các cột chung" vào nhiều bảng (ít nhất là không làm mất kiểm tra tính toàn vẹn mà bạn có thể nhận được trong các trường hợp đó thông qua các khóa ngoại trên một bảng).

Câu hỏi thứ hai - có phải là bao giờ có thể cho người dùng giữ nhiều hơn một vai trò không? Trong nhiều trường hợp, nó sẽ là khác thường nhưng không hoàn toàn không thể, ví dụ: nhân viên cũng có thể là nhà cung cấp hoặc khách hàng.

Nếu tôi không thể nhận được câu trả lời sắc nét cho những câu hỏi như vậy hướng tôi đi, tôi sẽ thiết lập bảng người dùng chỉ với các trường chung; và các bảng riêng biệt cho các nhà cung cấp, nhân viên, người thử nghiệm beta, khách hàng và bất kỳ loại và vai trò nào khác mà tôi có thể có cho người dùng, mỗi cột chỉ có các cột chuyên biệt của riêng nó cộng với chìa khóa nước ngoài vào bảng người dùng để nhận phần còn lại.

Tôi nhận ra rằng các lược đồ chuẩn hóa đã hết thời trang, nhưng chúng đã phục vụ tôi một cách trung thực trong nhiều thập kỷ và tôi rất yêu thích chúng - tôi chỉ không chuẩn hóa khi tôi cần tối ưu hóa cụ thể. có thể nghĩ!-). Một số phần không chuẩn hóa có thể hữu ích ở đây là một cột liệt kê trong bảng người dùng cho thấy vai trò "chính" hoặc "duy nhất" của mỗi lần sử dụng cụ thể (nó có thể rỗng và có thể đồng đều null khi bắt đầu, nếu tôi đã đủ mạnh để có nó ngay từ đầu ...; -) ... nhưng tôi có thể chờ đợi để thêm nó nếu và khi hiệu suất của một số truy vấn cụ thể cần nó như một tối ưu hóa cụ thể, thay vì thiết kế lược đồ theo cách đó ngay từ đầu (lưu ý rằng đây là lý do chính để không bao giờ sử dụng SELECT * FROM trong các truy vấn của bạn - nếu bạn ALTER TABLE sau đó thêm cột, SELECT * là một bit sẽ bị vỡ! -).

Answer 3

Đây là câu hỏi bình thường hóa nổi tiếng.

Xem nhanh bài viết này hoặc những người khác thích bài viết đó để tìm câu trả lời phù hợp với nhu cầu kinh doanh.

To normalize or not to normalize

Answer 4

Bạn không nói nếu bạn đang sử dụng một ngôn ngữ cấp cao, vì vậy tôi sẽ chỉ đưa ra một ví dụ chung với DB-giống như ví dụ:

Cơ sở dữ liệu thiết kế là khó khăn. Vì vậy, đây sẽ là một câu trả lời nhanh chóng và đơn giản.

Câu hỏi của bạn là câu hỏi cơ bản về mối quan hệ dữ liệu và thiết kế cơ sở dữ liệu. Tìm kiếm một số hướng dẫn cách thực hiện cơ bản để giúp câu trả lời này. Nó có thể giúp suy nghĩ về cách thông tin của bạn được nhóm lại, và liên kết "trở lại" với tập hợp chính (bảng) từ các bộ khác (bảng).

Vì vậy, người dùng là người dùng - đó là bảng của bạn. Nó phải chứa các yếu tố chính (các cột) dữ liệu được liên kết với người dùng.

Sau đó, tập hợp thông tin khác này (ví dụ: quyền hoặc điều gì đó) là một bảng khác.

Chỉ cần đảm bảo rằng bảng khác này có một giá trị (cột) trỏ lại cho người dùng, mà nó đề cập đến. Bạn có thể sẽ muốn nói với cơ sở dữ liệu của bạn để tạo ra một "chỉ số" giữa chúng (để cải thiện màn trình diễn tra cứu, vv)

Ví dụ, A loại "phép" bảng cho người dùng:

- integer "id"  <--- unique, index column, auto-increment 
    - integer "user_id" <--- this is which user this belongs 
    - ... 
    - Boolean "can_write"   <--- example data column 
    - Boolean "can_read"   <--- example data column 
    - Boolean "can_reboot_system" <--- example data column 
    - etc, whatever you want 

Vì vậy, bạn có thể "SELECT * FROM user_table WHERE first_name = 'joe' (hoặc như vậy) ... để có được một người dùng. Trong đó, tôi hy vọng bạn có một số loại 'id' giá trị để xác định hàng đó. Bây giờ, chỉ cần thực hiện quyền 'SELECT * FROM FROM WHERE user_id =' nnnn '(bất kể id của người dùng đó là gì).

Nếu người dùng chỉ có 1 quyền được đặt, thì bạn chỉ có thể có user_id mà không có cột "id" bổ sung.