Monthly Archives: February 2014

代码片断:在m位数之前加0,凑足n位

代码片断:在m位数之间加0,凑足n位.

这主要用于使数字按字符串排序的顺序跟直接按数字排序的顺序相同

比如把 8,9,10,11 变成 08, 09, 10, 11后,按字符串序排序仍与数字大小序相同


	/**
	 * 1 => 0001
	 * 
	 * @param positiveNumber
	 * @param maxValue
	 * @return
	 */
	private static String prependZeroForNumber(int positiveNumber, int maxValue) {
		int digitLength = String.valueOf(maxValue).length();
		String numStr = String.valueOf(positiveNumber);

		StringBuffer pre = new StringBuffer();
		for (int i = 0; i < digitLength - numStr.length(); i++) {
			pre.append("0");
		}
		pre.append(numStr);
		return pre.toString();

	}

要不要做冗余字段?

冗余是为了避免join, 但避免join未必要一定冗余。你可以先把A关联的b_id查出来,然后再去B表里查一次。

那么什么情况下应该选择冗余,什么情况下选择查询两次呢?除了要看数据会不会更新,还有一些考虑因素:(大前提是不作join)

1. 如果只需要看A的单行记录,及这行记录对应的B记录,使用两次查询就够了

2. 如果需要查看A的列表,及对应的B记录,那就可以考虑把B记录冗余到A表,也可以不冗余。不冗余的话,就要收集A列表中所有的b_id,然后批量地去B表中执行in查询,稍微有点麻烦

3. 如果需要根据B表中的字段查询A记录,并带出相关的B记录,那就只能用冗余了。为了帮助理解,举个例子:在一个论坛系统的数据库中,找出这样一些“回复”记录,这些回复对应的主贴的作者以"k"开头且回复发表于三天之内,结果中除了要显示“回复”记录,还要显示主贴的作者。 如果“回复”表里没有冗余“主贴作者”字段,这个问题就无解。

mongodb + spring data一起使用时,bean的id应该用什么类型?

mongodb + spring data一起使用时,bean的id应该用什么类型? 在插入bean时我不会设置id的值,而是让mongodb/spring data把生成的_id塞进来。

用原子类型long, int 会有问题;不设置值时,值就是0, mongodb会认为你传的_id值为0. 第一条记录以_id=0插入成功后,插入第二条_id=0的记录时,系统会报键重复的异常。

用Long, Integer行不行? 也不行,因为Spring Data没有内置这样的转换。

正确答案是:String或BigInteger, Spring Data默认只支持这两种类型。参见:ObjectIdToBigIntegerConverter 和 ObjectIdToStringConverter .  或者你可以自定义一个converter, 但我没有去验证。

mongodb出的nosql数据库选型方案

http://www.mongodb.com/lp/whitepaper/nosql-considerations

有自吹的嫌疑,但仍然很有参考价值

==========

摘抄一段使用nosql的三个动机:

(1)In some cases the motivation is technical — such as a need

to scale or perform beyond the capabilities of their existing systems — (2)while in other cases companies are driven by the desire
to identify viable alternatives to expensive proprietary software. (3)A third motivation is
agility or speed of development, as companies look to adapt to the market more quickly and embrace agile development methodologies.

(1) – 大部分nosql都可以自动扩展或者说很容易扩展

(2) – 大部分nosql免费

(3) – nosql没有schema或者schema很弱,需求变更时不需要小心翼翼地、层层审批地增减拆数据库字段;nosql在数据结构方面没有关系的限制,比起rdb有更强的建模能力和适应变更的能力,比如多层嵌套、多态的对象结构,用nosql做起来就很容易。

再抄一段data model的分类

1. key-value and wide-column models

    a. value对数据库来说完全透明,数据库只认key或key family

    b. 只能按key进行数据读写

    c. 一般不支持第二索引

    d. 代表:riak, redis(k/v); hbase, cassandra(wide column)

2. document model . 一条记录就是一个document (比如组装成json格式后再存储)

    a. 数据结构与OO对象可以完美映射

    b. 可以按任何field检索

    c. 支持统计查询

    d. 可以说是多才多艺,应用最广

    e. 代表产品:mongodb, couchdb

3. graph model.  采用图论中的概念来代表数据

   a. 使用node, edge 和 property来表示数据

   b. 关系查询语句执行最快,其他查询可能并不最优

   c. 主要用于强调关系的应用,如社交网络

   d. 代表产品: neo4j, hypergraphdb