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"。  阅读全文

     摘要: 限于自己的水平还未达到DBA级别，只能先以应用为主的角度读了。
也许过几个月再回来重读，会有另一番心得。

笔记包含索引、事务与锁、备份及其他四类。
  阅读全文

从今天开始，把读书时做的标注集中地做个摘抄，在加深印象的同时也能全面地了解一下自己在读该书时的侧重点及收获。
首先，逐步地把以前的整理出来:)

• 细节应该依赖于抽象
• 在包的依赖关系图中不允许存在环
• 如果在迭代结束的时候，90%的任务已被完成，但没有一个素材是被完全完成的，这将是噩梦一般的情景

• SINGLETON模式强制结构上的单一性。它防止创建出多个对象实例。相反，MONOSTATE模式则强制行为上的单一性，而没有强加结构方面的限制。
• VISITOR模式如同一个矩阵
• Builder模式着重于一步步构造一个复杂对象，而Abstract Factory着重于多个系列的产品对象。Builder在最后的一部返回产品，而对于Abstract Factory来说，产品是立即返回的。

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