Lưu trữ giới tính (giới tính) trong cơ sở dữ liệu

Tôi muốn lưu trữ giới tính của người dùng trong cơ sở dữ liệu với chi phí (kích thước / hiệu suất) càng ít càng tốt.

Cho đến nay, 3 kịch bản đến với tâm trí

1. Int - căn chỉnh với Enum trong mã (1 = Nam, 2 = Nữ, 3 = ...)
2. char (1) - Lưu trữ m , f hoặc một mã định danh ký tự đơn khác
3. Bit (boolean) - có tên trường thích hợp cho tùy chọn này không?

Lý do tôi hỏi là vì điều này câu trả lời mà nói rằng chars là nhỏ hơn so với các phép toán luận .

Tôi nên làm rõ rằng tôi đang sử dụng MS SQL 2008, trong thực tế DOES có kiểu dữ liệu bit.

Tôi gọi cột là "giới tính".

Data Type   Bytes Taken          Number/Range of Values
------------------------------------------------
TinyINT     1                    255 (zero to 255)
INT         4            -       2,147,483,648 to 2,147,483,647
BIT         1 (2 if 9+ columns)  2 (0 and 1)
CHAR(1)     1                    26 if case insensitive, 52 otherwise

Các BIT kiểu dữ liệu có thể được loại trừ bởi vì nó chỉ hỗ trợ hai giới tính có thể đó là không đủ. Mặc dù INT hỗ trợ nhiều hơn hai tùy chọn, phải mất 4 byte - hiệu suất sẽ tốt hơn với kiểu dữ liệu nhỏ hơn / hẹp hơn.

CHAR(1)có lợi thế hơn TinyINT - cả hai đều có cùng số byte, nhưng CHAR cung cấp số lượng giá trị hẹp hơn. Việc sử dụng CHAR(1)sẽ làm cho việc sử dụng các khóa tự nhiên "m", "f", v.v ... so với việc sử dụng dữ liệu số được gọi là khóa thay thế / khóa nhân tạo. CHAR(1)cũng được hỗ trợ trên bất kỳ cơ sở dữ liệu nào, nếu cần phải chuyển.

Phần kết luận

Tôi sẽ sử dụng Tùy chọn 2: CHAR (1).

Phụ lục

Một chỉ mục trên cột giới có thể sẽ không giúp ích vì không có giá trị trong một chỉ mục trên cột có số lượng thẻ thấp. Có nghĩa là, không có đủ sự đa dạng trong các giá trị để chỉ mục cung cấp bất kỳ giá trị nào.

Đã có một tiêu chuẩn ISO cho việc này; không cần phải phát minh ra sơ đồ của riêng bạn:

http://en.wikipedia.org/wiki/ISO_5218

Theo tiêu chuẩn, cột phải được gọi là "Giới tính" và loại dữ liệu 'gần nhất' sẽ là cực nhỏ với ràng buộc KIỂM TRA hoặc bảng tra cứu nếu phù hợp.

Trong y học có bốn giới tính: nam, nữ, không xác định và không rõ. Bạn có thể không cần cả bốn nhưng chắc chắn bạn cần 1, 2 và 4. Không phù hợp để có giá trị mặc định cho kiểu dữ liệu này. Thậm chí ít hơn để coi nó là Boolean với trạng thái 'là' và 'không'.

Một Int(hoặc TinyInt) liên kết với một Enumlĩnh vực sẽ là phương pháp của tôi.

Đầu tiên, nếu bạn có một bittrường duy nhất trong cơ sở dữ liệu, hàng vẫn sẽ sử dụng một byte đầy đủ, cho đến khi tiết kiệm không gian, nó chỉ trả hết nếu bạn có nhiều bittrường.

Thứ hai, chuỗi / ký tự có cảm giác "giá trị ma thuật" đối với chúng, bất kể chúng có vẻ rõ ràng như thế nào tại thời điểm thiết kế. Chưa kể, nó cho phép mọi người lưu trữ bất kỳ giá trị nào mà họ không nhất thiết phải ánh xạ tới bất kỳ thứ gì rõ ràng.

Thứ ba, một giá trị số dễ dàng hơn nhiều (và thực hành tốt hơn) để tạo bảng tra cứu, để thực thi tính toàn vẹn tham chiếu và có thể tương quan 1-1 với enum, do đó, có sự tương đương trong việc lưu trữ giá trị trong bộ nhớ ứng dụng hoặc trong cơ sở dữ liệu.

Tôi sử dụng char 'f', 'm' và 'u' vì tôi phỏng đoán giới tính từ tên, giọng nói và cuộc trò chuyện và đôi khi không biết giới tính. Quyết định cuối cùng là ý kiến ​​của họ.

Nó thực sự phụ thuộc vào mức độ bạn biết người đó và liệu tiêu chí của bạn là hình thức vật lý hay bản sắc cá nhân. Một nhà tâm lý học có thể cần các lựa chọn bổ sung - chuyển sang nữ, chuyển sang nam, chuyển sang nữ, chuyển sang nam, lưỡng tính và chưa quyết định. Với 9 tùy chọn, không được xác định rõ ràng bởi một ký tự, tôi có thể đi theo lời khuyên của Hugo về số nguyên nhỏ.

Tùy chọn 3 là đặt cược tốt nhất của bạn, nhưng không phải tất cả các công cụ DB đều có loại "bit". Nếu bạn không có một chút, thì TinyINT sẽ là lựa chọn tốt nhất của bạn.

CREATE TABLE Admission (
    Rno INT PRIMARY KEY AUTO_INCREMENT,
    Name VARCHAR(25) NOT NULL,
    Gender ENUM('M','F'),
    Boolean_Valu boolean,
    Dob Date,
    Fees numeric(7,2) NOT NULL
);




insert into Admission (Name,Gender,Boolean_Valu,Dob,Fees)values('Raj','M',true,'1990-07-12',50000);
insert into Admission (Name,Gender,Boolean_Valu,Dob,Fees)values('Rani','F',false,'1994-05-10',15000);
select * from admission;

nhập mô tả liên kết ở đây

Tôi sẽ đi với Tùy chọn 3 nhưng nhiều cột bit NON NULLABLE thay vì một cột. IsMale (1 = Có / 0 = Không) IsFirting (1 = Có / 0 = Không)

if requried: IsUn UnknownGender (1 = Có / 0 = Không), v.v.

Điều này giúp dễ đọc các định nghĩa, dễ mở rộng, dễ lập trình, không có khả năng sử dụng các giá trị bên ngoài miền và không yêu cầu bảng tra cứu thứ hai + các ràng buộc FK hoặc CHECK để khóa các giá trị.

EDIT: Sửa chữa, bạn cần ít nhất một ràng buộc để đảm bảo các cờ thiết lập là hợp lệ.