124

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 charsnhỏ 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.

|
  • 1

    FWIW, câu hỏi SO mà bạn tham chiếu đề cập đến cách .NET thể hiện các loại này trong bộ nhớ. Nó không liên quan gì đến cách SQL Server thể hiện chúng. bit <= char. msdn.microsoft.com/en-us/l Library / ms177603.aspx

    – Bùi Trung Nghĩa 16:57:59 14/11/2010
  • 4

    Cũng đáng xem xét: không hỏi người dùng về giới tính và / hoặc giới tính của họ ở nơi đầu tiên. Bạn có thể không thực sự cần nó. Nhưng nếu bạn làm thế, đừng quên rằng giới tính không phải là nhị phân. Một số người sẽ không muốn chọn M hoặc F, vì không áp dụng cho họ (hoàn toàn hoặc hoàn toàn) và / hoặc họ không muốn nói với bạn. Đó là năm 2018; nếu bạn cần câu trả lời cho câu hỏi này, có lẽ bạn nên tìm kiếm một số cách thực hành tốt nhất để bao gồm và xử lý giới tính không nhị phân trong giao diện người dùng, nếu bạn chưa có. Sau đó tìm ra những mã bạn muốn sử dụng.

    – Tạ Thùy Dung 08:28:45 02/05/2018
  • 1

    Bạn đang sử dụng lĩnh vực giới tính để làm gì? Nó có thể chỉ là một chuỗi, vì vậy mọi người có thể nhập những gì họ thích? Cố gắng liệt kê tất cả các câu trả lời có thể cho câu hỏi này sẽ rất khó khăn.

    – Hoàng Thanh Vinh 10:43:40 31/05/2018
  • @PeterCordes Tôi không mua giải pháp đa giới. Nếu đó là thời trang, nó không phải là một giải pháp khả thi theo thời gian. Tôi sẽ giữ nó nhị phân hoặc ternary giống như cách người dùng sẽ làm nếu mọi người không muốn trả lời hoặc thay đổi nó để sexnó không thay đổi. Nhưng có lẽ tôi là một người quá quê mùa, những người không biết về những sáng tạo đô thị mới của năm 2018.

    – Phan Kim Khánh 19:40:00 21/08/2018
  • @ThePasbah: Tôi nghĩ rằng tùy chọn thông thường về cơ bản là m / f / khác, vì vậy, vernary như bạn đề nghị là tốt. Bạn có thể muốn phân biệt "khác" với "không xác định" (như trong "Tôi không nói" và / hoặc "chúng tôi chưa hỏi người dùng"). Tôi không biết những người có giới tính muốn có giá trị dấu phẩy động với thanh trượt họ có thể đặt mỗi ngày; Tôi đoán là hầu hết trong số họ (và những người không có giới tính truyền thống khác) sẽ rất vui khi chọn "khác" hoặc "không xác định" trên hầu hết mọi trang web. Nhưng không, tôi không nghĩ yêu cầu "sex" thay vì "giới tính" sẽ là một ý tưởng hay.

    – Trần Minh Kỳ 19:52:25 21/08/2018
73

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 phím 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.

|
  • 1

    Bất kỳ tài liệu tham khảo để thực hiện? Tôi biết rằng nó gần như tối ưu hóa vi mô mà tôi không nên làm, nhưng đó là thức ăn cho tâm trí tò mò của tôi.

    – Dương Xuân Lan 02:32:20 14/11/2010
  • 1

    Cảm ơn @OMG Ponies, còn hiệu suất thì sao? Một char sẽ tốn kém hơn một chút trong trường hợp này?

    – Hồ Quỳnh Nga 02:45:10 14/11/2010
  • 1

    @Marko: Như tôi đã nói trước đây, họ bằng nhau. Nhưng một chỉ mục 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.

    – Tạ Ðức Anh 02:49:35 14/11/2010
  • 1

    Tôi tự hỏi tại sao không đề cập đến ENUM

    – Tạ Danh Thành 11:52:47 05/08/2014
  • 1

    Hiệu suất thực sự sẽ được sử dụng tốt hơn bao nhiêu , giả sử, kiểu dữ liệu 4 byte trên nền tảng 64 bit? Chỉ cần nói ... ;-)

    – Hoàng Phước Huệ 20:12:05 13/04/2016
163

Đã 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à kiểu 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.

|
  • 1

    Tại sao nó bỏ qua đến 9 cho 'không áp dụng'? Còn 3-8 thì sao?

    – Trịnh Khánh Hoàn 06:49:03 05/06/2015
  • 1

    Đây là cho tình dục. OP đặc biệt yêu cầu giới tính. Giới tính và giới có thể có các giá trị khác nhau có thể cần phải được nắm bắt.

    – Tạ Vương Việt 20:21:10 15/10/2015
  • 1

    @indigochild OP sử dụng cả hai từ trong tiêu đề câu hỏi và rõ ràng coi chúng là tương đương, ít nhất là cho trường hợp sử dụng của mình (YMMV). Quan điểm của tôi đơn giản là một tiêu chuẩn ISO tồn tại trong lĩnh vực này và bạn không bao giờ nên lãng phí thời gian vào việc đưa ra kế hoạch của riêng mình khi một tiêu chuẩn chính thức tồn tại. Tất nhiên trừ khi tiêu chuẩn đó không bao gồm trường hợp cụ thể của bạn, điều này là hoàn toàn có thể.

    – Phạm Phúc Ðiền 14:54:24 17/10/2015
  • 1

    Đây phải là câu trả lời được chấp nhận. Nó tập trung vào tính toàn vẹn dữ liệu (là ~ mãi mãi) thay vì tối ưu hóa (là tình huống).

    – Tạ Minh Tuyết 16:03:51 31/10/2015
  • 1

    @Zuko Rời khỏi phòng trong đặc điểm kỹ thuật cho các bổ sung trong tương lai ...

    – Trịnh Xuân Thảo 17:20:26 26/06/2016
40

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'.

|
5
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

|
3

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 = Yes / 0 = No), 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ị.

|
3

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ỏ.

|
3

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 vào 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.

|
1

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.

|

Câu trả lời của bạn (> 20 ký tự)

Bằng cách click "Đăng trả lời", bạn đồng ý với Điều khoản dịch vụ, Chính sách bảo mật and Chính sách cookie của chúng tôi.

Không tìm thấy câu trả lời bạn tìm kiếm? Duyệt qua các câu hỏi được gắn thẻ hoặc hỏi câu hỏi của bạn.