第1章資料模型設計
第1條:確保所有表都有主鍵
【1】當表缺少主鍵時，會出現各種問題，所有表都必須有一列(或多列)設定為主鍵，
【2】主鍵應當具備的特征
唯一性，值非空，不可變，盡可能簡單
【3】不要使用復合主鍵，效率太低
定義主鍵時，大多數資料庫會同時強制創建唯一索引
適用主鍵做連接查詢很常見，但是在具有多個列的主鍵上這樣做很復雜，效率也很低
【4】如果不希望非鍵列出現重復資料，在列上定義唯一索引以保證其完整性，
第2條:避免存盤冗余資料
【1】規范化是按照不同的主題將資訊分類，以避免冗余資料的存在
【2】冗余是指用戶在不同地方輸入相同資料的情況
【3】規范化最重要的目標就是最小化資料重復
【4】通過消除冗余資料，避免插入、更新和洗掉時出現例外
第3條:消除重復資料組
【1】資料庫規范化的目標是消除重復的資料組，并盡可能減少表結構的修改
【2】通過洗掉重復的資料組，可以使用唯一的索引來防止以外的重復資料，并大大簡化查詢陳述句
【3】洗掉重復的資料組使設計更加靈活，因為添加新的資料組只需要加一條記錄，而不用修改表設計增加更多的列
第4條:每列只存盤一個屬性
【1】正確的表設計師為每個分配單獨的列，當列包含多個屬性時，搜索和分組即使有可能做，也會是極其困難的
【2】對于某些應用程式，有過濾列中的某部分資料的需求，這可能會決定列的粒度級別
【3】當需要重新把屬性組合成報表或列印清單時，適用連接
第5條:理解為什么存盤計算列通常有害無益
【1】如果這個表用于大型在線資料錄入系統，創建計算列可能會對服務器造成巨大的負載，從而影響服務器的回應時間
【2】許多資料庫系統允許你在創建表時定義計算類，但應該主義性能影響，特別是在適用非確定性運算式或函式的時候
【3】你還可以像定義普通列一樣定義計算列，然后適用觸發器來維護，但是撰寫觸發器的代碼可能會很復雜
【4】計算列會對資料庫系統產生額外的開銷，只有當利大于弊時候才考慮適用它
【5】大多數情況下，你希望在計算列上創建一個索引，以小號更多的存盤空間和攪蠻的更新作為交換，獲得一些便利性
【6】當不能使用索引時，使用視圖來做計算通常可以作為在表里創建計算列的計算方法
第6條:定義外鍵以確保參考完整性
【1】正確地設計資料庫時，在許多表中都會包含應用相關父表主鍵的外鍵
【2】外鍵明顯有助于保證相關表之間的資料完整性，確保子表的記錄能在父表找到對應的記錄
【3】如果表中存在違反約束的資料，向表中添加FOREIGN KEY約束將失敗
【4】在某些資料庫系統中，定義FOREIGN KEY約束將會最懂創建索引，這樣可以提高連接查詢的性能，在其他一些資料庫系統中，創建索引來覆寫FOREIGN KEY約束必須小心，即使沒有索引，一些資料庫系統優化器也會特別對待這些列，以提供更好的查詢效率
第7條:確保表間關系的合理性
【1】再三斟酌，為了簡化關系模型而合并包含相似欄位的表是否真的有意義
【2】只要對應列資料型別匹配【或可以隱式地強制轉換】，就可以在兩個表之間創建連接，但只有當列當屬于同一個業務領域時，關系才是有效的，所以，最理想的連接是兩端都具有相同的資料型別和業務領域
【3】在建模之前，檢查你處理的資料是否是結構化資料，如果是半結構化的，則要做特殊的處理
【4】明確資料模型的目標通常有助于判斷給定的設計是否由于簡化關系模型和適用此資料模型應用程式的設計導致了復雜性或例外的增加
第8條:當第三范式不夠時，采用更多范式
【1】判斷一個設計遵循第三范式但可能違反更高范式的警告標志是，看一個表是否與其他多個表關聯，特別是當表參與了多個多對多的關系時，
【2】另一個判斷方法是，如果表包含復合鍵就有可能違反較高的范式，
【3】前三個范式關注關系中屬性之間的功能依賴，功能依賴是指屬性依賴于關系中的鍵，
【4】對于四個范式，我們關注的是多值依賴，是兩個彼此獨立的屬性同時依賴關系中同一個鍵的情況
【5】大多數資料模型已經滿足了較高的范式，因此，只需要注意某些明顯違反高級范式的情況
【6】第四范式只有在某些特殊的情況下才會違反
【7】第五范式要求候選鍵可推匯出所有連接依賴，意味著你應該能夠基于各個屬性來約束候選鍵的有效值，這種情況只發生在復合鍵上
【8】第六范式是將表的關系減少到只存在一個非關鍵屬性，這樣會導致表的數量膨脹，但是可以避免出現空值的列
【9】無損分解是檢測表是否違反較高范式的一個有效工具
第9條:非規范化資料倉庫
【1】規范化的表通常比非規范化的表更小且占用的空間更少
【2】資料被拆分成多個小表，小到足以存在快取中，性能通常也更好
【3】想清楚要復制的資料及原因
【4】計劃如何保持資料同步
【5】適用非規范化欄位重構查詢
第2章可編程性與索引設計
第10條:創建索引時空值的影響
【1】null是關系資料庫中的特殊值，表示列位置或資料確實，
【2】null永遠不能等于或不等于另一個值，甚至是另一個null也不行
【3】要檢測是否存在null值，必須適用IS NULL條件
【4】創建索引時考慮列是否包含空值
【5】如果要搜索空值，但列中的大多數值都可能為NULL，那么最好不要對列進行索引，這也可能表明表需要重新設計
【6】如果希望更快地對列進行搜索，但列中大多數值為NULL，具有資料庫支持的話，可以創建排除空值的索引
【7】每種資料庫處理索引中空值的方法都不同，在為可能包含空值的列上創建索引時，確保了解資料庫系統的選項
第11條:創建索引時謹慎考慮以最小化索引和資料掃描
【1】盡管加大硬體的投資可以提高性能，但是優化查詢通常可以以更低成本的方式獲得更好的效果
【2】導致性能問題常見的原因是缺少索引或者設定了錯誤的索引，這會導致資料庫引擎必須處理更多的資料來查找符合條件的記錄，這些問題通常被稱為索引掃描和表掃描
【3】當資料庫引擎需要通過掃描索引或者資料塊來能找到相應的記錄時，就需要索引掃描或表掃描
【4】分析資料，創建正確的索引以提高性能
【5】確保創建的索引都被使用
第12條:索引不只是過濾
【1】資料庫索引在資料庫中擁有獨特的資料結構
【2】由于索引會復制已索引表的資料，所以每個索引都有屬于自己的磁盤空間，所以索引時純冗余的，但這種冗余是可以接受的
【3】因為索引不需要在每次查詢中索引表中的每一個行，可以快速定位資料提高資料檢索操作的速度
【4】WHERE子句中的列是否包含在索引中會查詢的性能產生影響，一個寫的很差的WHERE字句是緩慢查詢的罪魁禍首
【5】SELECT子句中的列是否被索引也會影響查詢的效率
【6】連接查詢的列是否被索引可能會影響查詢的效率
第13條:不要過度使用觸發
【1】創建表時，因為使用約束提供的DRI以及內置功能創建的計算列，性能通常會更好，所以我們建議將約束或創建計算列的內置功能作為默認解決方案
【2】觸發器通常不可移植：一個資料庫系統的觸發器，在不做修改的情況下，很難在另一個資料庫系統中運行
【3】僅在絕對必要時才使用觸發器，如果可能，確保觸發器是冪等的
第14條:使用過濾索引包含或排除資料子集
【1】過濾索引進隊少部分行有用，可節省空間
【2】過濾索引可用于對行自己執行為以約束
【3】過濾索引可避免排序操作
【4】考慮是否需要磁區表來提供類似過濾索引的功能，從而避免維護一個索引的成本
第15條:使用宣告式約束替代編碼校驗
【1】考慮使用約束來槍支資料完整性
【2】查詢優化器可以使用約束定義來構建高性能查詢執行計劃
第16條:了解資料庫使用的SQL方言并撰寫相應的
【1】即使一條陳述句可能復合SQL標準，也可能無法在你的DBMS中使用
【2】由于不同的DBMS以不同方式執行，相同的SQL陳述句在性能上的表現也會不同
第17條:了解何時在索引中使用計算結果
【1】不要過度使用索引
【2】分析資料庫預期的使用情況，以確保過濾索引僅在真正有意義的地方使用
第3章 當你不能改變設計時
第18條:使用視圖來簡化不能更改的
【1】視圖是一種讓用戶創建自然或至關的結構化資料的方式
【2】使用視圖來限制對資料的訪問，限制用戶盡可以看到【有時候可以修改】他們所需要的資料
【3】使用視圖來隱藏和重用復雜的查詢
【4】視圖可從各種表中匯總用于生成報告的資料
【5】使用視圖實作和強制命名及編碼標準，特別是在需要更新舊資料庫的結構時
第19條:使用ETL將非關系資料轉換為有用的資訊
【1】ETL工具讓你能更容易并非關系資料匯入到資料庫中
【2】ETL工具可幫助你重新格式化并重新排列匯入的資料，以便將其轉換為有用的資訊
【3】大多數資料庫系統中提供了某些勒死的ETL工具，也有一些商業工具可用
第20條:創建匯總表并維護
【1】存盤匯總資料可以幫助最小化聚合流程
【2】使用表存盤匯總資料后，可以索引包含聚合資料的欄位，以便更有效地查詢匯總資料
【3】匯總對于幾乎靜態的表效果最好，如果原表變化太頻繁，則匯總的開銷可能太大
【4】觸發器可用于執行匯總，但重建匯總表的存盤程序通常更好
第21條:使用UNION陳述句將非規范化資料列轉行
【1】UNION查詢中的每個SELECT陳述句必須具有相同數量的列
【2】盡管SELECT陳述句的列名并不重要，但每列的資料型別必須兼容
【3】要控制資料出現的順序，可以再最后一個SELECT陳述句之后使用ORDER BY子句
【4】如果你不希望消除重復行或能夠承受移除重復行帶來的性能損失，請使用UNION ALL替代UNION
第4章過濾與查找資料
第22條:了解關系代數及其如何在SQL實理
【1】關系模型定義了你可以再集合上執行的8個操作
【2】所有主流的SQL實作都支持選擇、投影、連接、笛卡爾積和并集
【3】一些SQL的實作使用INTERSECT和EXCEPT或MINUS關鍵字支持交集和差集
【4】實作SQL的主流資料庫系統都不支持除操作，但可以通過SQL的其他操作得到相同的結果
第23條:查找不匹配或缺失的記
【1】雖然易于理解，但使用NOT IN運算子通常不是最有效的辦法
【2】使用NOT EXISTS運算子通常比使用NOT IN運算子更快
【3】使用無效連接通常是非常有效的，但這取決于DBMS如何處理空值
【4】使用DBMS查詢分析器來確定哪種方式最適合你的具體情況
第24條:了解何時使用CASE解決問題
【1】當你需要解決IF...THEN...ELSE這類問題時，CASE是一個強大的工具
【2】你可以使用簡單的CASE來執行相等判斷和基于搜索的CASE以使用復雜的條件
【3】可以使用運算式的地方都可以使用CASE，包括作為SELECT子句的列定義或作為WHERE或HAVING子句條件的一部分
第25條:了解解決多條件查詢的技術
【1】需要通過關聯表或多個表判斷多個條件才能解決問題，通常都比較復雜
【2】當父表查詢需要在其一個或多個子表的相應記錄滿足多個條件時才能翻會記錄，必須在表子查詢中使用INNER JOIN或OUTER JOIN并結合空值判斷，或者或者在表子查詢中使用IN和AND或NOT IN和OR才能得到正確的結果
第26條:如需完美匹配，先對資料進行除操作
【1】除是8個公認的關系集操作之一，但SQL標準和主流資料庫系統都不支持DIVIDE關鍵字
【2】你可以使用除來查找一組資料中匹配另一組資料所有記錄的記錄
【3】你可以通過測驗除數集中的每一行、NOT EXISTS和GROUP BY或HAVING來執行除操作
第27條:如何按時間范圍正確地過濾日期和時間的列
【1】不要依賴隱式日期轉換；使用顯式轉換函式來處理日期字符
【2】不要將函式應用于日期和時間列，否則查詢將不能使用索引
【3】攝入誤差可能導致日期和時間值不正確；使用>=和<替代BETWEEN
第28條:書寫可引數化搜索的查詢以確保引擎使用索引
【1】避免使用不可引數化搜索的運算子
【2】不要再WHERE子句中的一個或多個欄位上使用函式
【3】不要對WHERE子句的欄位進行算數運算
【4】使用LIKE運算子時，只能在字串末尾使用通配符【不是‘%something’或‘some%thing’】
第29條:正確地定義“左”連接的“右”側
【1】在SQL中使用OUTER JOIN執行差集操作
【2】當你對外部WHERE子句中的左連接加入右側資料使用過濾時，你將無法獲得所需的結果，反之亦然
【3】要正確地過濾資料自己，必須在資料庫系統執行外連接之前使用過濾
第5章聚合
第30條:理解GROUPBY的作業原理
【1】聚合在執行WHERE子句之后完成
【2】GROUP BY子句聚合過濾后的資料集
【3】HAVING子句過濾聚合后的資料集
【4】ORDER BY子句對變換后的資料集進行排序
【5】在SELECT子句中沒有使用聚合函式或計算的任何列必須同時出現在GROUP BY子句中
【6】使用ROLLUP、CUBE和GROUPING SETS可以在單個查詢中提供更多可能的組合、以代替創建多個聚合查詢，然后再將其合并
第31條:簡化GROUP BY子句
【1】某些DMBS要求將非聚合的列也添加到GROUP BY，即使當前的SQL標準不再需要這么做
【2】GROUP BY中的列過多可能會對查詢的性能產生負面影響、也會使閱讀、理解和重寫變得困難
【3】對于同時需要聚合和詳細資訊的查詢，首先在子查詢中執行所有聚合，然后將結果再連接到其他表以查詢詳細資訊
第32條:利用GROUP BY或HAVING解決復雜的問題
【1】在分組之前使用WHERE子句過濾記錄，分組后使用HAVING過濾記錄
【2】HAVING子句可以過濾聚合運算式
【3】即使你在SELECT子句中已給聚合運算式明明，如果要在HAVING子句中使用運算式，必須重寫該運算式，不能重用SELECT中的名稱，
【4】可以將簡單文字的聚合值與復雜子查詢聚合回傳的值進行比較
第33條:避免使用GROUP BY來查找最大值或最小值
【1】主表連接到自身需要使用LEFT JOIN
【2】將GROUP BY子句中的每一列都變成ON 子句的一部分，并使用相等=進行比較
【3】MAX（）或MIN（）子句中的列將成為ON子句的一部分，并且使用<或>
【4】應該為ON子句中的列添加索引，以過的更好的性能，特別是針對較大的資料集時
第34條:使用OUTER JOIN時避免獲取錯誤的COUNT（）
【1】使用COUNT(*)來統計所有記錄的總數，也包括空值的記錄
【2】使用COUNT()僅統計列值不為NULL的記錄的總數
【3】有時一個子查詢甚至一個相關的子查詢，也會比使用GROUP BY有效率
第35條:測驗HAVING COUNT(x) <某數時包含零值記錄
【1】使用INNER JOIN不能找出零計數
【2】過濾左連接的右側，將獲得相當于內連接的結果，將過濾器移入子查詢或在ON條件中過濾右側
【3】當想大于1的總計數時，尋找零計數可以幫助你識別資料中的問題
第36條:使用DISTINCT獲取不重復的計數
【1】使用COUNT（）函式適當的方式來簡化計算
【2】可以考慮使用函式作為COUNT（）函式的引數，以便不需要使用WHERE子句就能執行組合計算
第37條:知道如何使用視窗函式
【1】視窗函式感知周圍的行，這使得創建運行或移動聚合比傳統的聚合函式和陳述句級分組更容易
【2】視窗函式是更需要對不同的或獨立的資料應用聚合的理想選擇
【3】視窗函式可以與現有的聚合函式一起使用，并通過包含OVER子句來啟用
【4】PARTITION BY謂詞可用于制定必須將該分組應用于聚合運算式
【5】ORDER BY謂詞通常很重要，因為它影響后續行將如何計算其聚合運算式
第38條:創建行號與排名
【1】必須始終對ROW_NUMBER()、RANK()和其他排序函式進行視窗化，因此必須與相應的OVER子句一起出現
【2】考慮如何使用排序函式處理關聯，如果你需要連續排名，應該使用DENSE_RANK()
【3】ORDER BY謂詞對于這類函式是強制性的，因為它會影響結果如何排序
第39條:創建可移動聚合函
【1】無論如何需要將視窗框架的邊界更改為非默認設定，即使可選，也必須指定ORDER BY謂詞
【2】如果需要為視窗框架定義任意大小，則必須使用ROWS，這樣可以輸入需要包含在視窗框架中的前后幾行
【3】RANGE只能接受UNBOUNDED PRECEDING、CURRENT ROW或UNBOUNDED FOLLOWING作為有效選項
【4】你可以選擇RANGE邏輯分組行貨ROWS物理偏移行，如果ORDER BY謂詞不回傳重復值，則兩者結果是等效的
第6章 子查詢
第40條:了解在何處使用子查詢
【1】你可以在任何使用表、視圖或能夠回傳表的函式或程序的位置使用表子查詢
【2】你可以在任何使用表子查詢和需要為IN或NOT IN條件提供一個串列的位置，使用回傳單列的表子查詢
【3】你可以在任何使用列名的位置使用標量子查詢，如在一個SELECT陳述句中，或在一個SELECT陳述句的運算式，或作為比較條件的一部分
第41條:了解關聯和非關聯子查詢的差異
【1】關聯子查詢在WHERE或HAVING子句中使用一個應用，該應用依賴于潛入子查詢的查詢回傳值
【2】非關聯子查詢不依賴于外部查詢，并且可以獨立執行
【3】通常，你可以使用非關聯子查詢，為FROM子句提供已過濾的資料集，或作為IN條件的單列資料集，或作為在WHERE或HAVING子句中為比較條件回傳的標量值
【4】你可以使用關聯子查詢，為SELECT子句回傳標量值，在WHERE或HAVING子句中為比較條件提供單個值進行測驗，或者在EXISTS子句中提供用于存在性檢驗的資料集合
【5】關聯子查詢不一定比其他方法慢，但它可能是回傳正確結果的唯一方法
第42條:盡可能使用公共表運算式而不是子查詢
【1】利用公用表運算式【CTE】，你可以簡化多次使用相同子查詢的復雜查詢
【2】CTE可以免除使用可能無意中更改的功能，而這樣的修改會導致使用該函式的查詢無法正常作業
【3】在同一SQL中，CTE允許你直接定義要嵌入到另一個查詢中的子查詢，這樣做也更容易理解
【4】雖然你可以使用遞回CTE生成一些資料值，這些值在計數表中找到，但保存的基數表效率更高，因為你可以對其添加索引
【5】你可以使用遞回CTE遍歷層次關系，并以有意義的方式進行展示
第43條:使用連接而非子查詢創建更高效的查詢
【1】不要認為按順序解決問題是首選方法，SQL陳述句最適合按集合，而不是按行運行
【2】了解DBMS優化器多種處理方式的特性，從而決定首選的解決方案
【3】確保為任何鏈接都建立了適當的索引
第7章 獲取與分析元資料
第44條:了解如何使用系統的查詢分析器
【1】執行計劃中顯示地資訊可能會隨時間而變化
【2】DB2要求先創建系統表，它將執行計劃存盤在這些系統表中，而不是顯示它們，它會產生預估的計劃
第45條:學習獲取資料庫的元資料
【1】盡可能使用SQL標準的INFORMATION_SCHEMA視圖
【2】INFORMATION_SCHEMA在DBMS之間并不完全一樣
第46條:理解執行計劃的作業原理
【1】每當你閱讀執行計劃時，將其轉換為實際步驟，分析是否存在未使用的索引，并確定其未被使用的原因
【2】分析各個步驟，并判斷它們是否有效，請注意，效率受資料分部的影響，因此沒有所謂的“壞”操作，而是分析所使用的的操作是否適合正在使用的查詢
【3】不要因為一個查詢就加上索引來改善執行計劃，你必須從資料庫出發全盤考慮以確保索引盡可能的通用
【4】注意大與小情況，其中資料分布不均的資料對同一個查詢會需要不同的優化，當執行計劃被快取和重用時，這個問題就特別嚴重
第8章 笛卡兒積
第47條:生成兩張表所有行的組合并標示一張表中間接關聯另一張表的列
【1】使用笛卡爾積產生兩個表之間的各種組合
【2】使用INNER JOIN確定實際發生的組合
【3】使用LEFT JOIN將笛卡爾積的結果與實際發生的組合串列進行比較
【4】你還可以使用SELECT子句中CASE陳述句中的IN子查詢來產生于使用笛卡爾積及LEFT JOIN相同的結果，但性能取決于資料流、索引和特定DBMS
第48條:理解如何以等分量排名
【1】將等分資料分成排名區間是評估資訊有趣有用的方式
【2】使用RANK（）視窗函式輕松創建排名值
【3】將1除以磁區數以產生每個磁區的乘數
第49條:知道如何對表中的行配對
【1】找出從N個專案中取出K個專案的排列組合很有用
【2】有獨特列時找出排列組合很容易
【3】要增加每個組合選擇的專案數量時，只需將目標表的另一個副本添加到查詢中即可
【4】操作大量資料時要小心，因為最終可能產生成百上千億行
第50條:理解如何列出類別與前三偏好
【1】除運算可找出完全匹配
【2】如果接受部分匹配，則需要套用其他技巧
【3】表中有排名的資料可以幫助你決定最佳的匹配
第9章計數表
第51條:根據計數表內定義的引數生成空行
【1】生成空白行可能是有用的，特別是對于報表
【2】你可以使用遞回CTE或技術表來幫助你生成空行，在某些情況下，直接使用表可能會更快
【3】為了方便為空行數提供引數值，創建一個接收引數的函式，以便你可以從SELECT陳述句中呼叫它
第52條:使用計數表和視窗函式生成序列
【1】計數表可以與視窗函式一起使用，以提供更多的序列或其他需要以視窗描述的方式
【2】非等式連接與計數表在需要憑空產生記錄時很有用
第53條:根據計數表內定義的范圍生成行
【1】使用計數表產生資料庫中沒有的值
【2】當計數表包含一個范圍的值時，你可以比較此范圍與現有資料以產生相對值
【3】你可以使用序列計數表根據另一個計數表的值生成行
第54條:根據計數表定義的值范圍轉換某個表中的值
【1】確保你的轉換計數表符合你的資料設計
【2】確保非等式中使用的不等式適用于正在使用的計數表
第55條:使用日期表簡化日期計算
【1】對于日期與日期運算密集的應用程式，日期表可大幅簡化邏輯
【2】日期表可加入作業日、假榷訓財年等特定應用領域
【3】由于日期表基本上是個維度表，因此即使是在線交易處理資料庫也可以大量創建索引，如果可能，將表明確地存盤在記憶體中能夠避免磁盤存取并改善優化器的判斷
第56條:創建在某個范圍內所有日期的日程表
【1】確保你的日期表有適當的索引
【2】確保WHERE子句從適當的表中測驗值
第57條:使用計數表行轉列
【1】需要行轉列資料時，你的資料庫系統可能有專屬的語法
【2】若只想要使用標準SQL，你可以使用CASE運算式對資料進行行列轉換，以提供聚合函式中每行需要的值
第10章 層次資料建模
第58條:從鄰接串列模型開始
【1】鄰接串列只是在表中添加一個自參考表的主鍵的一個外鍵，不需要元資料
【2】始終使用鄰接串列模型構建一致的層次模型
第59條:對不常更新的資料使用嵌套集以提升查詢性能
【1】你必須使用存盤程序來維護嵌套集模型，以封裝構建集合后的邏輯，并為每個節點分配正確的左和右數字，
【2】嵌套集模型不適用于頻繁更新的情況，因為對層次結構的更改需要對其他幾個節點進行重新編號，可能是整個表，這可能會導致死鎖，
【3】獲取計數不需要查找其他記錄，因為它可以從lft和rgt元資料列計算，使得嵌套集模型對于維護統計資訊非常有效，
【4】嵌套集模型只能使用單個根節點的單個層次結構，如果你需要多個層次結構，多個根節點，請考慮其他模型，
第60條:使用存盤路徑簡化設定與搜索
【1】存盤路徑的好處是容易理解與處理，因為它基于我們都熟悉的檔案系統路徑，
【2】設計的限制很難發現，因為沒有簡單的方法預知層次結構是否太深或太寬而超過索引的限制，因此你必須對層次結構加上限制以避免產生問題，
【3】存盤路徑的搜索僅在一個方向上有效，因為在開始或謂詞中有通配符時不能創建可搜索的查詢，設計時要考慮這一點，
第61條:使用祖先遍歷閉包做復雜搜索
【1】當你需要頻繁更新和易于搜索時，使用祖先遍歷閉包模型，但代價是維護祖先表的額外復雜性，
【2】雖然比較規范化，但是不能將祖先表中的元資料保持為最新，可能導致查詢結果不正確，這可以通過在Employees表上使用觸發器來自動修改祖先表來緩解，但需要付出一定的成本，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/445416.html
標籤：其他
上一篇：MySQL視圖