我希望将用户的性别存储在数据库中,并尽可能降低(大小/性能)成本。
到目前为止,我想到了3种情景
我问的原因是因为这个answer提到字符 小于而不是布尔。
我应该澄清我正在使用MS SQL 2008,其中 DOES 实际上具有位数据类型。
答案 0 :(得分:164)
已经有ISO标准;无需发明自己的方案:
http://en.wikipedia.org/wiki/ISO_5218
根据标准,该列应该被称为“Sex”,而“最接近”的数据类型将是tinyint,并且具有CHECK约束或查找表。
答案 1 :(得分:74)
我将该栏目称为“性别”。
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
可以排除BIT数据类型,因为它只支持两种可能不合适的性别。虽然INT支持两个以上的选项,但需要4个字节 - 使用更小/更窄的数据类型时性能会更好。
CHAR(1)
的边缘超过TinyINT - 两者都采用相同的字节数,但CHAR提供的数值更为狭窄。使用CHAR(1)
将使用“m”,“f”等自然键,而不是使用被称为代理/人工键的数字数据。如果需要移植,任何数据库也支持CHAR(1)
。
我会使用选项2:CHAR(1)。
性别列的索引可能会 不 帮助,因为低基数列的索引中没有值。意思是,索引的值没有足够的多样性来提供任何值。
答案 2 :(得分:40)
在医学中,有四种性别:男性,女性,不确定和未知。您可能不需要全部四个,但您肯定需要1,2和4.具有此数据类型的默认值是不合适的。甚至更少将它视为具有'is'和'is not'状态的布尔值。
答案 3 :(得分:3)
与Int
字段对齐的TinyInt
(或Enum
)将成为我的方法。
首先,如果数据库中只有一个bit
字段,该行仍将使用完整字节,因此,只要节省空间,只有多个bit
字段才能获得回报
其次,字符串/字符对他们有“神奇的价值”感觉,无论他们在设计时看起来多么明显。更不用说,它可以让人们存储他们不一定会映射到任何明显的任何价值。
第三,数值更容易(并且更好的做法)创建查找表,以便强制执行参照完整性,并且可以将1对1与枚举关联,因此存储值时存在奇偶校验在应用程序或数据库中的内存中。
答案 4 :(得分:3)
我使用char'f','m'和'u'因为我从名字,声音和谈话中推测出性别,有时候不知道性别。最终的决定是他们的意见。
这取决于您对这个人的了解程度以及您的标准是物理形式还是个人身份。心理学家可能需要额外的选择 - 交叉到女性,交叉到男性,转换为女性,转换为男性,雌雄同体和未定。有9个选项,没有明确的单个字符定义,我可能会选择Hugo的小整数建议。
答案 5 :(得分:1)
选项3是您最好的选择,但并非所有数据库引擎都具有“位”类型。如果你没有一点,那么TinyINT将是你最好的选择。
答案 6 :(得分:-3)
我会使用选项3但是多个NON NULLABLE位列而不是一个。 IsMale(1 =是/ 0 =否) IsFemale(1 =是/ 0 =否)
如果需要: IsUnknownGender(1 =是/ 0 =否) 等等...
这样可以轻松读取定义,易于扩展,易于编程,不可能使用域外的值,也不需要第二个查找表+ FK或CHECK约束来锁定值。
答案 7 :(得分:-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;