|
该帖已经被评为隐藏帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-05-18
lgx522 写道 ray_linn 写道 数据量再大也是可以解决的，以医院为例子，仓库里的药也不过就是数万种，常开的处方也就数千种，常用药呢，数量则更少。 其实HIS系统，药相对少得多，诊疗检查项目才够多。原先PB做的HIS，是把拼音字头映射的好多个txt存在本地，每次启程序的时候检测更新并加载进内存。拼音字头作输入、名称作显示、编码为条件，到数据库里查规格、价格、库存等信息，Client根据根据输入的项目、数量计算种类和价格，格式化后打印。 原先用C/S实现还是比较容易的，不知Ajax是否可以很好地实现。 这个也简单，签名的applet和activex也可以做到 |
| 返回顶楼 | |
|
发表时间：2007-05-18
dengyin2000 写道 ray_linn 写道 dengyin2000 写道 把数据现load到client端，也就是javascript中。 如果数量太大的话，该怎样处理。 也可以先load到server中。 然后通过ajax取数据。 但是这样的话实时性就差点 数据量再大也是可以解决的，以医院为例子，仓库里的药也不过就是数万种，常开的处方也就数千种，常用药呢，数量则更少。 那么javascript加载常用药，ajax取不常用药。 我增对的当然不是才几千条这样的数量。。 当然 如果数据上万 几十完的话swing也是有同样的问题。 如果数据量这么大， 肯定还是要每次发送sql去查找数据库了。 实时性肯定降低。 但是swing少了数据传输的过程。可能实效性可能会好点 任何依靠人工输入的数据，都有一定的hit rate，因为人自身的记忆能力就是有限的，这是我的设计的依据。从新回到药品吧，一个科一天开的药品和检查，一定是某个大集合的小子集，所以一定能设计出一种类似cache的模式来提高响应速度。 你说的是最坏的情况是影响大，但发生率低的。 |
| 返回顶楼 | |
|
发表时间：2007-05-19
LZ好好去看看PB11吧
开发BS软件,那速度也算得上是天下第一了!!!!! 可惜PB11没有使用AJAX技术,否则要一统江湖了 |
| 返回顶楼 | |
|
发表时间：2007-05-19
抛出异常的爱 写道 数量太大的话。。。。
一个cookie的树你认为怎么样？ PS：变态需求什么时候都有，大多数作不出来。。。但我的任务就是用变态方式来解决变态需求 能不能具体谈谈...我猜想是不是这样的: www.mycompany.com path = /node0 path = /node0_node1 path = /node0_node1_node2 cookie值按一定优先级排序存储到不同的 nodexxx 里,找某样东西的时候,就直接在内存中查找节点名字,再去取得相应名字所对应的cookie里的数据? |
| 返回顶楼 | |
|
发表时间：2007-05-19
企业应用访问量不大、对界面美观没有什么要求，不限于浏览器访问，用PB/VB/DELPHI开发是唯一的选择。但如果反过来，访问量巨大，只能用浏览器访问，你再用PB试试？访问量可以有办法，但"限于浏览器"这一条是谁也躲不过去的。WEB应用和企业应用解决的是不同的问题，根本没有可比性。
|
| 返回顶楼 | |
|
发表时间：2007-05-19
楼上的都是king of night?
|
| 返回顶楼 | |
|
发表时间：2007-05-19
ray_linn 写道 任何依靠人工输入的数据，都有一定的hit rate，因为人自身的记忆能力就是有限的，这是我的设计的依据。从新回到药品吧，一个科一天开的药品和检查，一定是某个大集合的小子集，所以一定能设计出一种类似cache的模式来提高响应速度。 你说的是最坏的情况是影响大，但发生率低的。 对于某一些特定岗位的工作人员，会面临从数万乃至数十万的列表中快速输入某个值的要求。 虽然可以通过树型展开，但是速度就达不到要求。 所以比较常见的设计做法就是用户输入前几个数字或字母，在下拉列表中即时刷新可选择项，其实和google目前的搜索效果差不多。 但需要注意的是google返回的结果列表只有5个，因为它不需要把所有满足条件的结果都列出来. 但是在企业应用中,应当把所有的结果都列出来,这样下拉列表中的值都有数百乃至上千项,而且要让用户感觉不到延迟. |
| 返回顶楼 | |
|
发表时间：2007-05-19
clamp 写道 ray_linn 写道 任何依靠人工输入的数据，都有一定的hit rate，因为人自身的记忆能力就是有限的，这是我的设计的依据。从新回到药品吧，一个科一天开的药品和检查，一定是某个大集合的小子集，所以一定能设计出一种类似cache的模式来提高响应速度。 你说的是最坏的情况是影响大，但发生率低的。 对于某一些特定岗位的工作人员，会面临从数万乃至数十万的列表中快速输入某个值的要求。 虽然可以通过树型展开，但是速度就达不到要求。 所以比较常见的设计做法就是用户输入前几个数字或字母，在下拉列表中即时刷新可选择项，其实和google目前的搜索效果差不多。 但需要注意的是google返回的结果列表只有5个，因为它不需要把所有满足条件的结果都列出来. 但是在企业应用中,应当把所有的结果都列出来,这样下拉列表中的值都有数百乃至上千项,而且要让用户感觉不到延迟. B/S又不是神。。。 有个一百左右cookies就受不了。。 |
| 返回顶楼 | |
|
发表时间：2007-05-19
clamp 写道 ray_linn 写道 任何依靠人工输入的数据，都有一定的hit rate，因为人自身的记忆能力就是有限的，这是我的设计的依据。从新回到药品吧，一个科一天开的药品和检查，一定是某个大集合的小子集，所以一定能设计出一种类似cache的模式来提高响应速度。 你说的是最坏的情况是影响大，但发生率低的。 对于某一些特定岗位的工作人员，会面临从数万乃至数十万的列表中快速输入某个值的要求。 虽然可以通过树型展开，但是速度就达不到要求。 所以比较常见的设计做法就是用户输入前几个数字或字母，在下拉列表中即时刷新可选择项，其实和google目前的搜索效果差不多。 但需要注意的是google返回的结果列表只有5个，因为它不需要把所有满足条件的结果都列出来. 但是在企业应用中,应当把所有的结果都列出来,这样下拉列表中的值都有数百乃至上千项,而且要让用户感觉不到延迟. 偶只能说具体事情具体分析, 这个当然有. 业务就是技术,技术就是业务,业务不熟,就常常过度设计. 其实就是ajax,内网里才有多少延迟..10ms吧 |
| 返回顶楼 | |
|
发表时间：2007-05-29
讨论的没什么意思，因为讨论的人里面，大部分都没做过HIS。。。
|
| 返回顶楼 | |
