2008年11月18日 星期二 16:56
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>
Zeuux © 2024
京ICP备05028076号