数据库设计表的时候把不管啥字段类型都设置为 varchar，有啥好处嘛

[zanelee]

[dqzcwxb]

非常精准的体现了自己的技术水平

[FYFX]

这样还不够，最好字段名称是 str1,str2,...

[T0m008]

没啥好处，懒呗

[wd]

好处就是啥都可以存进去

[looking0truth]

用 text 吧，var 还有限制 /dog

[Jooooooooo]

偷懒了

某些情况下是有点好处, 比如你订单弄成 long, 哪天里面想加点字符就搞不定了.

[masker]

高性能 MySQL ？

[rockyliang]

好处没想到，坏处倒是有，举个简单的例子，假设你用 varchar 来存储数字，并且需要排序的时候，会发现排不了

[815979670]

可能是培训班出来的，我们老师当时说 不会选引擎就选 innodb 不会选字段就选 varchar

[yedanten]

补充一下坏处，时间也用 varchar 存，那按时间区间查询也不能简单的直接><=between 。
坏处随便想想就有不少，好处除了存数据方便不用脑子反正不会报错，想不出其他的

[liaohongxing]

pg 用 varchar 没问题 ，pg 的 varchar 和 text 几乎一样，都能存大文本

[westoy]

梭哈流建议直接 json

[pytth]

排序需要用 int ，时间用 timestamp ，内容多用 text ，其他用 varchar ，基本够用了。

[lithiumii]

好处不如别设计了，换 no sql 吧，爱啥字段啥类型就啥

[bigbigpark]

可以多加班

[hjosama200]

梭哈流直接 json+1 ，懒得设计复杂的数据库表结构，一个 json ，能解决太多问题了，项目里面就喜欢直接存 json ，不设计复杂的表结构。

[XCFOX]

这边建议直接用 MongoDB

[nobody1234]

也要看使用场景，某些场景就是可接受的，甚至是推荐的。比如做 ELT 数仓，第一步就是将数据拉取过来，在无法保证上游数据质量的情况下，落地 Staging 层的表就可以全用 varchar ，之后再慢慢清洗。varchar 虽然耗空间，但数据兼容性不错

[raptor]

sqlite 很多类型实际都是用 varchar 存的。

SAP 的大部分字段都是用 CHAR 类型。

归根到底要看实际情况需要。

[luotuoxiaohui]

我也是，但是为什么让我养成了这个习惯，客户改需求导致，做好后这个位置改一下，不要这个换另外一个内容，然后又换，又换，，，，，换了后数据库这边格式没有改过来的话就蹦了，其他的调用了这个的话，又要改，但是改成 var 的话，只需要改前端就好了，反正都适配，一个字 方便