sql建表经验总结——主要是建表现象

在建表方面你都有哪些感悟？

见过的建表的一些现象：

1，一对多业务，有时候在主表见一个字段xxIds,然后存多表的id，多个英文逗号隔开，不知道这样好不好？

2，大部分字段建成varchar(50)，反正现在空间不珍贵了（相对而言），不管name，还是描述，不算事分类名还是别名……

3，时间类型建成varchar(20)，这样见的好处大概是转json时不会被转成事件戳了，啥数据都能被存储进去？

4，钱数据被建成varchar（20），数据不会丢失了？反正也不在数据库计算，不知道为啥这样见？

5，tinyint见到的很少，都是直接用int？其实取值范围很小，只有那么几个。

6，索引要不建一大堆，要不完全不见？

7，很多时候都很纠结，一对多的列表查询时，该如何查，关联多表数据吧，数据会重复，不关联吧，列表又要展示,你们都是咋查询的？

8，时间范围查询，不转类型也能查询，数据库都帮你转好了？耗费性能，性能很难被察觉阿……

9，存储过程一写几百行，用的时候真好用，改的时候不好改，到底该怎么权衡，总是很难办，随波逐流吧……

11，视图到底还能不能用到索引，是不被关注的，这个问题一直没搞清楚啊，网上说是不会用到……

12，一对多还好，很常见，多对多数据量真恐怖啊，有时候反复分析，好不容易转为一对多，但是有时候针对是灾难阿……

13，convert xml配合outer apply写的sql好难看啊，不知道性能如何呢，反正数据是查到了……

14，stuff写起来还是不顺手啊，可是客户希望拼起来，也没有办法啊，拼多了感觉stuff函数好强大啊……

15，over函数不要太强大啊，除了分页使用，还有好多用法，都不怎么用，但是进行分组排序真的好用，有时候。

16，group by 后having过滤往往被忽略，可是配合having再配合聚合函数用，有时候很方便。

17，with t as上下文表达式，大部分数据库都支持，有时候大大简化了sql的清晰度。

可能有时候见的不规范建表的现象多了，往往变麻木，然后很多字段的长度都建的长一点，varchar（50）、varchar（100）到处都是，很难评价啊……

只是罗列了自己看到的一些现象，希望大家批评指正，在评论中可以写下您的见解，我整理下，大家共同进步。

巴特西