在数据库建表方面你都有哪些感悟和理解？
在最常用场景你有哪些查询疑惑？
下面说说自己工作中的遇到的一些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）到处都是，很难决断啊……
本文罗列了自己看到的，一些sql建表现象，以及sql使用的疑惑。希望大家批评指正，在评论中写下您的见解，我将整理下，放到文章末尾，以期大家共同进步。