在某些情況下，在生產環境中執行認真草擬的 UPDATE 陳述式可以解除危機。其他時候，一個拙劣的 UPDATE 可能會比最初的問題造成更多的危害。就像你總是可以在開發或測試資料庫上執行資料調處語言（Data Manipulation Language，DML）陳述式，但由於資料的差異，這種方法最多只能判斷陳述式對生產資料的影響。
那麼，在執行 INSERT、UPDATE 或 DELETE 陳述式之前，有哪些選項可以準確預測其結果對生產資料的影響呢？至少部分取決於資料庫供應商和產品。還有一些解決方案得到了廣泛的支持。我們將在本文中看看這兩個選項。
上週完結了關於「常見的 SQL 查詢錯誤」的系列文章，現在是時候從 Monty Python 劇本中翻開一頁，然後轉到一個截然不同的題目。這個題目就是為什麼資料庫開發人員和管理員應該考慮使用第三方資料庫管理工具（DBMT）來填補主要資料庫製造商的不足之處。無論價格如何，所有第三方 DBMT 都能補足或取代資料庫製造商的工具集，提供滿足一般 DBA 社群需求的功能。今天的文章將重點介紹第三方 DBMT 的一些好處。
述詞的評估順序
就在本系列的第 3 部分之前，我們短暫地停頓了一下，討論了 SQL 中的述詞，因為它們會導致與外部聯結相關的錯誤。在本系列「常見的 SQL 查詢錯誤」的最後一部分中，述詞將再次出現，因為我們將研究述詞的評估順序如何導致看似結構良好的查詢因錯誤而執行失敗。
搗亂的子査詢
在這個關於「常見的 SQL 查詢錯誤」的系列中，我們已經看了幾個 SQL 查詢的範示，這些查詢在第一次檢查時看起來非常可靠，但它們有機會導致錯誤的結果和/或效能降低。上週，我們學習了放置謂詞的位置如何對查詢執行產生負面影響，尤其是在外部聯結中。今天將重點介紹子查詢，以及當任何基礎資料表變更時它們如何破壞 SQL 陳述式。
- 2024 (1)
- 2023 (1)
- 2022 (1)
- 2021 (1)
- 2020 (1)
- 2019 (1)
- 2018 (1)
- 2017 (1)
