在資料庫建表方面你都有哪些感悟和理解？

在最常用場景你有哪些查詢疑惑？

下面說說自己工作中的遇到的一些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使用的疑惑。希望大家批評指正，在評論中寫下您的見解，我將整理下，放到文章末尾，以期大家共同進步。