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>