在sql中如何知道何时使用varchar、何时使用text？
这似乎是一个非常武断的决定。 在大多数情况下，两者都可以完成同样的事情。 在我看来，限制 varchar 长度就像搬起石头砸自己的脚，因为你永远不知道需要多长的字段。
对于为字符串字段选择 VARCHAR 或 TEXT 是否有任何具体准则？
我将使用 postgresql 和 python 的 sqlalchemy orm 框架。
It seems like a very arbitrary decision.
Both can accomplish the same thing in most cases.
By limiting the varchar length seems to me like you're shooting yourself in the foot cause you never know how long of a field you will need.
Is there any specific guideline for choosing VARCHAR or TEXT for your string fields?
I will be using postgresql with the sqlalchemy orm framework for python.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
在 PostgreSQL 中，
varchar和text之间没有技术差异，您可以将
varchar(nnn)视为text具有禁止存储较大值的检查约束的列。因此，每次您想要长度约束时，请使用
varchar(nnn)。如果您不想限制数据的长度，请使用
textIn PostgreSQL there is no technical difference between
varcharandtextYou can see a
varchar(nnn)as atextcolumn with a check constraint that prohibits storing larger values.So each time you want to have a length constraint, use
varchar(nnn).If you don't want to restrict the length of the data use
text这句话是错误的：
例如，如果您要保存 MD5 哈希值，您确实知道存储的字段有多大，并且您的存储会变得更加高效。其他示例有：
This sentence is wrong:
If you are saving, for example, MD5 hashes you do know how large the field is your storing and your storage becomes more efficient. Other examples are:
简而言之：
固定 类比数组和链表，数组是固定长度的字段，链表就像varchar。数组和链表哪个更好？幸运的是我们两者都有，因为它们在不同的情况下都很有用，在这里也是如此。
In brief:
Think of an analogy to arrays and linked lists, where arrays are fixed length fields, and linked lists are like varchars. Which is better, arrays or linked lists? Lucky we have both, because they are both useful in different situations, so too here.
在大多数情况下，您确实知道字段中字符串的最大长度是多少。例如，如果是姓氏和名字，则不需要超过 255 个字符。因此，根据设计，您可以选择要使用的类型，如果您总是使用文本，则会浪费资源
In the most cases you do know what the max length of a string in a field is. In case of a first of lastname you don't need more then 255 characters for example. So by design you choose wich type to use, if you always use text you're wasting resources
查看这篇文章 PostgresOnline，它还链接到另外两篇有用的文章。
当您使用处理 TEXT 与 VARCHAR 的工具、应用程序和驱动程序时，PostgreSQL 中的大多数 TEXT 问题都会发生，因为其他数据库对这两种数据类型的行为非常不同。
Check this article on PostgresOnline, it also links to two other usefull articles.
Most problems with TEXT in PostgreSQL occur when you're using tools, applications and drivers that treat TEXT very different from VARCHAR because other databases behave very different with these two datatypes.
数据库设计者几乎总是知道一列需要容纳多少个字符。美国送货地址最多需要包含 64 个字符。 （美国邮政局发布的地址指南是这么说的。）美国邮政编码的长度为 5 个字符。
数据库设计者在指定列时会查看来自客户的代表性样本数据。她会问自己“最长的产品名称是什么？”之类的问题。当答案是“70 个字符”时，她不会将该列设置为 3000 个字符宽。
VARCHAR 在 SQL Server 中有 8k 的限制（我认为）。大多数应用程序不需要为单个列提供那么多存储空间。
Database designers almost always know how many characters a column needs to hold. US delivery addresses need to hold up to 64 characters. (The US Postal Service publishes addressing guidelines that say so.) US ZIP codes are 5 characters long.
A database designer will look at representative sample data from her clients when she's specifying columns. She'll ask herself, questions like "What's the longest product name?" And when the answer is "70 characters", she won't make the column 3000 characters wide.
VARCHAR has a limit of 8k in SQL Server (I think). Most applications don't require nearly that much storage for a single column.