這個怎麼說呢，其實也有用y和n的，甚至有用success的，感覺有點亂，有個統一的標準還是好事，起碼乙個產品或者乙個系列的東西應該在這一點上是統一的
雖然說這個大小寫敏感的配置是可以修改的，但還是統一小寫比較好，不像oracle
注意有些"複數"表名其實是單詞的本義，並不是複數
之前也有用欄位名_u1,欄位名_n1這樣的，具體還是看公司規範吧
decimal對應dto中的bigdecimal，搭配使用
比如性別這種的字段
有時候可能還會加一些樂觀鎖欄位、建立人、最後修改人字段等，也看具體的公司吧
有的公司可能會再加個模組名什麼的
庫名、應用名、服務名什麼的，但凡是一對一的無歧義的情況下，保持一致是最好的選擇
下拉框對應的之類的字段，前台增加的時候，最好後台也更新(一些較為靈活和不確定的字段除外)
所以說，正規化不是絕對的，具體情況具體分析
表的設計要貼合實際的業務場景和產品需要，這個其實才是最關鍵的，合理的設計與拆分，能避免很多效率的問題
關於索引我之前總結過一遍部落格
從一條查詢sql執行過程了解mysql索引
其實就是從資料庫層面，最基本的層面來保證資料的唯一性。但是建組合索引的時候，也要注意順序
實際業務中，還是有不少超過三表的，只能說這是乙個美好的願景吧，起碼從設計階段就要設計好，不然的話超過三張表是避免不了的，除非把有關聯關係的表強行拆開，既不符合業務邏輯也達不到太大的優化作用
大部分的索引前面一部分的長度就能夠有很好的區分度了。
通過減小索引長度，這樣能夠減小索引檔案的大小，能夠加快資料的insert。
乙個varchar欄位索引區分度的例子
關於搜尋引擎的簡單概念，看過乙個回答，簡單來說資料庫只能做到右模糊，其他情況就走不了索引了，如果資料量大的話，那麼這樣的查詢會很慢，是不能接受的。所以推薦使用搜尋引擎，搜尋引擎不光可以實現左模糊全模糊，甚至包括了一些查詢改寫、自動糾錯等。當然這些和查詢演算法、資料探勘有著密不可分的關係。
搜尋引擎如何做到模糊匹配
要善用explain分析執行計畫
針對varchar欄位建立索引算區分度的時候，就是用的這個。
要記住這裡ifnull是方言，如果是寫多數庫通用sql的話，需要注意下
或者是字段值 is null，不要用字段值 = null這種
所以一般分頁日誌會有兩條sql，先執行count，再執行查具體資料的
已經很久沒見有人用外來鍵了，這個只是sql初學階段的乙個概念，有助於理解表間關係的。
儲存過程+oracle這一套太笨重了
先執行select能夠判斷選定的資料範圍是否正確，不然萬一where條件有誤，就真的對資料做了錯誤的修改。此外，非正常業務流程對資料的操作，要及時的存留操作指令碼以及備份資料
阿里巴巴編碼規約學習之安全規約
乙個成熟的系統都是要專門的鑑權機制的，比如微服務中的鑑權元件，或者單體應用中的 也可以起到類似的作用，市面上的鑑權手段多樣，這裡主要是說明許可權控制的重要性。在設計的時候，就要考慮到如果有別有用心的使用者，得到了其他使用者的訪問請求，加以修改，如果沒有許可權控制的話，是容易出大事的 手機號 身份證號...
阿里巴巴編碼規約學習之異常日誌
異常一定要處理，不能捕獲以後，之列印出來什麼都不管。比如某個業務層的方法中，對乙個異常做了捕獲，catch塊僅僅是列印出了異常，這種情況下異常是不容易被發現的，也就是異常被吞掉了 如果這個時候上層方法有事務註解，甚至會和spring的事務衝突 專案中異常的幾個注意事項 空指標是乙個很常見的異常了 這...
阿里巴巴開發規約之命名風格
我下邊總結的只是我自己平時需要注意的 1.userdo而不是userdo 2.方法名，成員變數名，區域性變數名，引數名統一用lowercamelcase駝峰標識 3.常量全部大寫用下劃線隔開，並且力求語意完整，不論多長，4.boolean型別的常量不要加是字首，否則容易引起框架異常，5.為了 自解釋...