平常心情【持續更新中】

前言

去年7月來到深圳，開始了大學畢業的第一份工做，轉眼又到了夏天。

今天突然發現工做中的有些感想不知道該同誰說。和同期入職的好朋友兼同事說吧，天天只有午餐時間和偶爾的下班後能夠交流，但那時候又忍不住說一些更有意思的話題（笑）；和女友（抱歉忍不住想秀一下，說到和愛有關的，關鍵就是幸運，因此祝福屏幕前的你早日遇到你愛也愛你的另外一半）說吧她又不是計算機專業的；

不說倒也不憋得慌，只是以爲許多有趣的想法和感覺就這樣隨風消逝了，怪惋惜的，因而猛然想起本身在學生時用過一下的開源中國………

2019-04-19

鍵盤上老是亮着的大寫鎖定指示燈

ORACLE 數據庫裏的各類命名老是少不了大寫，因而那麼一長串的大寫字母就讓我忍不住打開了大寫鎖定；平時中英文輸入切換太多，一不當心把中文的標點帶到代碼裏就很煩了，我慣用的 QQ 五筆在這個 WIN10 下又不知道有什麼鬼 BUG ，在英文狀態下按住 SHIFT 輸入大寫字母再鬆開 SHIFT 時會切換回中文，好在 PL/SQL 不區分大小寫，我就習慣了將 CAPS LOCK 看成切換中英文輸入的切換按鈕，因此個人電腦在休眠時大寫鎖定指示燈老是亮着的，算是一道不起眼的風景吧。

使用 PL/SQL 處理字符串真讓人頭大

產生麻煩的主要緣由是 PL/SQL 中沒有專門用於描述字符的類型，字符和字符串在這裏是一視同仁的，語法分析那種難度的處理使用正則搜索和替換倒也能夠，但好比統計一個字符串中有多少「,」這種事情寫起來就讓人很頭大了

Nvl(Length(Regexp_Replace(v_Fonts_Type, '[^,]+', '')), 0)

真是服了，這也能想到。

2019-05-10

沉不住氣就很氣

需求方找我說問題，原本我就事論事回答問題就行了，但不知道爲何我就忍不住提了一下本身以前作過的項目怎麼怎麼樣，唉！真的是沉不住氣，一瓶子不滿半瓶子晃盪……工程師的項目就像藝術家的做品同樣，是本身心血的結晶，老是但願可以獲得其餘人承認。**可能仍是作得太少了，作多了就再也不那麼忍不住吹噓本身作過的東西了吧……**一瓶子不滿半瓶子晃盪，就很氣。

2019-05-24

說話要穩要慢

做爲一個懂這件事的人，在向不清楚這件事的人描述這件事時，必定要穩，說話必定要慢，必定要觀察對方的反應，注意對方是否理解。不能由於本身很清楚就連珠炮似的說個不停！！！

2019-09-26

神奇的INSERT

一個INSERT語句報了錯，MMP在我心中上了膛；這個插入是絕對沒有違反任何限制的，然而仍是TNND報錯了！惋惜我日誌記錄疏忽了，忘記在 Dbms_Utility.Format_Error_Backtrace 後面加 SQLERRM 致使我仍是不知道具體錯誤緣由。待我修改代碼，記下這我的神共憤的奇葩異常倒底是何方妖孽。

原來是前端的問題

關於上次事件的後續：GFBFYXR 在完善日誌記錄後，終於找到了這個問題的緣由：

INSERT 報錯是由於有個字段違反的 NOT NULL 的約束，這個存儲過程的調用方：Form 裏的 ON-UPDATE 觸發器，對任何修改過的行都會執行一次，即便修改後與修改前一致；然初始都是未勾選的狀態，但當用戶先勾選再取消勾選時，一條本不該執行該存儲過程的記錄也執行了，解決方案就是在 ON-UPDATE 中檢查是否勾選。用戶當初測試時反饋她兩次相同的操做，一次有報錯，一次沒報錯，實際上當時報錯的那次操做應該是多了一個勾選後又取消勾選。

這次經歷給個人啓示有兩點：

1. 要對用戶的反饋報有懷疑，仍是應該儘量依靠日誌來調查 BUG；
2. 給表創建約束真的能夠在最後關頭避免有問題的數據插入，形成更深更廣的災難。

2019-10-25

面對複雜報表，拒絕遊標，用動態SQL

當一個查詢須要關聯到許多表，而且用戶要求的查詢參數過於多時，不要猶豫，雖然字符串拼接有各類各樣的風險，但不要怕，消除恐懼，微笑着面對它！

在報表這種 OLAP 應用中，SQL 硬解析的開銷能夠忽略，應該儘量幫數據庫找到最優計劃去執行，什麼綁定變量，什麼遊標參數，都很差使；尤爲當有些條件可能爲空時，寫一堆 t_Condition IS NULL OR Table.Col = t_Condition 實在不是什麼好操做。

報表一次運行跑半天，拼接字符串就完事兒了！把拼好的 SQL 寫到日誌裏，拼不對再調調調！

2019-11-05

有個不成熟的想法……

上次搞了個動態SQL，把報表搞得很快很快，需求方反饋，速度賊快；我看到仍是挺開心哈，可能我仍是比較喜歡互動，也喜歡獲得別人的承認；因此在想，要不要轉行去當老師呢？是時候去了解一下了。