Trường hợp của bạn trông giống như một trường hợp của lớp / lớp con.
Có hai cách cổ điển để thiết kế bảng SQL để xử lý các lớp con. Mỗi thứ đều có ưu điểm và nhược điểm.
Một cách được gọi là "Kế thừa Bảng Đơn". Trong thiết kế này chỉ có một bảng cho tất cả các đối tượng người dùng. Nếu một cột nhất định không liên quan đến một hàng nhất định, thì phần giao nhau là NULL. Một cột có thể được thêm vào để chỉ ra loại người dùng.
Một cách khác được gọi là "Kế thừa Bảng Lớp". Điều này giống như câu trả lời mà Nanego đã đưa ra, với một vài thay đổi nhỏ. Có một bảng cho người dùng, với tất cả dữ liệu chung và một trường id. Có một bảng cho mỗi lớp con, với dữ liệu liên quan đến lớp con đó. Trường id thường được thiết lập dưới dạng bản sao của trường id trong hàng khớp trở lại trong bảng người dùng. Bằng cách này, khóa lớp con có thể làm nhiệm vụ kép, hoạt động như một khóa chính và khóa ngoại tham chiếu đến bảng người dùng. Kỹ thuật cuối cùng này được gọi là "Khóa chính dùng chung". Nó yêu cầu một chút lập trình tại thời điểm chèn, nhưng nó rất đáng giá. Nó thực thi tính chất 1-1 của mối quan hệ và tăng tốc các phép nối cần thiết.
Bạn có thể tra cứu cả ba thiết kế này dưới dạng thẻ trong SO hoặc dưới dạng các bài báo trên web.
một bảng-kế thừa class-table-inherit shared-primary-key
