老師公開(kāi)課源碼及vip所有都在這里public表示其他名稱(chēng)為日期-tom springjdbcorm

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