zeuux-universe  - 讨论区

标题:[zeuux-universe] zeuux-universe 摘要, 卷 15, 发布 43

2008年11月18日 星期二 16:56

王峰 wangfengmadking在gmail.com
星期二 十一月 18 16:56:07 CST 2008

python中Web开发有一个比较好的开源框架django,非常好用,针对需求的变化,用这个框架完全可以胜任。

2008/11/18 <zeuux-universe-request在zeuux.org>

> 想在 zeuux-universe 邮件列表发言,请写信给:
>        zeuux-universe在zeuux.org
>
> 要订阅或者退订列表,可以访问万维网地址:
>        http://www.zeuux.org/mailman/listinfo/zeuux-universe
> 或者可以向:
>        zeuux-universe-request在zeuux.org
> 发送主题或者正文为'help'的邮件。
>
> 您可以通过邮件地址:
>        zeuux-universe-owner在zeuux.org
> 联系到此列表的管理员。
>
> 当回信时,请给一个适当的标题,这样会比 "Re:
> Contents of zeuux-universe digest..."更清楚明白。
>
>
> 本日主题:
>
>   1. Re: 请教Python问题 (monnand)
>   2. Re: 请教Python问题 (Zhang Weiwu)
>   3. Re: 请教Python问题 (Xia Qingran)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 17 Nov 2008 16:24:31 +0800
> From: monnand <monnand.deng在gmail.com>
> Subject: Re: [zeuux-universe] 请教Python问题
> To: Zhang Weiwu <zhangweiwu在realss.com>
> Cc: "Zoom.Quiet" <zoom.quiet在gmail.com>, Zeuux
>        <zeuux-universe在zeuux.org>
> Message-ID: <49212A3F.7080307在gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Zhang Weiwu 写道:
> > monnand wrote:
> >
> >> 我把这个项目的背景来介绍一下吧:
> >>
> >> 是北京阜城门外医院来做的一个研究。主要是跟踪调查一批心血管病人的用药和
> >> 健康情况。由于心血管类疾病的致病因素很复杂,因此,还很难确定究竟跟踪哪
> >> 些参数──比如是否跟踪心跳频率等。这样的话,只能想到一点就写在调查表格里
> >> 面。而这个调查──准确说是检查──结果,会存入数据库。而对于每个病人,在初
> >> 次检查后,还需要间隔一定时间后进行几次的复查。之所以需要这么一个平台,
> >> 一来方便医生整理收集检查结果,二来可以在医生登录系统后提醒医生应该复查
> >> 哪些病人。
> >>
> >>
> > 阜外医院的冠脉介入治疗很有名的,与你眼下这个项目有关系吗?
> >
> 好像是心血管方面的,具体我也不清楚,是我老师给我的项目──准确说,这项目一
> 开始是我老师做的,他开始是用php写,后来因为数据库结构设计问题,导致扩展
> 性不好,而且现在要加入对R的支持,因为要用R做数据分析,而我老师认为用
> Python与R接口比较合适,就交给我,让我重新写了。
>
> 其实老实讲,最好的办法是把我老师的程序改改,加一个对R的支持,但是既然老
> 师这么说了,老师那个数据库设计的也确实不太好,而且我也想顺便看看
> python,所以就重写了。
> >> 由于这方面的调查还处于研究阶段,而且就心血管病来讲,不确定性很大。因
> >> 此, Zhang Weiwu所说的"等到需求稳定下来再设计实施"是不太可能了。就这个
> >> 项目而言,如果我们知道了心血管的全部致病因素,那这个研究也就没必要了。
> >>
> >> 这些用户(医生)都不是专业人士,因此"直接采用易用型的数据库产品"也不太
> >> 可能──准确说来,医院之所以找人做这个东西,就是希望有个方便的系统能完成
> >> 这个 研究。
> >>
> >> 这个项目的主要问题就是:
> >> 对于每个被调查的病人,分别有初次检查结果,第一次回访检查结果,第二次回
> >> 访检查结果等N张表格。表格内包含了检查的项──比如有血压,心跳等。而表格
> >> 内究 竟包含多少项,是会逐渐增加的。
> >>
> >> 目前想到了一个方法:
> >>
> >> 对每个数据类型建立一个表(我想这个项目能用到的数据类型就是浮点数,字符
> >> 串 了),表的每项包含:
> >>
> >> sample_id ── 这项数据属于哪位病人
> >> item_id ── 这项数据属于哪张表格中的哪一项(血压,心跳,还是医生备注)
> >> item_value ── 这一项的值
> >>
> >> 再有一个表,可以叫做form_component,写明了哪些表格包含了哪些内容,每项
> >> 有 以下内容:
> >> item_id ── 这一项的ID
> >> form_id ── 这一项指明了该项数据属于哪张表格
> >> item_type ── 这一项数据的数据类型
> >> item_name ── 这一项的专业名称
> >>
> >> 这样的话,如果某张表格新增加一项,那么就在form_component中增加一个元
> >> 素,而对于这一项以后的数据,就存在相应的数据类型中的表里了。
> >>
> > 你说的这即是竖表了。
> >
> >> 这么做的话,会不会让搜索效率比较低?不过据说只有五千多个人的数据,这样
> >> 一 来也就不用担心了。
> >>
> > 五千多人数据应该不会有效率问题。不过可能需考虑第二个问题,即在数据取得之
> > 后的分析问题。可能会遇到projection复杂引起分析用的SQL指令难于控制(考虑
> > 一下一个50行的SQL指令,用你的数据结构几个月后你会感觉50行是比较短的SQL指
> > 令了)。
> >
> > 有没有考虑这种设计方法?
> >
> > 创建一个表:tab_data
> > form_id
> > int_item001
> > int_item002
> > int_item003
> > ....
> > int_item256
> > str_item001
> > str_item002
> > str_item003
> >
> > 创建另外一个表:form_component
> > item_id: 此列值为前面表的列名,如"int_item001"
> > item_friendly_name:
> > item_name:
> > ....
> >
> 这样的话查询起来确实方便了,起码减掉了不少SQL语句的长度。
> 我这就发邮件问问,如果他们对表格的扩展性要求不是很大,并且对空间占用不是
> 很在意,这样的结构可以考虑。
> > 这张表很宽(有数百列),并且用的时候可以肯定多数字段是空的(浪费)。但是
> > 这样在数值分析时方便。否则分析涉及的变量如果有十多个,使用竖表就需要十多
> > 次联合查询,对系统负载不一定大,对人而言是很麻烦的。这样的数据一张表一
> > 行,结构简单是其优点。如果所需观察的研究数据是有限的(比如,当"心率、血
> > 压、……"这样列下去能列完的时候),那么tab_data只需稳定的列数就可以了,列
> > 名也可以更直观一些。
> >
> 数据可能不是有限的,至少目前来讲,他们想尽量全面地获得影响心血管病的因
> 素,所以可能要不断地增加调查的内容。
> > 其实还有别的办法,我下面的话会引起数据库愤青的讨论了:这样的统计分析任务
> > 不一定需要或者最好使用关系型数据库。我们的常识是遇到软件项目就选一个关系
> > 型数据库,原因是关系型数据库能解决所有的情况,但是不是说它最适合解决所有
> > 的情况。比如说,对于患者的研究,当数据审核(验证数据正确并从统计意义上可
> > 以用于分析)完成之后,数据不再有个体上的意义,传统关系型数据库擅于维护针
> > 对个体和其数据的关系,这种情况下不重要了。(上面这句是猜需求的,实际需求
> > 还可能有需对患者跟数年的情况从而驳倒我的猜需求。)
> >
> 目前他们这边的要求是mysql,加上还有一些原来的数据,都是存在mysql中的(天
> 哪……这东西弄完还得有数据迁移问题。实在不想再打点老师那个数据库了)。
> > 非关系型数据有很多种,有些情况下(如部署离线应用程序时)可能最普通的键-
> > 值对应数据库就可以解决很多问题不引起复杂度;有的情况下树型数据库比关系表
> > 更合适(如Directory型数据)等等。就调查类需求而言,比如当调查需求大于分
> > 析需求时(例:政府的随意性应付上级调查),我觉得XML数据库也可以很有效
> > (其原因几句说不清楚,但是你的数据不是这种情况,因为你的分析需求还可能会
> > 比较强)。
> >
> 有空我多看看这方面资料。非关系数据库我好像就用过伯克利DB那样Key-Value型的。
> > 当然这只是想像,实际需求研究是设计的准备工作,工作量可能很大并且涉及内容
> > 很复杂,只有具体研究了需求才能成为评估解决方案的准备。所以我现在说什么解
> > 决方案可能都是空谈。不过你还是可以考虑:
> >
> >    1. 分析是否是医生的期望之一?如果是,分析有何特点?使用什么分析工具?
> >       统计分析工具适合接驳的数据和商业智能(BI)类工具需求的数据就很不
> >       同;如果医院方面觉得分析与你无关,他们自己能做,那么观察他们确定是
> >       否真的是这样,因为这涉及到整个项目的成功,而非仅软件部分的成功。没
> >       有全局观念的软件服务商不是好的服务商。
> >
> 目前他们打算加入对R的支持,用R来做统计分析。但是具体分析什么还不知道……所
> 以我只要做个简单的demo,算个平均数,画个饼形图也许就好了。至于进一步的数
> 据分析,我还真不太清楚。我这就发邮件问问我老师。
> >    2. 数据收集过程和分析过程如何连接?(另外一种思路:收集软件做成分析软
> >       件的前端。现有的开源分析软件有pspp、gretle等等)
> >
> 目前来看,他们的数据输入是通过网页手工录入。之后应该是用R来做分析。但是
> 怎么分析我也不清楚,所以这块还很模糊。这样的话确实有些担心需求上有什么问
> 题。我已经发邮件问了老师。
> >    3. 数据质量如何保证?如果没有考虑这一层,低数据质量如果影响了分析,可
> >       能会在软件设计单位和数据收集单位间扯皮。如果能预先有办法解决或提出
> >       减少麻烦的办法,好的情况下可以获得研发经费谈判的筹码,不好的情况下
> >       也会为未来争议做好了准备。
> >
> 数据收集工作是他们来作(好像还没开始做)。这一点我会转发给老师。
> >    4. 有无办法和医院协定研发成果开源?这并非不可能!我这里就成功说服客户
> >       开源其产品,重要的是使客户了解开源对他是有好处的。具体说如果研究成
> >       果是为了提高研究单位的声誉,那么开源其中部分或全部软件产品,更有利
> >       于其它医院研究,从而使你的客户声誉提高。问他们你的成果有可能卖给其
> >       它医院吗?答案也许是不可能的,原因很多,政策上的或没有好的营销办法
> >       和渠道等。那么,既然不能卖钱,何不开源出去提高原来研究单位的声誉
> >       呢?反正是没有损失的。
> >
> 我老师以前开发的那款是基于一个GPL的CRM系统修改过去的。所以许可证也是GPL
> 的。这次我做的就不清楚了,可能很大程度上依赖我老师──不过我老师对开源倒是
> 很支持
> > 顺便说一下我也有做医院信息产品的经验。
> >
> 呵呵,这太好了,这里果然是高手如云。
>
> 另外,关于"直接采用易用型的数据库产品"的问题:
> 目前医院方面应该是铁了心做个web系统,来协助医生录入信息,并且提醒他们定
> 期回访了。据说这项目是从国家申请了经费,而要是使用已有系统,估计这经费就
> 很难给了。唉~这也很无奈。
>
> 非常感谢Zhang Weiwu,帮了我很大的忙!
>
> --
> Regards
>
> monnand
> Email: monnand在gmail.com
> GTalk: monnand在gmail.com
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 17 Nov 2008 21:42:51 +0800
> From: Zhang Weiwu <zhangweiwu在realss.com>
> Subject: Re: [zeuux-universe] 请教Python问题
> To: monnand <monnand.deng在gmail.com>
> Cc: "Zoom.Quiet" <zoom.quiet在gmail.com>, Zeuux
>        <zeuux-universe在zeuux.org>
> Message-ID: <492174DB.1070302在realss.com>
> Content-Type: text/plain; charset=UTF-8
>
> monnand wrote:
> >>
> >> 有没有考虑这种设计方法?
> >>
> >>
> > 这样的话查询起来确实方便了,起码减掉了不少SQL语句的长度。
> > 我这就发邮件问问,如果他们对表格的扩展性要求不是很大,并且对空间占用不
> > 是 很在意,这样的结构可以考虑。
>
> 看来仍是学校里面的项目了。学校项目是接触实际业务的非常好的机会,恭喜你获
> 得这样的机会,尤其还是有直接和客户沟通的机会。每一位打算从事企业IT应用的
> 学生都应该在大学时见过客户,对了解用户需求是很好的机会,可以扫清楚很多对
> 企业IT服务的误会,不然还以为其实是主要每天在写内核驱动呢。其实我们这行多
> 数人真的没本事写内核驱动之类,我是实际经营企业服务业务的,基本上没有这样
> 底层的可以展现复杂逻辑能力的空间,还是理解与应用多。祝贺你已经从理解一些
> 技术往同时理解需求与应用的方向扩展。
>
> 需求分多层,客户提出的不是他们想要的,他们想要的不是他们应该要的,他们应
> 该要的不是我们想给的。应对需求也分多层,先是客户要什么我们给什么,之后是
> 客户要什么我们巧妙地提供而不吃亏,再后是我们告诉客户他们应该要什么(通过
> 对客户业务的深刻理解达到这一层次),最后在我们打算给的和客户应该要的之间
> 取得好的平衡。其中的学问也是有的,我因为做需求这一块为主,所以谈需求得多
> 些。技术上我不如人的,能提供点帮助觉得很高兴了。
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 18 Nov 2008 11:40:04 +0800
> From: Xia Qingran <qingran在zeuux.org>
> Subject: Re: [zeuux-universe] 请教Python问题
> To: Zhang Weiwu <zhangweiwu在realss.com>
> Cc: "Zoom.Quiet" <zoom.quiet在gmail.com>, Zeuux
>        <zeuux-universe在zeuux.org>
> Message-ID: <49223914.2040900在zeuux.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Zhang Weiwu wrote:
> > monnand wrote:
> >
> >>> 有没有考虑这种设计方法?
> >>>
> >>>
> >>>
> >> 这样的话查询起来确实方便了,起码减掉了不少SQL语句的长度。
> >> 我这就发邮件问问,如果他们对表格的扩展性要求不是很大,并且对空间占用不
> >> 是 很在意,这样的结构可以考虑。
> >>
> >
> > 看来仍是学校里面的项目了。学校项目是接触实际业务的非常好的机会,恭喜你获
> > 得这样的机会,尤其还是有直接和客户沟通的机会。每一位打算从事企业IT应用的
> > 学生都应该在大学时见过客户,对了解用户需求是很好的机会,可以扫清楚很多对
> > 企业IT服务的误会,不然还以为其实是主要每天在写内核驱动呢。其实我们这行多
> > 数人真的没本事写内核驱动之类,我是实际经营企业服务业务的,基本上没有这样
> > 底层的可以展现复杂逻辑能力的空间,还是理解与应用多。祝贺你已经从理解一些
> > 技术往同时理解需求与应用的方向扩展。
> >
> > 需求分多层,客户提出的不是他们想要的,他们想要的不是他们应该要的,他们应
> > 该要的不是我们想给的。应对需求也分多层,先是客户要什么我们给什么,之后是
> > 客户要什么我们巧妙地提供而不吃亏,再后是我们告诉客户他们应该要什么(通过
> > 对客户业务的深刻理解达到这一层次),最后在我们打算给的和客户应该要的之间
> > 取得好的平衡。其中的学问也是有的,我因为做需求这一块为主,所以谈需求得多
> > 些。技术上我不如人的,能提供点帮助觉得很高兴了。
> >
> 这段总结的很精辟!
>
>
> --
> 夏清然
> Xia Qingran
> E-mail: qingran在zeuux.org
> Gtalk: qingran.xia在gmail.com
> MSN: supermanxqr在msn.com
>
>
>
> ------------------------------
>
> _______________________________________________
> zeuux-universe mailing list
> zeuux-universe在zeuux.org
> http://www.zeuux.org/mailman/listinfo/zeuux-universe
>
> ZEUUX Project - Free Software, Free Society!
> http://www.zeuux.org
>
> 结束zeuux-universe 摘要, 卷 15, 发布 43
> **********************************************
>
-------------- 下一部分 --------------
一个HTML附件被移除...
URL: <http://www.zeuux.org/pipermail/zeuux-universe/attachments/20081118/dd57af82/attachment-0001.html>

[导入自Mailman归档:http://www.zeuux.org/pipermail/zeuux-universe]

如下红色区域有误,请重新填写。

    你的回复:

    请 登录 后回复。还没有在Zeuux哲思注册吗?现在 注册 !

    Zeuux © 2024

    京ICP备05028076号