1.B* 索引不会为 全null 值建立索引条目 所以 select * from T where x is null 不会使用索引 (如果索引建在x字段上) 不过， 如果满足以下两个条件， 仍会用到索引 a. 索引建在 (x,y) 上 b. y 被定义为Not Null字段 2. 外键上要不要索引？ a.一般来说都要，否则的话 i.如果修改父表的主键值或者删除父表中一行记录，会导致整个子表被锁 ii.父表中的On Delete Cascade被触发时 也会导致全表扫描 iii.按父表中的值查询子表记录时，由会导致对子表的全表扫描 b.相反地，如果同时满足以下所有条件，就不用加索引 i.不会修改父表主键值且不会删除父表记录 ii.不存在从父表到子表的连接 3.为什么我的索引没有被用上？ i. 索引建在 (x,y)复合字段上，但查询谓词只查了x …
BitMap 索引 1.基本上用于OLAP，一般不适用于OLTP环境 2.结构 BitMap Index: 一个索引条目对应多行 B* Index: 一个索引条目只对应一行 3.一个条目对应多行 => 因此只适用于 Distinct Cardinality 较低的情况，比如“性别字段”只有M/F这两种取值 4.不适用于“并发写”很频繁的场合。锁住一行数据 => 锁住整个索引条目 => 锁住该条目下的所有数据行 => 并发性极弱 BitMap Joined Index 1.也是BitMap索引的一种 2.只不过表A的索引建在表B的某个字段上，这样可以提升连接查询的效率。
1.结构 a.类似于二叉树 b.高度平衡：所有叶结点都在树的同一层次上 c.一般来说高度是2或者3 (需要2至3次I/O) 2.When B*? a.如果与索引有关的查询只返回少数几行数据，则可以用B* 索引 b.如果与索引有关的查询会牵涉到多行数据，但索引本身就可以回答这类查询（如 select count(*)），则也可以用B*索引。
1. B*树 — 最常用的一种索引 2. BitMap Index — 主要用于数据高度重复的情形，不适用于OLTP系统 3. BitMap Join Index — 在本表建立针对另一个表的字段的索引 4. Function-based Index — 可顾名思义 5. Application Domain Index -> ?
设置属性 myAutoComp.forceSelection = true;可以使用户无法输入无效的值–如果输入了非侯选值，输入框会被清空。 这个属性可以和 selectionEnforceEvent 一起使用。 在用户输入无效值而被清空后， selectionEnforceEvent 会被触发。
目前只想到两个后果，以后再补充 1.无法确定何时从session中移除这个变量。 在一系列操作的最后一步时去除？不行，用户可能做了一半就不做了。那，就不移除又怎么样？ 答案是会有灾难性的后果，用户会看到莫名奇妙的东西，同时程序员很难复现这种问题。 2.无法确定何时把变量植入到session中。一般认为在“操作系列”的第一步时植入就够了，但其实每个中间步骤在未来都可能变成另一个“操作系列”第一步。到未来再说？ 未来的程序员就是另一个人了，他根本不知道原始“操作系列”的存在！
答: 影响了下层模块的可重用性。由于下层依赖上层的某个模块，当上层的另一个模块需要调用该下层模块时，那就会发现这个下层无法直接调用。 举个例子。比如 某个Service模块需要读取“操作者”以判断权限。第一次写代码时，为了贪图方便，就直接在Service里读取 Session.getUser()获得“操作者” 。后来来了新需求，某个Web服务也要调用这个Service，那这样就会出问题了。
Nested Table 1.Can be used for persistence or PL/SQL programming, but mainly used for programming. 2.Can be used as the type of another table’s column 3.Can’t referece any table for constraints, including itself. Temp Table: 1.There is no concurrency problem for temp tables. Because two sessions will never share one copy. …
Notes on ‘Expert Oracle’ — No.10.4: Table — Nested table & Temp table Read More »
所谓链式的setter 就是 bean.setProp1("1").setProp2("2")…setPropN("N") 这样的好处就是：一行代码就可以设置完尽量多的属性值。这在单元测试里特别有用。 举例来说，当你要设置一个Bean作为测试数据，如果不用链式，则 Bean bean = new Bean(); bean.setProp1("1"); bean.setProp2("2"); bean.setProp3("3"); assertEquals("XXX", bean.getXXX()); 一共要写五行代码。 1. 由于普通的Setter不支持链式调用，因此3个属性要写3行set语句，每条语句里都要写一个"bean"字，即12个字母； 2. 另外，构造方法 new Bean()本来是链式的，但由于受到无链式setter的拖累，以致于必须显式地声明一个 "bean" 变量。 而如果我们用链式风格的setter的话，一行即可。 assertEquals("XXX",new Bean().setProp1().setProp2().setProp3().getXXX())); 看，多简洁！ 可以采用匿名对象(new Bean())，并且不用换行。 当然了，这样做的好处主要是为了单元测试时准备数据。正式代码里可能不会一次性设置这么多属性，就算要设置这么多，这样写也会降低代码的可调试性。 你可能会问为什么不用一个 带有所有参数的构造方式？ 我的看法是， 1.参数较多的构造方法比较丑陋，调用时也容易把参数顺序搞错。比如 new Name("Diego", "Maradona") 中，哪个是 first name, 哪个是 last name? 2.写带参构造方法比写无参和要累 3.最重要的是，新增属性时会使带参的构造方法不得不重构。很烦。
1.引子 问题：我经常连接表A和表B，除了建立表索引外吗，还有别的优化手段吗？ 答案：有。如果A和B相应的一组数据在同一个块中，那么查询时就不需要取出那么多块了，I/O效率会高很多。 2.什么是聚簇 a. A和B的同组数据放在同一个块中，如果A和B经常连结 b. 同一张表中共享同一列值的行尽量放在同一个块中 3.一个聚簇块应该放几行数据？ 要恰当地设置这个值。 a.如果行数太少，则会浪费块的空间 b.如果行数太多，则可能会导致 块 不能容纳整行数据，而只能通过串链解决问题。串链太多就适得其反了。 4.什么时候应该用聚簇 以读为主、且主要使用索引读、并且经常要进行连接查询的一组表应该放在同一个聚族中。