作者jscorpio1 (我 天蠍)
看板Programming
标题Re: [问题] 资料结构跟资料库的关联
时间Fri Jul 11 10:25:11 2014
首先,感谢几位先进的回应
会PO文的原因是因为看了网路上的一篇文章
连结
http://0rz.tw/qNMbk
因为文中一直强调选对方法能增加执行速度,这当然没错
1亿笔资料,O(n)跟O(1)有着天差地远的效率
因此,才连结到我前一篇文章里所说,到底资料结构跟资料库的关系是什麽?
如那篇文章中所举的范例,100万笔通讯录资料的排序及搜寻
我不清楚的是,资料排序完之後,最终会写入资料库,总不可能一直都放在记忆体吧
既然这样,就像几位先进讲的,资料库在存入资料时已经建立了某种资料结构
我们再用SQL去取出来就是了
那麽,资料结构到底用在哪? 不是说资料库实作了什麽资料结构
而是在程式code中,资料结构用在哪?
或者说,既然资料库都已经实作了如k大所说的B+tree了
那在程式code中,不就只要SQL取出来,在display给使用者就好了
ps.感谢K大的回应,让我修正了上面这一段
问了很笨的问题,请各位包涵 = ="
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 140.120.62.160
※ 文章网址: http://webptt.com/cn.aspx?n=bbs/Programming/M.1405045518.A.628.html
1F:推 KoenigseggG:B+tree 218.161.96.194 07/11 10:46
※ 编辑: jscorpio1 (140.120.62.160), 07/11/2014 10:55:15
2F:推 bxxl:如果你要的东西可以直接用SQL写出来,那本来 114.45.137.253 07/11 11:40
3F:→ bxxl:就不需要在外面搞另外一层资料结构吧 114.45.137.253 07/11 11:40
4F:推 LPH66:SQL 就是把这堆麻烦事给包起来, 用一条指令 140.112.30.32 07/11 14:42
5F:→ LPH66:就可以办到复杂的事情 140.112.30.32 07/11 14:42
6F:→ LPH66:有的时候 SQL 写的不好也是会有效能问题 140.112.30.32 07/11 14:43
7F:→ LPH66:这就是因为 SQL 描述的方式让资料库系统用了 140.112.30.32 07/11 14:44
8F:→ LPH66:比较没效率的方式去进行计算的关系 140.112.30.32 07/11 14:45
9F:→ LPH66:(这种现象就是 Joel 的「抽象渗漏法则」) 140.112.30.32 07/11 14:46
10F:→ LPH66:如果硬是要问「资料结构在哪」, 那只好说 140.112.30.32 07/11 14:48
11F:→ LPH66:它被 SQL 这一层壳给包起来了, 所以表面上 140.112.30.32 07/11 14:48
12F:→ LPH66:看似一条指令实际上底下就是用这些资料结构 140.112.30.32 07/11 14:49
13F:→ LPH66:在做苦工... 140.112.30.32 07/11 14:49
14F:→ azureblaze:程式的工作不只是从资料库捞东西显示 36.224.100.32 07/11 15:10
15F:→ Killercat:所以ORM跟DAO如此重要(耶稣光) 59.124.251.135 07/11 15:15
16F:→ mars90226:假如你要用资料做甚麽特殊运算,就可能 1.171.163.140 07/11 17:19
17F:→ mars90226:需要特别的资料结构与演算法来做 1.171.163.140 07/11 17:20
18F:→ mars90226:如果只是简单的显示资料,当然没差 1.171.163.140 07/11 17:20