我正在建立一个非常小的MySQL数据库,存储,名字,姓氏,电子邮件和电话号码,我很难找到每个字段的“完美”数据类型。我知道没有一个完美的答案,但必须有一些常见的常用惯例,例如这些。例如,我已经确定一个未格式化的美国电话号码太大而无法存储为unsigned int,它必须至少是一个bigint。
因为我相信其他人可能会觉得这很有用,所以我不想把我的问题限制在我上面提到的字段中。
哪些数据类型适用于常见数据库字段?电话号码,电子邮件和地址等字段?
答案 0 :(得分:66)
有人会发布一个比这更好的答案,但只是想说明个人我永远不会在任何类型的整数字段中存储电话号码,主要是因为:
总的来说,我似乎几乎只使用:
当然也有例外,但我发现它涵盖了大多数可能性。
答案 1 :(得分:34)
以下是我使用的一些常见数据类型(虽然我不是专业人士):
| Column | Data type | Note
| ---------------- | ------------- | -------------------------------------
| id | INTEGER | AUTO_INCREMENT, UNSIGNED |
| uuid | CHAR(36) | or CHAR(16) binary |
| title | VARCHAR(255) | |
| full name | VARCHAR(70) | |
| gender | TINYINT | UNSIGNED |
| description | TINYTEXT | often may not be enough, use TEXT
instead
| post body | TEXT | |
| email | VARCHAR(255) | |
| url | VARCHAR(2083) | MySQL version < 5.0.3 - use TEXT |
| salt | CHAR(x) | randomly generated string, usually of
fixed length (x)
| digest (md5) | CHAR(32) | |
| phone number | VARCHAR(20) | |
| US zip code | CHAR(5) | Use CHAR(10) if you store extended
codes
| US/Canada p.code | CHAR(6) | |
| file path | VARCHAR(255) | |
| 5-star rating | DECIMAL(3,2) | UNSIGNED |
| price | DECIMAL(10,2) | UNSIGNED |
| date (creation) | DATE/DATETIME | usually displayed as initial date of
a post |
| date (tracking) | TIMESTAMP | can be used for tracking changes in a
post |
| tags, categories | TINYTEXT | comma separated values * |
| status | TINYINT(1) | 1 – published, 0 – unpublished, … You
can also use ENUM for human-readable
values
| json data | JSON | or LONGTEXT
答案 2 :(得分:14)
根据我的经验,名字/姓氏字段应至少为48个字符 - 来自马来西亚或印度等一些国家的名称已经很长。
电话号码和邮政编码应始终视为文字,而不是数字。给出的正常理由是有一些以0开头的邮政编码,在某些国家,电话号码也可以从0开始。但真正的原因是它们不是数字 - 它们是标识符恰好由数字组成(并且忽略像加拿大这样的邮政编码中包含字母的国家/地区)。所以将它们存储在文本字段中。
在MySQL中,您可以将VARCHAR字段用于此类信息。虽然它听起来很懒惰,但这意味着你不必太在意正确的最小尺寸。
答案 3 :(得分:8)
由于您将要处理可变长度的数据(名称,电子邮件地址),因此您需要使用VARCHAR。 VARCHAR字段占用的空间量为[field length]
+ 1个字节,最大长度为255,所以我不会太担心找到一个完美的大小。看看你想象的可能是最长的长度,然后加倍并将其设置为VARCHAR限制。那说......:
我通常将电子邮件字段设置为VARCHAR(100) - 我还没有提出问题。名称我设置为VARCHAR(50)。
正如其他人所说,电话号码和邮政编码实际上并不是数字值,它们是包含数字0-9(有时甚至更多!)的字符串,因此您应该将它们视为字符串。 VARCHAR(20)应该足够了。
请注意,如果您要将电话号码存储为整数,许多系统会假设以0开头的数字是八进制(基数为8)!因此,完全有效的电话号码“0731602412”将以十进制数字“124192010”进入您的数据库!!
答案 4 :(得分:1)
我正在做同样的事情,这就是我所做的。
我使用单独的表来表示名称,地址,电子邮件和数字,每个表都有一个NameID列,它是除Name表之外的所有内容的外键,它是主要的群集密钥。我使用MainName和FirstName而不是LastName和FirstName来允许商业条目和个人条目,但您可能不需要。
NameID列在所有表中都是一个smallint因为我相当肯定我不会超过32000个条目。几乎所有其他东西都是varchar(n),范围从20到200,具体取决于你想要存储的东西(生日,评论,电子邮件,很长的名字)。这实际上取决于你存储的是什么类型的东西。
Numbers表是我偏离的地方。我将其设置为五列,分别标记为NameID,Phone#,CountryCode,Extension和PhoneType。我已经讨论了NameID。 Phone#是varchar(12),其检查约束如下所示:CHECK(Phone#like'[0-9] [0-9] [0-9] - [0-9] [0-9] [0 -9] - [0-9] [0-9] [0-9] [0-9]“)。这确保了只有我想要的东西才能进入数据库并且数据保持非常一致。扩展名和国家/地区代码我称之为可为空的smallint,但如果您愿意,那些可以是varchar。 PhoneType是varchar(20)并且不可为空。
希望这有帮助!
答案 5 :(得分:0)
使用:INT(11)
。
MySQL indexes 将能够以最快的速度解析 int 列表。
使用:BINARY(x)
或 BLOB(x)
。
您可以直接在 BINARY(x) 或 BLOB(x) 中以十六进制形式存储安全令牌等。要从 binary
-type 中检索,请使用 SELECT HEX(field)...
或 SELECT ... WHERE field = UNHEX("ABCD....")
。
使用:DATETIME
、DATE
或 TIME
。
如果您需要同时存储日期和时间(而不是一对字段),请始终使用 DATETIME
,因为 DATETIME
索引更适合 MySQL 中的日期比较。
使用:BIT(1)
(仅限 MySQL 8。)否则,使用 BOOLEAN(1)
。
BOOLEAN
实际上只是 TINYINT(1)
的别名,它实际上存储 0 到 255(不完全是真/假,是吗?)。
使用:INT(11)
。
VARCHAR 或其他类型的字段不适用于 SUM()
等函数。
使用:文本。
最大限制为 65,535。
使用:MEDIUMTEXT。
最大限制为 16,777,215。
使用:长文本。
最大限制为 4,294,967,295。
使用:VARCHAR(255)
。
UTF-8 字符每个可见字符可以占用三个字符,并且某些文化不区分名字和姓氏。此外,文化可能对哪个名字是first 和哪个名字是last 存在分歧。您应该将这些字段命名为 Person.GivenName
和 Person.FamilyName
。
使用:VARCHAR(256)
。
电子邮件路径的定义是在 1982 年的 RFC821 中设置的。电子邮件的最大限制是在 2001 年由 RFC2821 设置的,这些限制在 {{ 3}} 于 2008 年。(请参阅部分:4.5.3.1. 大小限制和最小值。)RFC5321 于 2004 年发布,错误地将电子邮件地址限制引用为 320
个字符,但这是一个“信息-only" RFC 根据其介绍明确“没有定义标准”,因此请忽略它。
使用:VARCHAR(255)
。
您永远不知道电话号码何时会以“1800...”、“1-800”或“1-(800)”的形式出现,或者以“ext. 42”结尾,或“找苏珊”。
使用:VARCHAR(10)
。
您将获得 12345
或 12345-6789
之类的数据。使用验证来清理此输入。
使用:VARCHAR(2000)
。
官方标准支持比这更长的 URL,但很少有现代浏览器支持超过 2,000 个字符的 URL。见RFC3696
使用:DECIMAL(11,2)
。
它上升到 11。