我的大部分技術生涯都在初創公司中度過。我喜歡快節奏和學習新事物的機會，以及將一個新產品成功帶進市場的成就感。我的職業生涯始於QA。在初創公司中，開發人員與測試人員的比例不可能像大企業那樣低。作為一名初創公司的QA工程師，收件箱的郵件總是比發件箱多得多。你是新版本發布的最後一道關卡，因此你總處於顯微鏡之下。在初創公司的早期階段，你很可能也從屬於“客戶支持”團隊，所以當產品出現問題時，你會成為最忙碌的一位。
和其他從事相同工作的人一樣，我總是非常關注於尋找正確的工具來減輕我的負擔，但是不能犧牲我個人對於工作質量的定位。因此我在10年前就遇到了FindBugs。我第一次使用這個工具時，我將它的結果分享給團隊的開發工程師，他們感覺這個工具產生了多於真實Bug的誤報或者屬於一種“吹毛求疵”方式。但是，隨著我們不斷地根據自己的需求調整和擴展所執行的檢查，並且將FindBugs得到的數據與測試和生產中發現的實際Bug數量相關聯，FindBugs最後成為每夜構建版本和按需構建版本的組成部分。這些報告是在早期預示潛在問題的好線索，也允許開發者提前修正錯誤，避免占用測試時間或運營故障故障時間。此外，對於我團隊中的開發者而言由於每天都能收到構建系統的提醒，而且這些提醒會幫他們改掉自己的壞習慣，編寫出更安全、更高效、更穩定的代碼，所以他們產生的缺陷也越來越少。發布周期縮短了，產品質量提高了，客戶滿意度也提高了，這都證明了預防確實比治療更加重要。
隨著企業IT不斷地擁抱敏捷開發實踐和采用DevOps模式，以此更快地向市場推出更優質的產品，DBA實際上也開始感覺到壓力。前面關於初創軟件公司QA工程師的介紹也一樣適用於DBA。隨著版本發布越來越頻繁，DBA接收到需要編寫、檢查、修改或優化的SQL腳本數量要遠遠多於完成的數量。DBA是數據質量、數據安全和數據平台性能的最後一道防線，因此DBA也是第一批響應問題的人。
在與我們協作的財富500強公司DBA中， 他們日常工作中最耗費時間的任務是檢查SQL。有一些DBA將自己70%的時間用在人工檢查SQL腳本上。他們會像FindBugs等工具檢查Java代碼一樣去檢查SQL：預示邏輯問題的編碼模式、安全漏洞、性能問題及違反內部規定最佳實踐或外部法規的合規性問題。
顯然，DBA需要一種和十年前FindBugs一樣的工具。SQL靜態分析並不是新技術，但是目前可用的產品也只能做到靜態分析。通常，它們會在不考慮上下文的情況下評估SQL語句。這種局限性會影響最終的生產力和質量，因為數據庫生命周期管理的大多數時候都知道誰在何時、何地執行何種操作。例如，一個組織可能允許給一個測試環境分配權限和執行INSERT語句，但是絕不允許在生產環境的自動化任務中執行這些操作。任何SQL靜態分析工具都必須考慮環境參數。
另一個讓問題變得復雜的是數據庫“版本變化”。雖然各個版本的應用程序都會打包、設定版本和全部替代，但是支持應用程序的數據模式一直存在，並且不斷地進化。而且，外部合規性標准與內部審計要求通常規定要嚴格控制數據庫的增量修改，並且要用嚴格定義的流程來跟蹤變化。這意味著，DBA還必須通過手工流程和檢查SQL注釋）確認能夠跟蹤到修改的原因，而且要在每一個環境中跟蹤修改的執行結果。
DaticalDB Rules Engine在設計與實現時專門考慮了SQL檢查與靜態分析所帶來的特殊挑戰。下面是Datical DB通過靜態分析安全可靠地提高效率的一些原因：
