不错。但算法大多是现成有的。实现方法也是比较重要的。用语言提供的feature做比较方便，效率确实问题；用数据库操作效率不错，但是大家知道，现在用的关系型数据库在逻辑思维上与程序员的OO、甚至是structural的 ...
很感谢您的指教！也很同意您的观点。机器效率和编程效率的确都要考虑进去。只是我想，在没有出结果之前，可否暂时放下机器效率问题（现在硬件越来越快，慢一点估计影响不大，呵呵），先着重提高编程效率，用一种自己最熟悉、最人性化的语言脚本来编写。即使机器效率慢一点，但起码整个算法思路的关键点已经掌握了。再去考虑移植到别的脚本上或修改算法提速就不难了。纯属个人浅见，见笑了。呵呵。 先顶一下，有空再细看。 数据库的设计理念不是为了优化内存操作，要大数据量外存操作才显得出数据库的囧威武囧。
数据量是相对内存来说的，30年前10m就很大，如今100m也很小。
二、三十年前，都是很可爱小娃娃，如今，却成了很三俗怪叔叔囧。
曾几何时，天真无邪可爱小娃娃。
到现如今，庸俗低俗下流怪叔叔。
囧
[ 本帖最后由 duno 于 2010-5-15 04:05 PM 编辑 ] 恩。我觉得数据库的速度是一方面，还有就是寻路算法也是一方面
一般情况是广度遍历好些。如果为了速度，可以两头一起遍历，找到中间点再分别推算出两把路径 恩。我觉得数据库的速度是一方面，还有就是寻路算法也是一方面
一般情况是广度遍历好些。如果为了速度，可以两头一起遍历，找到中间点再分别推算出两把路径
页:
1
[2]