老師公開課源碼及vip所有都在這里public表示其他名稱為日期-tom springjdbcorm

咕院（每天20：30騰訊課堂公開課）今日課程：基于SpringJDBC實(shí)現(xiàn)ORM及分庫分表咕咕打開課程安排一、什么是對(duì)象關(guān)系映射（ObjectRelationalMap二、為什么要使用ORM框架ORM框架有哪些？Hibernate全自動(dòng)、MyBatis半自動(dòng)對(duì)比（手自一體）SpringJDBC純手動(dòng)檔（設(shè)計(jì)思想Hibernate的數(shù)據(jù)庫移植性遠(yuǎn)大于Hibernate有完整的日志系統(tǒng)，Mybatis只有基本的記錄功能SQLMybatis更方便，可控性較強(qiáng)。SSM/SSHS搞定（Spring態(tài)系統(tǒng)SpringMVC/SpringJDBC/AOP/IOC/SpringData/SpringCloud/SpringBoot）三、代碼演示ORM實(shí)現(xiàn)原1、了ResultSetgetMetaData()方法和getColumnCount()2、利用反射機(jī)制掃描出實(shí)體中的注解，將實(shí)體類名和表名，屬性名和字段名關(guān)聯(lián)3、從結(jié)果集中取值并封裝實(shí)體對(duì)象四、為什么要分庫、分表數(shù)據(jù)庫中的數(shù)據(jù)量不一定是可控的，在未進(jìn)行分庫分表的情況下，隨著時(shí)間和業(yè)務(wù)的發(fā)展，庫中的表會(huì)越來越多，表中的數(shù)據(jù)量也會(huì)越來越大，相應(yīng)地，數(shù)據(jù)操作，增刪改查的開銷也會(huì)越來越大；另外，由于無法進(jìn)行分布式式部署，而一臺(tái)服務(wù)器的資源（CPU、磁盤、內(nèi)存、IO等）是有限的，最終數(shù)據(jù)庫所能承載的數(shù)據(jù)量、數(shù)據(jù)處理能力都將遭遇瓶頸。五、企業(yè)內(nèi)部框架、設(shè)計(jì)及分庫、分表操作1、單表操作實(shí)現(xiàn)2、如何設(shè)計(jì)分庫API，利用ThreadLocal動(dòng)態(tài)切換數(shù)據(jù)源3、如何設(shè)計(jì)分表API，自定義分表算法，動(dòng)態(tài)計(jì)算表名4、如何設(shè)計(jì)讀寫分離API，數(shù)據(jù)庫主從實(shí)現(xiàn)讀寫分離5、設(shè)計(jì)QueryRule類，NoSql的重要中間件6、設(shè)計(jì)常用的ORM操作API，增、刪、改、查六、淺談常用分庫分表規(guī)設(shè)計(jì)表的時(shí)候需要確定此表按照什么樣的規(guī)則進(jìn)行分庫分表。例如，當(dāng)有新用戶時(shí)，程序得確定將此用戶信息添加到哪個(gè)表中；同理，當(dāng)?shù)卿浀臅r(shí)候我們得通過用戶的賬號(hào)找到數(shù)據(jù)庫中對(duì)應(yīng)的記錄，所有的這些都需要按照某一規(guī)則進(jìn)行。路由通過分庫分表規(guī)則查找到對(duì)應(yīng)的表和庫的過程。如分庫分表的規(guī)則是user_idmod4的方式，當(dāng)用戶新了一個(gè)賬號(hào)id123,我們可以通idmod4的方式確定此賬號(hào)應(yīng)該保存到User_0003表中。當(dāng)用戶123登錄的時(shí)候，我們通過123mod4后確定記錄在User_0003。Range（范圍）–這種模式允許將數(shù)據(jù)劃分不同范圍。例如可以將一個(gè)表通過年份劃分成若干個(gè)分區(qū)。Hash（哈希）–這中模式允許通過對(duì)表的一個(gè)或多個(gè)列的HashKey進(jìn)行計(jì)算，最后通過這個(gè)Hash碼不同數(shù)值對(duì)應(yīng)的數(shù)據(jù)區(qū)域進(jìn)行分區(qū)。例如可以建立一個(gè)對(duì)表主鍵進(jìn)行分區(qū)的表。Key（鍵值）-上面Hash模式的一種延伸，這里的Hash是MySQL系統(tǒng)產(chǎn)生的。List（預(yù)定義列表）–這種模式允許系統(tǒng)通過預(yù)定義的列表的值來對(duì)數(shù)據(jù)進(jìn)行分割。七、分庫分表產(chǎn)生的問題，及注意事分庫分表維度的問題假如用戶了商品,需要將交易記錄保存取來，如果按照用戶的緯度分表，則每個(gè)用戶的交易記錄都保存在同一表中，所以很快很方便的查找到某用戶的情況，但是某商品被購買的情況則很有可能分布在多張表中，查找起來比較麻煩。反之，按照商品維度分表，可以很方便的查找到此商品的情況，但要查找到買人的交易記錄比較麻煩。所以常見的解決方式有：通過掃表的方式解決，此方法基本不可能，效率太低了。記錄兩份數(shù)據(jù)，一份按照用戶緯度分表，一份按照商品維度分表。通過搜索引擎解決，但如果實(shí)時(shí)性要求很高，又得關(guān)系到實(shí)時(shí)搜索(聚合查詢)。聯(lián)合查詢的問題聯(lián)合查詢基本不可能，因?yàn)殛P(guān)聯(lián)的表有可能不在同一數(shù)據(jù)庫中。避免跨庫事務(wù)避免在一個(gè)事務(wù)中修改db0中的表的時(shí)候同時(shí)修改中的表，一個(gè)是操作起來更復(fù)雜，效率也會(huì)有一定影響。盡量把同一組數(shù)據(jù)放到同一DB服務(wù)器上。八、總結(jié)1、ORM優(yōu)、缺點(diǎn)優(yōu)點(diǎn)：隱藏了數(shù)據(jù)細(xì)節(jié)，“封閉”的通用數(shù)據(jù)庫交互，ORM的。他使得我們的通用數(shù)據(jù)庫交互變得簡單易行，并且完全不用考慮該死的SQL語句?？焖匍_發(fā)。ORM使我們構(gòu)造數(shù)據(jù)結(jié)構(gòu)變得簡單易行缺點(diǎn)：無可避免的，自動(dòng)化意味著映射和關(guān)聯(lián)管理，代價(jià)是犧牲性能（早期，這是所有不喜歡ORM人的共同點(diǎn)）。現(xiàn)在的各種ORM框架都在嘗試使用各種方法來減輕這塊（LazyLoad，Cache），效果還是很顯著的。面向?qū)ο蟮牟樵冋Z言(X-QL)作為一種數(shù)據(jù)庫與對(duì)象之間的過渡,雖然隱藏了數(shù)據(jù)層面的業(yè)務(wù)抽象,但并不能完全的屏蔽掉數(shù)據(jù)庫層的設(shè)計(jì),并且無疑將增加學(xué)習(xí)成本。對(duì)于復(fù)雜查詢，ORM仍然力不從心。雖然可以實(shí)現(xiàn)，但是不值得。世上沒有驢是不吃草的(又想好又想巧