@doommm 所以还是看字段量，如果字段少，这部分工作量的比重就会比较大。如果字段量很多，相对于维护这些字段，维护查表的成本要小很多。比如维护单个字段的成本系数是 10，字段查表的成本系数是 5，那成本就是 10k 与 5k+C （ k 是字段数量的某种指标，C 是维护查表方法的成本，不随字段数量增长）。那么 k 小于 2 时直接维护字段划算。k 大于 2 时建立映射表划算。
抱歉之前可能比较暴躁，主要是对你的描述里透露出的“因为抵触，认定它一定是不合理的，不愿去了解和学习”不满

又如，如果你们弄了个通用系统，要在各个项目里用到，但不同项目对相同数据的描述却不一样，编码也不同，本质上确是同一个东西，难道你要为每个子系统重新设计一套命名，然后去批量改代码里的命名？用表驱动的话就根本不需要做这种工作，直接更新表就行了。

@doommm 你的问题是学的太少抱怨太多。上万个字段的场景，而且有频繁的字段增减、字段值编码的变化，这时候单词命名是根本不够用的，你思考一下就知道这时候就得用数据库表来驱动，将字段名、字段值都放表里，人是读不懂编码的，所以还得写个映射方法去映射。

@doommm 所以才要查表啊，这得有多懒惰连查表法都不知道

@doommm 加密个铲铲，估计他自己都不懂这么做的缘由，只是照搬别人的规范而已。
这么做完全是为了维护性，代价是需要建额外的字段映射表。如果表很少，这么做确实有点多余。但是如果表很多，字段上万，这么做非常有必要。

@ilunny 至少要遍历一次数组才能知道是否有序

@q397064399 所以还是至少学一门静态学一门动态。静态有时候太束缚，动态又容易失控。使用动态语言但借鉴静态语言的一些约定是不错的思路。

国内做什么东西都内耗严重

@q397064399 py 是强类型

唉，国内这生态也 TM 好意思叫互联网

界面也是你做吗？学习一下 web 的 mvc 呀，把功能和视图分离

老是在这些细枝末节上钻，工作做完了吗？

@EvilCult if 累赘，可以去掉：
DEBUG = os.environ.get('DJANGO_DEBUG', 'False') == 'True'

如果坐实企业可以随意删除打卡记录，钉钉已经涉嫌违法了