那天赶上市院的临时抽查，要找十年前一批涉农村信用社的借贷旧案做统计。老庭长点了三次刷新，屏幕都卡在那转。烟蒂扔了半烟灰缸，最后还是翻了仓库里堆了半间房的纸质卷，才凑齐材料。
为啥这么慢？数据库结构烂的呗。
早年法院的数据库，全是凑活出来的烂摊子
那时候刚有电脑，懂技术的人少，做数据库的都是外边找的外包，根本没人问我们办案的法官要啥需求。
你猜他们咋做？把案由、当事人名字往一个字段里一塞，完事儿。同一个民间借贷，张书记员输「民间借贷」，李书记员输「个人借贷纠纷」，王书记员图省事直接输「欠钱」，你搜的时候啥都出不来。
更可笑的是结构拆分，把当事人身份证号拆去了信息表，案由拆去了分类表，年份拆去了归档表，你要查个「2015年本地做房东的租赁合同纠纷」，得三张表串起来找，慢不说，还经常串错数据，把被告的信息安原告头上。
数据库结构优化，到底优化的是啥？
说实话，很多搞技术的小伙子听不懂我们的需求，上来就说要符合第三范式，要拆分得干干净净，结果用的时候死慢。
我们要的不是教科书上的标准结构，是能一分钟调出我们要的案子。
现在案件量一年比一年大，我们一个基层院一年小一万件新案，二十年攒下来小二十万件，原来的旧结构撑不住，优化就是改几个最要命的地方。
第一，把法官常用的查询字段提前整合，别拆得七零八落。第二，给常用的搜索字段建合适的索引，就像你书前面的目录，翻的时候直接找，不用一页一页翻。第三，把没人用的旧数据挪去冷存储，别占着主库的位置拖速度。
我前几年听过一个笑话，某个区院搞优化，花了几百万重新做结构，结果优化完调卷比原来还慢三分钟，为啥？为了符合标准，把所有字段全拆了，每次查询都要联五六个表，能不慢吗？
我攒的几个土办法，都是踩坑踩出来的
这些年我帮院里对接过好几次数据库升级，给管这事的老伙计总结了几条，好用。
1. 常用查询字段别乱拆，放主表不丢人
别听什么纯理论的范式要求，我们办案的只要搜得快，牺牲一点冗余空间根本不算事。
2. 超过十年办结的旧案，自动挪冷存储
除了偶尔调卷复查，没人天天翻十年前的老案，占着主库空间拖速度完全没必要。
3. 所有可标准化的字段，全部做成下拉选择
别让书记员随便打字输案由，统一选现成的，就不会出现同一个案由七八个写法的破事。
4. 优化先试跑再全量更新，别上来就动全库
先拿一个庭的几千件案子试半个月，没问题再推全院，上来就改全库，出了错谁都担不起。
其实说来说去，不管是法院的案子数据库，还是别的什么行业的数据库，结构优化的核心都一样，就是给谁用，就照着谁的需求改。
别搞花架子，别拿教科书压人，能用、好用，就是好的优化。
当年那个把老庭长逼得抽半包烟的破数据库，早就换了。现在年轻人哪懂那种等十分钟出不来结果的焦虑，也就我们这些老家伙，还记得这些破坑罢了。
