刚起床。。。
你们没有明白我为什么不认同SQL,这个话题暂且不谈,以后再说,要说起来就要说到自由这么一个概念。
来说这道题:
第一,没有必要像7楼所说的搞两个数据类型,relation database(以下简称RDB)之所以这样做,是为了避免数据重复存储的现象。而对于这道题没有这个问题,如果你搞两个数据类型,像7楼里说的(名字,地址) (地址,电话号码),倒是增加了内存的开销,因为地址这个信息被你重复存储了,所以7楼IT_BoBo的建议我不赞同。
第二,我所想到的数据结构和list 有关,又和Vector有关。也就是说,你现在想象一下,你现在有一个很大的容器,容器里放着两个容器,一个容器的类型为list, 其存放每个Element 的地址,另外一个容器的类型为Vector, 其存放Element. 为什么这样做呢?是为了高效的排序。我们来看如果你的数据类型为Vector,当你排序的时候,你怎么做?不管你采用何种排序法,都会出现Element移动的现象,而这个移动就有时间开销,数据为多,数据类型越复杂,移动的时间开销就越大。显然Vector 这个数据类型不行,那么list 呢?list 倒是有一个很大的优点,list 的那个很大的优点就是删除和插入,因为删除和插入对list 来讲就是节点断开和重新连接的问题,你看到了,那个移动现象没有了,那么排序的时候会怎么样呢?排序的时候会有一个copy 的动作,就是说,把某一个节点的内容copy 到一个临时变量,然后删除当前节点,然后将这个临时变量插入到其合适的位置。这个copy 的动作是很不舒服的,尤其对于复杂的数据类型,这个copy 动作将是一个很大的时间开销。那么现在的问题是,有没有可能避免这个copy 动作,回答是没有可能,那么有没有优化的可能?回答是有,那么如何来优化呢? 这就是我这个数据结构做的事情。在Vector里面放的是你的Element,这些Element放进去以后,他们的次序就永远固定了,但是那个list 里面放着每个Element的地址,而地址是一个Integer,现在如果你要对Elemente 排序,当然你排序的还是Vector里面存放的Element,但是他们的次序的变动是那个List里面的地址数据在更改次序,由于采用了List,并且List上面的数据为Integer,那么这个copy的动作就优化到了最极致了,这就是我的想法。我这样的叙述,不知大家能理解否?