坚决支持，热烈期盼，进一步发展的参考意见---致AWater先生

li_chen · 发表于 2006-1-9 00:14

坚决支持，热烈期盼，进一步发展的参考意见---致AWater先生(1)
To AWater：
盼望中看到您2006-1-8 12:33:56、2006-1-8 20:50:22的发言。“StoneBase”是一个极其优秀的围棋软件。我们对您表示坚决地支持，并祝愿
“StoneBase”不断发展，不断完善，成为最完美的围棋软件!
1. 一点订正:
您2006-1-8 20:50:22的发言中: "那么我首先来解释一下，什么叫做视图。下个定义，视图就是在源棋谱库的数据基础上福建某些过滤调价后所得到的过滤之后的数据的集合。" 应该为: "那么我首先来解释一下，什么叫做视图。下个定义，视图就是在源棋谱库的数据基础上复建某些过滤条件后所得到的过滤之后的数据的集合。"

2. 您2006-1-8 12:33:56的发言中: "......在2005年7月底的时候，stonebase的网站在网管维护服务器的时候，不幸被误删除。损失了所有的数据，其中包括了stonebase网站留言板中所有棋友们发言，交流意见，提出宝贵想法的内容......"
这里谨将我过去在"stonebase网站留言板"中的两个发言提供如下:
(待续)

[此贴子已经被作者于2006-1-9 0:19:13编辑过]

li_chen · 发表于 2006-1-9 00:15

<

> 坚决支持，热烈期盼，进一步发展的参考意见---致AWater先生(2)
<

><a href="http://www.stonebase.org/gb/show.asp?id=1825" target="_blank" >http://www.stonebase.org/gb/show.asp?id=1825</A> 2005-2-21 23:59:28 li_chen：实现棋谱库有效管理的革命性变革——兼谈对“关于棋谱库设计的一个新想法”的参考意见 如何在棋谱库中避免大量的重局？如何在棋谱库中实现极有效率的管理？这些问题，是目前各个围棋软件（棋谱库软件）作者所面临的最重要的课题之一。 AWater先生的新思路（<a href="http://www.stonebase.org/gb/show.asp?id=1800" target="_blank" >http://www.stonebase.org/gb/show.asp?id=1800</A> 2005-2-19 13:51:57 AWater：“[探讨一下]关于棋谱库设计的一个新想法 ”）体现了优秀软件“StoneBase”作者AWater先生，在继棋谱库文件由以前的三个文件改进为目前的一个独立的数据文件之后，又一次在这方面进行的新探索。这是一个正确的方向，我们表示坚决的支持，并作进一步的修改如下： 1. 不是“把现在的多文件多棋谱库方式合并为单数据文件”，而是把所有的对局棋谱（注意：仅仅是对局谱！这是出现“大量的重局”的最经常、最严重、最重要的领域）合并为一个单数据文件（棋谱库），而把“死活”、“手筋”等教程棋谱合并为另外一个单数据文件（教程库）——这样就解决了该网页2楼叶公好棋先生所担心的问题。 2. 在“单数据文件（棋谱库）”中，每局棋谱只出现一次、而且是唯一的一次——所有的重局检测、重局删除均在此处进行即可。这是对局谱方面唯一的一个真正的物理意义上的棋谱库。在此基础上，所建立的赛事“棋谱库”（例如“富士通杯”、“中国招商银行杯CCTV快棋赛”、“日本本因坊战”、“韩国LG精油杯”等）、棋手姓名“棋谱库”（例如“吴清源对局集”、“聂卫平对局集”、“加藤正夫对局集”、“李昌镐对局集”等）、对局时间“棋谱库”（例如“1999年对局集”、“2004年对局集”等）......均不是真正的物理意义上的棋谱库（并不增加棋谱库的空间）——只不过是建立相应的索引文件而已。 也就是说：使用占用硬盘空间极小的索引文件取代原来的各种分类子棋谱库，这样既可以大大地减少棋谱库的空间，又可以极为有效地实现棋谱库中重局的有效控制。 这个建议与原思路的根本不同在于：1. 可以极为有效地进行重局检测、重局删除工作，使得棋谱库中重局的有效控制成为可能；2. 可以大大地减少棋谱库的空间；3. 由于索引文件占用硬盘空间极小，就可以根据各类使用者的不同需要，更加方便地建立各种各样的“棋谱库”（索引文件）。这是一种带有革命性的飞跃。 不知是否可行？请指正。 由于本建议与原思路出入甚大，因此专题另列。 以上意见，谨供AWater先生参考。
<

>(待续)

li_chen · 发表于 2006-1-9 00:17

<

>坚决支持，热烈期盼，进一步发展的参考意见---致AWater先生(3)
<

>2005-2-24 18:34:52 li_chen： To AWater： 进一步阐明如下： 1. 不是在网上“有一个中央的，专门负责收集整理棋谱的网络棋谱库中心(中央服务器)，然后每个用户使用的软件阅读棋谱都需要连接到这个棋谱库中心上来，每个用户在本地有他自己的分类索引”（300k先生的发言内容只是表达他的感想），而是使StoneBase软件具有以该种方式处理棋谱的功能。 在使用StoneBase处理棋谱的实践中，经常受StoneBase棋谱库中重局过多的困扰。例如马晓春的某个对局，它即可能出现在某赛事棋谱库中，又可能出现在“马晓春对局集”棋谱库中......。在一个软件的棋谱库中重局过多就给棋谱的整理工作带来很大的麻烦。因此，如果StoneBase软件具有该功能，其优势不言而喻！ 遥远的、目前不可能实现的事情没有考虑的必要，需要做的是踏踏实实的目前可以做到的事情。 2. 棋谱的整理工作并不是由软件作者进行（如果那样的话，当然您会有“不是单凭我个人的财力和精力能够做到的”感慨），而是由使用者自己进行。 围棋爱好者既然对围棋有兴趣，那么就会自己进行棋谱的整理工作。而软件是否具有相应的功能，由于涉及电脑方面的专门知识，则是围棋爱好者自己不能解决的问题。因此，软件作者需要做的只是使StoneBase软件具有该功能，而不是棋谱的整理工作。因此，就不存在上述大工作量的问题，自然也就不存在“成本比较高”的问题。 3. “棋友之间进行部分棋谱的交换”——并不存在问题。 使用StoneBase软件，通过某种分类子“棋谱库”（索引文件）把该分类子“棋谱库”的棋谱调入软件界面的右端表格中，然后输出，就可以非常方便地实现“棋友之间进行部分棋谱的交换”。这似乎不应该成为问题。
<

> 问题的关键在于如何解决“这个方式对于性能会有一定的影响”的问题。 任何新生事物、任何软件的新的强大的功能的诞生总是要经过与困难的斗争（有时甚至需要坚持不懈的坚决奋斗）才可能取得成功。先生的StoneBase软件，在将棋谱库文件由以前的三个文件改进为目前的一个独立的数据文件，不是也经历过同样的曲折过程吗（要想提高软件的棋谱库性能，这样的革新显然是必然的、是不容置疑的，尽管这样的革新必然会伴随着“技术上的问题”、“使用者更换棋谱库的麻烦”等等诸多问题）？有史以来，所有的成功者其成功的原因各不相同，但其共同的一点往往都是：他们具有高瞻远瞩的战略头脑，眼光远大，研究、追求的目标抓得准。您说是吧？
<

> StoneBase软件该功能的实现，将极为有效地实现棋谱库的有效管理（这是目前世界上各个围棋棋谱库软件所共同面对的重大难点），将使得StoneBase软件具有不可比拟的巨大优势！ 以上意见，谨供AWater先生参考。 (待续)

li_chen · 发表于 2006-1-9 00:18

<

>坚决支持，热烈期盼，进一步发展的参考意见---致AWater先生(4)<

>由此可见, "视图" 与拙作中的(在源棋谱库基础上建立的)赛事“棋谱库”（例如“富士通杯”、“中国招商银行杯CCTV快棋赛”、“日本本因坊战”、“韩国LG精油杯”等）、棋手姓名“棋谱库”（例如“吴清源对局集”、“聂卫平对局集”、“加藤正夫对局集”、“李昌镐对局集”等）、对局时间“棋谱库”（例如“1999年对局集”、“2004年对局集”等）......等分类子“棋谱库”（索引文件）的设想是基本接近的。很高兴看到“StoneBase”在这方面取得了进步。
3. "在stonebase1.x版本中，打开超大型棋谱库（比如有4万条棋谱记录）时的速度是非常缓慢的，在新的2.0中，我对性能作了优化，在打开超大型的棋谱库时，基本上可以做到无相应延迟或仅延迟2-3秒，因为2.0版中提供了全新的数据库引擎，并且包含有两种优化的数据载入模式，用户也可以自行切换。" 这个改进非常重要。打开超大型棋谱库的速度快慢是围棋棋谱库软件的一大难题、一个极其重要的性能指标。这个改进意义十分重大。 衷心祝贺您取得的极其出色的成绩！同时也希望先生能够进一步深入思考以上参考意见。预祝您取得更大的成就！

[此贴子已经被作者于2006-1-9 0:26:19编辑过]

gm · 发表于 2006-1-9 06:19

'视图功能'原来是Li_Chen先生最早(05年2月!)提出来的!!! 敬礼!

AWater · 发表于 2006-1-9 20:39

谢谢li_chen先生的意见，当时您的意见对我帮助很大，后来由于网站资料丢失，您的很多宝贵意见也都因此而遗失了，实在遗憾。您如果还要其他的意见和建议，可以写信给我，咱们再详细交流。

关于视图的功能，总而言之，是多多得益于您和GM的启发了，再次向你们二位表示感谢。您文章中所提到的，把所有的棋谱都合并成为一个单独的大棋谱库，唔，关于这点，我需要再深思熟虑一下，毕竟这种方式有其利的地方，但也有其不利的方面，我需要在利与不利之间找到一个平衡点，既能够兼顾棋谱管理功能的最大化，也要获得性能的最优化，而且，不仅仅是性能，合并成为一个单一的巨大棋谱库之后，还会有交流，发布，更新的困难。如果采用中央的棋谱数据库方式，这些问题倒也不成为问题了，但是正如以前我们所探讨过得一样，建立一个公共的，庞大，包罗万象的中央棋谱数据库，不是我个人力量所能够运作和进行维护的事情，实在是力不从心啊，所以只能够退而求次啦。

帐号		自动登录	找回密码
密码			注册