Atea - Hero's Grave

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

現(xiàn)象：

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

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

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

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

性能調(diào)優(yōu)，應首先嘗試減少查詢的運行時間，其次再考慮設置參數(shù)等。
查詢中最好手動加上order by
索引組織表（IOT）是存儲在索引結構中的表，適合OLAP應用。IOT不存在主鍵的空間開銷，因為索引就是輸據(jù)。
位圖索引適用于高度重復而且通常只讀的數(shù)據(jù)（在OLTP中慎用，涉及到并發(fā)性）。在讀密集的環(huán)境中能很好的工作，但極不適用于寫密集環(huán)境。
僅當要通過索引訪問表中很少的一部分行（很小的一個百分比）時，才使用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插件，升級。
升級完重啟時，發(fā)生錯誤，IDE啟動失敗，報錯。


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

     摘要: 限于自己的水平還未達到DBA級別，只能先以應用為主的角度讀了。
也許過幾個月再回來重讀，會有另一番心得。

筆記包含索引、事務與鎖、備份及其他四類。
  閱讀全文