從數據庫的角度來看，這個說法是沒錯的。任何系統的運行，(對於數據庫來說) 最終都是增刪改查這4個”基本步”。
但是從系統設計和系統運行的角度來看，這個說法無疑是將系統的複雜的邏輯關係”簡單化”了。
因爲，成熟的功能系統可以說是一個”生態環境系統”，這個生態系統裏面的所有的表對象，都是相互關係着的，任何一個表格的變更，勢必會影響別的表格。所以，這時候，系統的運行就不止是對某個表格的”增刪改查”這個簡單的操作了。
舉個例子，由於複雜的邏輯關係限制，表格(在這個系統中)不允許被增刪改。例如設置了人員的權限，他只允許讀取表格的內容，而不允許增刪改。
另外，這個表格如果要做增刪改的動作，從一個系統的角度來看，必須要考慮對別的表有沒有影響；或者做DML動作之後，是否要進行一個什麼樣的邏輯處理過程(處理別的表格的數據)。
Oracle EBS就是這樣子的一個生態系統，系統裏面的所有表格都是相關關係着的。舉個例子，你不能爲了某個目的，直接在數據庫刪除交易MMT表的數據吧。這樣子其他表關係着的表格的數據都會出問題了。例如交易批次明細表，交易科目帳表等等。當然，有些對象設置了外鍵關係的話，想刪也刪不了。
這個關係就類似社會中的人一樣。單單從人的角度來看，人就是生或者死。
但是，對於社會環境來說，人不是孤立的，他有父母，妻子(丈夫)，兒女，同事，有工作，有組織等等。他們都互相關係着，人的任何變化，都會影響到別的人。
所以，從系統的角度來看，必須要先理清楚所有對象之間的複雜的邏輯關係，纔可以說是掌握了這個系統的精髓。當然，要做到這點並不容易，可以試着從業務邏輯着手。因爲任何系統都是爲業務服務的；先了解業務，再瞭解系統的功能，或者比較容易理解。
同時，要開發，設計一個好的系統，也必須要先理清所有表對象之間的邏輯關係，纔可以開發一個健康的好用的系統。
而不是簡單的知道對系統的表格的增刪改查，就了事，就認爲已經很瞭解系統了。