持续更新 【筑基之石】DBA成长之路-数据库设计避坑之路( 二 )


怎么样, 有没有感觉这个世界很魔幻, 魔幻在于我们在开发中要求数据库和class一 一对应 (心想: 尼玛, 我TM像做梦一样)
所以笔者的解决想法是, 既然互相冲突, 所幸不如换一种标识方式, 想了很久决定采用后缀命名
好处是:
1.至少我们看到这个后缀 本能想到它是个状态字段 或者 枚举字段, 其实想想 其实也是一种枚举, 当然数据库这里应该是类型
2. 有效避免RPC逆向解析问题
笔者自我研究的思路 诸位随意哈
避免保留字
这也是笔者在开发早起开发过程中遇到的问题, 当时是因为desc这个字段, 从命名上似乎并没有什么问题, 但是插入数据库的时候频繁报错, 查询度娘才知道 它是MYSQL的保留字 早起笔者都是手写sql创建表 所以没有加``的习惯, 导致出错, 现在有些工具已经能够识别这些问题 并帮我们自动解决
但是最好还是避免使用desc这样的字段 而应该采用全称!
3. 索引设计
在海量存储的情况下,索引设计太重要了,一个好的索引能让你的应用程序健步如飞 。
在建立表的时候,在未来具备一定增长的业务表是一定要给 和 添加索引,不单单考虑后续业务逻辑判断,更要考虑后续统计、甚至数据库大表归档时有备无患,尽管可以亡羊补牢,但就好比及时治病一样,前后总是有区别,说到底就是耗时问题 。千万级的大表建立索引可不是好差事 。除了1所说的必要索引,你的索引创建应该基于一定历史查询统计得出结论,而不是因为某一次数据库慢了,就简单认为是数据体量的问题 。最后
上面就是笔者从开始设计数据库历程中的一些真实坎坷, 希望能帮助到大家及时避坑,
这篇将持续为大家更新, 其中第六步骤还需笔者一些经验磨练 方能给出满意的结论, 老规矩 莫要白嫖 !