Atea - Hero's Grave

     摘要: 標題起的有些大，僅代表自己和身邊一些人從業這幾年來的感悟:P  閱讀全文

現象：

     摘要: VJET JavaScript IDE 是一個Eclipse插件，提供了整套的Javascript開發環境：語法提示、自動補全、高亮、編輯糾錯、debug等。
比起Aptana來，VJET更加輕量，速度也更快。  閱讀全文

     摘要: JDK1.5引入的泛型，減少了類型強轉的代碼，增加了編譯檢查，提高了代碼的健壯性。
但在某些情況，泛型檢查會出乎意料的“丟失”，由此可引發難以發現的bug。  閱讀全文

如果別人只是讀取數據，FOR UPDATE就不會鎖定資源不讓他們讀
sum,count等函數為表鎖
null不等于任何值，包括它自己
盡量不要使用LONG型字段，而考慮使用CLOB
與不可重復讀的區別在于：在幻像讀中，已經讀取的數據不會改變，只是與以前相比，會有更多的數據滿足你的查詢條件
客戶端發出的語句（如INSERT INTO）是原子性的
應慎用IMMEDIATE約束。一條語句可能會使表中的各行暫時“不一致”，這是很自然的。
一般認為，用更新級聯來修改主鍵是很不好的做法
應手動給外鍵加索引，否則會引起子表的表鎖。
優化期會對視圖的來源表使用查詢。所以，對視圖加索引不如直接對來源表進行索引優化。

無法通過頻繁提交來“節省”undo空間，所以沒有必要在循環中提交。
1、事務的粒度（時長）應設計的盡可能小（短）
2、事務不是稀缺資源，所以不要在循環中提交
以上2個說法都正確，并不矛盾：
Re1: 事務過大，會在rollback時消耗大量資源
Re2: 循環提交會頻繁IO

性能調優，應首先嘗試減少查詢的運行時間，其次再考慮設置參數等。
查詢中最好手動加上order by
索引組織表（IOT）是存儲在索引結構中的表，適合OLAP應用。IOT不存在主鍵的空間開銷，因為索引就是輸據。
位圖索引適用于高度重復而且通常只讀的數據（在OLTP中慎用，涉及到并發性）。在讀密集的環境中能很好的工作，但極不適用于寫密集環境。
僅當要通過索引訪問表中很少的一部分行（很小的一個百分比）時，才使用B*索引。每個唯一約束應該至少有一個確實唯一的NOT NULL列。B*樹索引不會對一個完全為NULL的項加索引。

http://atealxt.appspot.com/article/20110317/book_read_note_oracle_database_9i10gand11g_programming_techniques_and_solutions.html

     摘要: 使用"help" -> "Check for Updates", 選擇所有eclipse插件，升級。
升級完重啟時，發生錯誤，IDE啟動失敗，報錯。


解決辦法：
修改文件 "ECLIPSE_HOME\configuration\config.ini"。  閱讀全文