Atea - Hero's Grave

     摘要: 地址是： http://atealxt.appspot.com/  閱讀全文

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

現象：

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

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

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

無法通過頻繁提交來“節省”undo空間，所以沒有必要在循環中提交。
1、事務的粒度（時長）應設計的盡可能?。ǘ蹋?br /> 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"。  閱讀全文

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

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

從今天開始，把讀書時做的標注集中地做個摘抄，在加深印象的同時也能全面地了解一下自己在讀該書時的側重點及收獲。
首先，逐步地把以前的整理出來:)

• 細節應該依賴于抽象
• 在包的依賴關系圖中不允許存在環
• 如果在迭代結束的時候，90%的任務已被完成，但沒有一個素材是被完全完成的，這將是噩夢一般的情景

• SINGLETON模式強制結構上的單一性。它防止創建出多個對象實例。相反，MONOSTATE模式則強制行為上的單一性，而沒有強加結構方面的限制。
• VISITOR模式如同一個矩陣
• Builder模式著重于一步步構造一個復雜對象，而Abstract Factory著重于多個系列的產品對象。Builder在最后的一部返回產品，而對于Abstract Factory來說，產品是立即返回的。

http://atealxt.appspot.com/article/20110209/reading_notes_agile_software_gof.html