我正在使用一些数据库抽象层,其中大多数都使用诸如“String”之类的属性,它是 VARCHAR 250 或长度为 11 位的 INTEGER。但例如,我有一些长度少于 250 个字符的东西。我应该去减少它吗?它真的有什么有价值的区别吗?
提前致谢!
我正在使用一些数据库抽象层,其中大多数都使用诸如“String”之类的属性,它是 VARCHAR 250 或长度为 11 位的 INTEGER。但例如,我有一些长度少于 250 个字符的东西。我应该去减少它吗?它真的有什么有价值的区别吗?
提前致谢!
INT 长度什么都不做。所有 INT 都是 4 个字节。您可以设置的数字仅用于zerofill
(以及谁使用它!?)。
VARCHAR 长度做得更多。这是字段的最大长度。保存 VARCHAR 以便仅存储实际数据,因此长度无关紧要。如今,您可以拥有大于 255 个字节(即 256^2-1)的 VARCHAR。不同之处在于用于字段长度的字节。VARCHAR(100) 和 VARCHAR(8) 和 VARCHAR(255) 使用 1 个字节来保存字段长度。VARCHAR(1000) 使用 2。
希望有帮助=)
编辑
我几乎总是让我的 VARCHARs 250 长。无论如何,应在应用程序中检查实际长度。对于更大的字段,我使用 TEXT (并且这些字段的存储方式不同,因此可以长得多)。
编辑
我不知道这是最新的,但它曾经帮助我(理解):http ://help.scibit.com/Mascon/masconMySQL_Field_Types.html
首先,请记住,数据库旨在存储事实,旨在保护自己免受不良数据的侵害。因此,您不想让用户输入 250 个字符作为名字的原因是用户会在其中放入不是名字的所有类型的数据。他们会写上他们的全名、内衣尺码、一本关于他们去年夏天干了什么的小说等等。因此,您要努力确保数据尽可能正确。假设应用程序是防止不良数据的唯一保护者是错误的。您希望用户告诉您,他们在将War in Peace填充到给定列中时遇到了问题。
因此,最重要的问题是,“存储的数据最合适的值是多少?” 理想情况下,您将使用一个int
和一个检查约束来确保值具有适当的范围(例如,大于零、小于十亿等)。不幸的是,这是 MySQL 最大的弱点之一:它不遵守检查约束。这仅仅意味着您必须在触发器中实施这些完整性检查,这无疑更麻烦。
(4 字节)之间的int
差异会对tinyint
(1 字节)产生明显的影响吗?显然,这取决于数据量。如果您的行数不超过 10 行,答案显然是否定的。如果您将有 100 亿行,那么答案显然是“是”。但是,IMO,这是过早的优化。首先专注于确保正确性要好得多。
对于文本,您应该询问您的数据是否应该支持中文、日文或非 ANSI 值(即,您应该使用 nvarchar 还是 varchar)?该值是否代表真实世界的代码,如货币代码或具有特定规范的银行代码?
在 MySQL 中不太确定,但在 MS SQL 中,它只对足够大的数据库产生影响。通常,我喜欢使用较小的字段来 a) 节省空间(养成良好的习惯永远不会有坏处)和 b) 用于隐含验证(如果您知道某个字段不应超过 10 个字符,为什么要允许 11 个字符,让仅250?)。
我认为 Rudie 是错误的,并不是所有的 INT 都是 4 个字节......在 MySQL 中你有:
tinyint = 1 字节,smallint = 2 字节,mediumint = 3 字节,int = 4 字节,bigint = 8 字节。
我认为 Rudie 指的是“显示与”,即您在创建列时放在括号之间的数字,例如:
年龄 INT(3)
你告诉 RDBMS 只显示不超过 3 个数字。
并且 VARCHAR 是(可变长度字符字符串),因此如果您声明名称 varchar(5000) 并存储像“Mario”这样的名称,则您只使用 7 个字节(5 个字节用于数据,2 个字节用于值的长度)。
正确的字段大小用于限制可以放入的错误数据。例如,假设您有一个电话号码字段。如果您允许 250 个字符,您通常会在电话字段中看到类似以下内容(不是随机抽取的示例):
Call the good-looking blonde secretary instead.
因此,首先限制长度是我们执行数据完整性规则的一部分。因此,这是至关重要的。
其次,数据页上只有这么多空间,虽然一些数据库允许您创建潜在记录长于数据页宽度的表,但在存储数据时它们通常不允许您实际超过它。当突然无法保存一条记录时,这可能会导致一些很难找到的错误。我不知道 MySql 以及它是否会这样做,但我知道 SQL Server 会这样做,而且很难找出问题所在。因此,使数据具有正确的大小对于防止错误至关重要。