BizStruct - 商业架构

分页参见： [url=http://www.cnblogs.com/huyong/archive/2010/12/18/1910253.html]http://www.cnblogs.com/huyong/archive/2010/12/18/1910253.html[/url]

不好 这个仅仅是个 top分页而已 很多种问题都不能解决

[url]http://bbs.blueidea.com/thread-2948254-1-1.html[/url]

我认为应该考虑分类,而不是分页,10条数据就够看来

jyfalcon@gmail.com

楼主有没有什么比较好的实现跳转的sql或者其他解决方法呢？
有可能的话给我发一下吧！准备查询页面用ajax实现
多谢啦！

很不错的解决方法！nice sql
和ajax结合会效率非常高
不用刷新页面，网络传输数据少，sql查询简单
谢谢楼主了
不过个人推荐用上一页和下一页 以及跳转到第几页实现

很不错的解决方法！nice sql
和ajax结合会效率非常高
不用刷新页面，网络传输数据少，sql查询简单
谢谢楼主了
不过个人推荐用上一页和下一页 以及跳转到第几页实现

我并不完全统一阁下的说法，因为很简单，如果要下载500条记录，而我要查询第250条记录，仅仅靠拖动滚动条会把人累死，而有了下一页跳转我们可以一次到位。你也说了所有做的这些都是为了方便用户，所以我认为分页跳转还是有必要存在的。就好比50乘以100，你可以用加法运算一步一步实现，但是也可以用乘法法则一步实现，你说对么！！你的分页算法我挺赞同的，我刚学select top ……时还纳闷为什么要输出前几条语句，看了你的算法我知道了这条语句的一个妙用！

@布尔
可以访问

http://www.bizstruct.cn/JavascriptOnlineObfuscator/BizStruct.js.htm
已经不能访问了吧

很有创意！
支持

http://editor.lionsky.net/JSConfusionWebDemo/Default.aspx

昨天才看到这个JS混淆工具，今天就碰到了这篇大作，不错！！！

function test()
{
document.getElementById('I')
document.GetElementById('I')

}

－－－》
function pOQih2()
{
document.getElementById('I')
document.Nl39s3('I')

}嘿嘿，尝试下

占个位

@
你所抱怨的客户体验和速度，恰恰是我们产品的优势；如果你打开其他的网站速度很快，而我们的网站速度慢的话，可能原因是电信和网通的互联，我们的网站是电信的。另外长时间没有访问，第一次打开也会慢一些。
我们的架构到现在为止除了持久层，前面两层都不允许写 SQL 语句；你所看到的，我们在文章里写的SQL语句，都是我们在持久层里，为了支持前台的分页，而自动生成的；前台只需传回对象名，页大小和上一页末记录的主键即可，分页相关的 SQL 语句都是持久层生成的；另外支持 SQL 语句的分页，就是持久层配置的任意的 SQL 语句，都可以实现分页功能。

@BizStruct
呵呵，看样子你很自信

我明白了，确实开始没有理解，这个办法确实不错

@尧尧
NetAdvantage 的演示一开始还真没找到，只看到一些图片的演示，多谢你的提醒，终于找到了。

WEB演示在首页上的，LZ再仔细找找

我看了楼主的文章和演示，觉得这种思路是很好的。
长久以来，因为B/S受网络和编程方式的限制，无法像C/S的程序那样有友好的用户操作界面，可是AJAX技术的应用和编程平台的进步（.NET）使这一点必将改变，未来的编程就是网络的编程。
我认为这种思路是正确的也一定要坚定的走下去，虽然现在很多人已经有个固有思维把B/S和C/S在头脑中分离开来，但这是一种思维定式的表现，不用去理采。
我认为按你这种算法还可以有更好的表现。
支持楼主！也希望大家能开拓思维去分析问题，程序员要有改变世人想法的决心和勇气。

@尧尧
技术只是基础，最终是要为应用服务的；基础牢固了，应用也就能更高一些。

其他功能用NetAdvantage都可以实现的吧 :)

感觉太过于追求技术，不过实现挺好的，学习。

@yzx110
怎么说你才理解呢，完整的语句是

select top 页大小 *
from 表格名
where ((评论数 = 上一页末记录的评论数) and (主键 > 上一页末记录的主键)) or (评论数 > 上一页末记录的评论数)
order by 评论数，主键

实在不信的话，可以看看我们的“基于 AJAX 的下载”的演示，就可以理解，那是一个双主键的表格，生成的SQL语句和上面几乎一样。
主键排序的意义就是为了分页。

@BizStruct
你实际测试一下就知道了，看是否可以根据评论数那样排序

因为首先根据评论数排序后，那么主键的顺序就已经没有什么意义了，
这个条件：((评论数 = 末记录的评论数) and (主键 > 末记录的主键)) or (评论数 > 末记录的评论数)
得不出正确结果。

微软是如何实现的，原理是什么，有没有人做过相关的例子？

我现在遇到C/S中控件加载几万条数据慢的问题，数据库是ACCESS的，
我想知道我如何能像微软的数据库产品那样迅速加载数据，然后拖动滚动条显示其他数据的实现。

@ASDFGHJKL
C/S 下的这个还没有，不过在 C/S 下实现可能不需要我们这么复杂的架构，直接通过编码实现的难度应该不大吧。

有没有在C/S中，像上边说的拉动滚动条实现分页的功能，就像微软的数据库产品一样。

楼主说的这种方式是对的，我想，下一代比较好的数据浏览方式也就是这样的，但在实现技术上，最好是借助于AJAX技术，因为这样的效率应该是最高的，其实象Infragistics公司开发的NetAdvantage控件已经是支持这种效果的了！可以去官方网站看看演示：http://www.infragistics.com

各位争论了半天, 我也没看出个所以然来....

实际上, 最好的分页方法就在你眼前, 各位却不见....

去看看cnbloog的分页方法, 我认为他是目前最好的....

@愚工移山
不是所有的东西都需要测试的，你前面也说了，这个SQL语句很简单，对于有经验的数据库开发人员都应该能够判断这么简单的 SQL 语句的性能。

可能你没有仔细读我们的文章，这些“分页存储过程”的效率在""--我们看来都是很差的--""，因为对于较大的表格第一页和末页的效率，要差到几个数量级；而我们的分页算法，所有页的效率，都和其他算法的第一页效率一样高

怎么计算出来的？能把测试数据发上来吗？

不过有一点收获的就是：
我看了你们做的这个列表，我有一个问题，可以较好的解决啦
嘿嘿

@愚工移山
不知道你是不是理解错了，在我们的b/s中并没有一个页面上长长的滚动条；我们的方案从界面上和你的分页几乎没有差别，差别是操作方式上，不是点击页码按钮，而是点击滚动条。
不知你看没看我们的演示，如果看了应该没有这个疑问。

楼主呀
另外我们认为任意页的跳转功能并不是必要的---你可以这样认为，也可以这样做，都没问题。
但我要拿到项目中去，在b/s中给了客户一个页面上长长的滚动条让他看，肯定会有第二次翻工的，还会挨骂的。

就是你的功能再好，客户不要，哪也是白扯呀

况且，我个人认为你说的c/s里哪样的不要一个翻页，只有一个滚动条的做法，是很差劲的做法，哪简直是一个非人的拆磨。至少对于我来说，非常不喜欢拉着一个滚动条在哪儿的一条一条的拉着看，我喜欢一页面20条或者更少，清楚，明显，看着不累。就这样。

@fuyude.net
如果不看我们的产品，你能理解我们文章吗？既是你能做到，其他人呢？很多思想和技术，都是我们的原创，如果我们只是写文章，会有人认同吗？如果我们实现了，即使别人做不到，他也能认识到。至少比一些空口白说的要好吧。
系统架构的核心是思想，我们在实现自己的架构的时候，尝试了很多种设计，反反复复了很多次，现在的结果是我们努力的结果，我们拿出来和大家共享，作系统架构的人应该能认识到他的价值，也可能他们都知道，只是没说出来。
至于代码对系统架构重要吗？我们的三层架构javascript，控件，持久层都是互相依靠的，单独一层的代码都是无法运行的，如果要真的交流的话，只能开源了，这个我们是做不到的。
至于对海量数据的处理，是你对我们系统不了解的原因，而这个又是后台的，看不见，只能以后用流程描述；数据是一页一页读的，只有所有已读出的数据是缓存的，所谓的后台处理是指对用户是透明的，只要操作滚动条即可。
网页可能是我们认识上的问题吧，总想做得一目了然，让访问者能清楚的认识我们的产品，不会迷惑，所以对美观没太关注。

@will
你的问题写的不清楚。
如果从头往后读，读出的记录数小于页大小，就是最后一页。
如果直接读最后一页，只要倒序即可

select top 页大小 * from 表名 order by 主键 desc

@BizStruct
我想知道最近一頁是怎么分的，在很多情况下，最后一頁的PageSize > RowCount.

（接上）
网上好像有人写过类似的算法，他把查询出来的id放到application中了

我觉得可以通过一个迭代查询将每页第一条记录的id查找出来，当点击转到第几页时实际上执行
select top n from table where _id>=id

而我们的分页算法，所有页的效率，都和其他算法的第一页效率一样高。
真的?
通过游标遍历符合条件的唯一索引字段(只是唯一索引字段不包括表的其他字段)
把需要的唯一索引值找出来再查询一次记录集.

以上方法我是通过Ado.net做的效果还可以，对于放在存储过程中效果会更理想。

@小峰
可能你没有仔细读我们的文章，这些“分页存储过程”的效率在我们看来都是很差的，因为对于较大的表格第一页和末页的效率，要差到几个数量级；而我们的分页算法，所有页的效率，都和其他算法的第一页效率一样高。
另外我们认为任意页的跳转功能并不是必要的。

@tinywang
多谢支持，希望能多提建议，以利我们改进。

搜索一下“分页存储过程”，有很多解决方案的，

使用存储过程分页，效率也非常不错，而且可以实现任意页数的跳转。

不错，我喜欢，虽然还不成熟，但很有潜力。
推出产品后 ，我第一个购买。

@wen3062
GUID的主键，比较是没有问题的。
如果你不加上任何排序的话就是按照主键排序的，加上以后也没有区别。

@yzx110
你说的问题并不存在，我们的排序必须包含主键；如果要按照评论数排序，那么排序的字段是：

order by 评论数，主键

对于评论数重复的记录，实际的条件是：

((评论数 = 末记录的评论数) and (主键 > 末记录的主键)) or (评论数 > 末记录的评论数)

对于多主键的表格排序的原理和上面是一样的，只是更复杂。
GUID的主键比较大小和order by的意义就是为了取出分页的记录。

这个算法基本只能用在很少的场合。

比如说个场景：
博客园的文章里面，要根据评论数降序排序，这个就满足不了了。
因为评论数是会重复的

还有比如GUID的主键，比较大小根本没有意义，怎么order by ?