在數據庫建表方面你都有哪些感悟和理解？
在最常用場景你有哪些查詢疑惑？
下面說說自己工作中的遇到的一些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使用的疑惑。希望大家批評指正，在評論中寫下您的見解，我將整理下，放到文章末尾，以期大家共同進步。