大家好！
第一次用python做项目，以前只是看过一些它的代码。
现在是用django，需要提供一个用户接口，让用户可以通过网页的方式，为数据库
中添加表。这除了直接写SQL语句外，django是否提供了什么途径来完成这个任
务？如果django不行，又有什么好办法呢？

这个添加表的操作不是很频繁，但是相对来说比较重要。

-- 
Regards

monnand
Email: monnand在gmail.com
GTalk: monnand在gmail.com

2008/11/13 monnand <monnand.deng在gmail.com>:
> 大家好！
> 第一次用python做项目，以前只是看过一些它的代码。
> 现在是用django，需要提供一个用户接口，让用户可以通过网页的方式，为数据库
> 中添加表。这除了直接写SQL语句外，django是否提供了什么途径来完成这个任
这是最不提倡的渠道哪！
先看一下文档吧,,,

> 务？如果django不行，又有什么好办法呢？
>
> 这个添加表的操作不是很频繁，但是相对来说比较重要。
>



-- 
http://zoomquiet.org'''
过程改进乃是催生可促生靠谱的人的组织!
PE keeps evolving organizations which promoting people be good!'''
[HR]金山软件常年招聘大量Py/C++人才!
https://groups.google.com/group/python-cn/web/ot-py-c
简历直投俺就好;-)

Zoom.Quiet 写道:
> 2008/11/13 monnand <monnand.deng在gmail.com>:
>   
>> 大家好！
>> 第一次用python做项目，以前只是看过一些它的代码。
>> 现在是用django，需要提供一个用户接口，让用户可以通过网页的方式，为数据库
>> 中添加表。这除了直接写SQL语句外，django是否提供了什么途径来完成这个任
>>     
> 这是最不提倡的渠道哪！
> 先看一下文档吧,,,
>   
非常感谢！
知道这里python牛人多。所以来这里了。

你所说的不提倡是说不提倡直接用SQL语句，还是不提倡在运行中为数据库加表？

如果是前者，我也觉得有点不太合适……所以才想问一下，有没有其它的办法。

这个项目是一个记录调查数据的网站。由于这项调查正处于研究阶段，所以究竟调 
查哪些项还在实验中（比如究竟是否调查身高体重心跳频率）。但是这些调查结果 
需要存在数据里面，而要调查的内容又不确定，所以数据库的表结构是会改变的。 
不过目前能确定的是：
o 调查项只增不减。比如今天查血压，以后必然都要查血压
o 调查项的添加不会过分频繁，也许几个月加一些。而且每次添加都会是添加几个 
相关的调查项──比如这次添加的是体检指标，那么就是心跳频率，血压，身高等一 
块加进去了。

因此，我才想到每次添加就添加一张表，这样不会对以前的表结构产生影响。简单 
说来，这部分的功能就好像为数据库提供一个web界面。

正在看django的文档，目前还没找到合适的途径。如果每次添加表就自动生成一个 
python代码，添加一些module，然后再同步数据库，这是不是不太合适？
>   
>> 务？如果django不行，又有什么好办法呢？
>>
>> 这个添加表的操作不是很频繁，但是相对来说比较重要。
>>
>>     
>
>
>
>   


-- 
Regards

monnand
Email: monnand在gmail.com
GTalk: monnand在gmail.com

monnand wrote:
>
> 知道这里python牛人多。所以来这里了。
>
> 你所说的不提倡是说不提倡直接用SQL语句，还是不提倡在运行中为数据库加表？
>
> 如果是前者，我也觉得有点不太合适……所以才想问一下，有没有其它的办法。
>
> 这个项目是一个记录调查数据的网站。由于这项调查正处于研究阶段，所以究竟 
> 调查哪些项还在实验中（比如究竟是否调查身高体重心跳频率）。但是这些调查 
> 结果需要存在数据里面，而要调查的内容又不确定，所以数据库的表结构是会改 
> 变的。 不过目前能确定的是：
> o 调查项只增不减。比如今天查血压，以后必然都要查血压
> o 调查项的添加不会过分频繁，也许几个月加一些。而且每次添加都会是添加几 
> 个相关的调查项──比如这次添加的是体检指标，那么就是心跳频率，血压，身高 
> 等一 块加进去了。
>
> 因此，我才想到每次添加就添加一张表，这样不会对以前的表结构产生影响。简 
> 单 说来，这部分的功能就好像为数据库提供一个web界面。
>
> 正在看django的文档，目前还没找到合适的途径。如果每次添加表就自动生成一 
> 个 python代码，添加一些module，然后再同步数据库，这是不是不太合适？
虽然说现在能用写raw SQL的方法动态的添加表：
http://docs.djangoproject.com/en/dev/topics/db/sql/

但是这样做models提供的种种便利也就不存在了:(

根据现在django的玩法，models -> views - > template，如果model经常变，例 
如经常增加还没找到在django下很好的法子。

>>  
>>> 务？如果django不行，又有什么好办法呢？
>>>
>>> 这个添加表的操作不是很频繁，但是相对来说比较重要。
>>>
>>>     
>>
>>
>>
>>   
>
>


-- 
夏清然
Xia Qingran
E-mail: qingran at zeuux.org
Gtalk: qingran.xia at gmail.com
MSN: supermanxqr at msn.com

2008/11/13 Xia Qingran <qingran在zeuux.org>:
> monnand wrote:
>>
>> 知道这里python牛人多。所以来这里了。
>>
>> 你所说的不提倡是说不提倡直接用SQL语句，还是不提倡在运行中为数据库加表？
>>
>> 如果是前者，我也觉得有点不太合适……所以才想问一下，有没有其它的办法。
>>
>> 这个项目是一个记录调查数据的网站。由于这项调查正处于研究阶段，所以究竟 调查哪些项还在实验中（比如究竟是否调查身高体重心跳频率）。但是这些调查
>> 结果需要存在数据里面，而要调查的内容又不确定，所以数据库的表结构是会改 变的。 不过目前能确定的是：
>> o 调查项只增不减。比如今天查血压，以后必然都要查血压
>> o 调查项的添加不会过分频繁，也许几个月加一些。而且每次添加都会是添加几 个相关的调查项──比如这次添加的是体检指标，那么就是心跳频率，血压，身高
>> 等一 块加进去了。
>>
>> 因此，我才想到每次添加就添加一张表，这样不会对以前的表结构产生影响。简 单 说来，这部分的功能就好像为数据库提供一个web界面。
>>
因此，建议你复习一下DB设计的范式，将增表，转化成增加条目就好,,,

>> 正在看django的文档，目前还没找到合适的途径。如果每次添加表就自动生成一 个
>> python代码，添加一些module，然后再同步数据库，这是不是不太合适？
>
> 虽然说现在能用写raw SQL的方法动态的添加表：
> http://docs.djangoproject.com/en/dev/topics/db/sql/
>
> 但是这样做models提供的种种便利也就不存在了:(
>
> 根据现在django的玩法，models -> views - > template，如果model经常变，例
> 如经常增加还没找到在django下很好的法子。
>
>>>
>>>>
>>>> 务？如果django不行，又有什么好办法呢？
>>>>
>>>> 这个添加表的操作不是很频繁，但是相对来说比较重要。



-- 
http://zoomquiet.org'''
过程改进乃是催生可促生靠谱的人的组织!
PE keeps evolving organizations which promoting people be good!'''
[HR]金山软件常年招聘大量Py/C++人才!
https://groups.google.com/group/python-cn/web/ot-py-c
简历直投俺就好;-)

monnand wrote:
> Zoom.Quiet 写道:
>> 2008/11/13 monnand <monnand.deng at gmail.com>:
>>  
>>> 大家好！
>>> 第一次用python做项目，以前只是看过一些它的代码。
>>> 现在是用django，需要提供一个用户接口，让用户可以通过网页的方式，为数
>>> 据库
>>> 中添加表。这除了直接写SQL语句外，django是否提供了什么途径来完成这个任
>>>     
>> 这是最不提倡的渠道哪！
>> 先看一下文档吧,,,
>>   
> 非常感谢！
> 知道这里python牛人多。所以来这里了。
>
> 你所说的不提倡是说不提倡直接用SQL语句，还是不提倡在运行中为数据库加表？
>
> 如果是前者，我也觉得有点不太合适……所以才想问一下，有没有其它的办法。
>
> 这个项目是一个记录调查数据的网站。由于这项调查正处于研究阶段，所以究竟
> 调查哪些项还在实验中（比如究竟是否调查身高体重心跳频率）。但是这些调查
> 结果需要存在数据里面，而要调查的内容又不确定，所以数据库的表结构是会改
> 变的。 不过目前能确定的是：
> o 调查项只增不减。比如今天查血压，以后必然都要查血压
> o 调查项的添加不会过分频繁，也许几个月加一些。而且每次添加都会是添加几
> 个相关的调查项──比如这次添加的是体检指标，那么就是心跳频率，血压，身高
> 等一 块加进去了。
>
> 因此，我才想到每次添加就添加一张表，这样不会对以前的表结构产生影响。简
> 单 说来，这部分的功能就好像为数据库提供一个web界面。
>
> 正在看django的文档，目前还没找到合适的途径。如果每次添加表就自动生成一
> 个 python代码，添加一些module，然后再同步数据库，这是不是不太合适？
对于表的内容不确定的情况，使用依数据需求调整表结构的方法，会引起一些其它
的问题，主要是数据库结构不稳定所引起的。调查年份和次数多起来后不易处理。
我们处理的一个项目在接手前就已经因为各种调查有500多个数据库表，对数据的
分析例程很不易做。

这种情况下的实现方法中有一种我们（我这里是指我们公司的开发团队）认为适
合，即竖型表。详细资料一下子还不在手边，如需要我可以给你找出来。去年10月
份开始我们在按客户要求研发一套开源的调查专用数据库产品，每年在一省用它生
成约10000份调查问卷数据，调查经常变化，这种情况下的处理我们还是有些经验
的。只是产品交付还没有全部完成，所以还没有作为开源产品发到网上，等交付了
你就可以看到具体实现了。

依情况，如果你们调查数据量不多，调查需求高于分析需求，那么还有其它的技术
实现可能更为适合（比如基于OpenOffice + Xform的XML数据库解决办法）。你如
果可以提供你们项目更多的信息，我乐于多提出一些我的建议^_^

monnand wrote:
>
> 这个项目是一个记录调查数据的网站。由于这项调查正处于研究阶段，所以究竟
> 调 查哪些项还在实验中（比如究竟是否调查身高体重心跳频率）。
如果是这种情况，你有没有考虑到等到需求稳定下来再设计实施，而在实验阶段直
接采用易用型的数据库产品（即不需要SQL知识可以使用的数据库产品）？这类产
品中做得比较好的是OpenOffice Base和Kexi。还有一种不值得推荐但是经常被使
用的叫做MS Access。

这类产品中表的创建都是直接通过UI完成的。等实验进展之后，有了稳定的需求，
再专门写应用程序，并且将使用Kexi期间的数据迁移过去。

我上面说的使用竖表（也和Zoom Quiet说的“因此，建议你复习一下DB设计的范
式，将增表，转化成增加条目就好,,,”）是假设需求就是这样，项目需求就是要能
处理多变的数据。而你说到还在研究阶段，则可能是“目前的暂时需求是能处理多
变的数据”，这种情况下研究竖表和范式可能会overkill了。

所以，还望多提供项目背景和需求信息。

Zhang Weiwu wrote:
> 对于表的内容不确定的情况，使用依数据需求调整表结构的方法，会引起一些其它
> 的问题，主要是数据库结构不稳定所引起的。调查年份和次数多起来后不易处理。
> 我们处理的一个项目在接手前就已经因为各种调查有500多个数据库表，对数据的
> 分析例程很不易做。
>
> 这种情况下的实现方法中有一种我们（我这里是指我们公司的开发团队）认为适
> 合，即竖型表。详细资料一下子还不在手边，如需要我可以给你找出来。去年10月
> 份开始我们在按客户要求研发一套开源的调查专用数据库产品，每年在一省用它生
> 成约10000份调查问卷数据，调查经常变化，这种情况下的处理我们还是有些经验
> 的。只是产品交付还没有全部完成，所以还没有作为开源产品发到网上，等交付了
> 你就可以看到具体实现了。
>   
以前也听说过“竖型表”这种方法，不过还没有详细研究过。
刚才google了一下找到以下资料：
http://www.developer.com/db/article.php/3736011

如果可以的话也发份你们公司的内部资料给我？非常感谢！
> 依情况，如果你们调查数据量不多，调查需求高于分析需求，那么还有其它的技术
> 实现可能更为适合（比如基于OpenOffice + Xform的XML数据库解决办法）。你如
> 果可以提供你们项目更多的信息，我乐于多提出一些我的建议^_^
> _______________________________________________
> zeuux-universe mailing list
> zeuux-universe at zeuux.org
> http://www.zeuux.org/mailman/listinfo/zeuux-universe
>
> ZEUUX Project - Free Software, Free Society!
> http://www.zeuux.org


-- 
夏清然
Xia Qingran
E-mail: qingran at zeuux.org
Gtalk: qingran.xia at gmail.com
MSN: supermanxqr at msn.com

首先我要说：真的非常感谢大家！
感谢Zoom.Quiet，我目前也在考虑数据库表结构的调整。
感谢Xia Qingran，你提供的资料非常有用。
感谢Zhang Weiwu，这里的人果然经验丰富，居然碰到一个有过类似项目经历的。

节约邮件列表资源，大家的邮件我就不一一回复了。

Zhang Weiwu 写道:
> monnand wrote:
>   
>> 这个项目是一个记录调查数据的网站。由于这项调查正处于研究阶段，所以究竟
>> 调 查哪些项还在实验中（比如究竟是否调查身高体重心跳频率）。
>>     
> 如果是这种情况，你有没有考虑到等到需求稳定下来再设计实施，而在实验阶段直
> 接采用易用型的数据库产品（即不需要SQL知识可以使用的数据库产品）？这类产
> 品中做得比较好的是OpenOffice Base和Kexi。还有一种不值得推荐但是经常被使
> 用的叫做MS Access。
> 这类产品中表的创建都是直接通过UI完成的。等实验进展之后，有了稳定的需求，
> 再专门写应用程序，并且将使用Kexi期间的数据迁移过去。
>
> 我上面说的使用竖表（也和Zoom Quiet说的“因此，建议你复习一下DB设计的范
> 式，将增表，转化成增加条目就好,,,”）是假设需求就是这样，项目需求就是要能
> 处理多变的数据。而你说到还在研究阶段，则可能是“目前的暂时需求是能处理多
> 变的数据”，这种情况下研究竖表和范式可能会overkill了。
>
> 所以，还望多提供项目背景和需求信息。
>   
我把这个项目的背景来介绍一下吧：

是北京阜城门外医院来做的一个研究。主要是跟踪调查一批心血管病人的用药和健 
康情况。由于心血管类疾病的致病因素很复杂，因此，还很难确定究竟跟踪哪些参 
数──比如是否跟踪心跳频率等。这样的话，只能想到一点就写在调查表格里面。而 
这个调查──准确说是检查──结果，会存入数据库。而对于每个病人，在初次检查 
后，还需要间隔一定时间后进行几次的复查。之所以需要这么一个平台，一来方便 
医生整理收集检查结果，二来可以在医生登录系统后提醒医生应该复查哪些病人。

由于这方面的调查还处于研究阶段，而且就心血管病来讲，不确定性很大。因此， 
Zhang Weiwu所说的“等到需求稳定下来再设计实施”是不太可能了。就这个项目而 
言，如果我们知道了心血管的全部致病因素，那这个研究也就没必要了。

这些用户（医生）都不是专业人士，因此“直接采用易用型的数据库产品”也不太可 
能──准确说来，医院之所以找人做这个东西，就是希望有个方便的系统能完成这个 
研究。

这个项目的主要问题就是：
对于每个被调查的病人，分别有初次检查结果，第一次回访检查结果，第二次回访 
检查结果等N张表格。表格内包含了检查的项──比如有血压，心跳等。而表格内究 
竟包含多少项，是会逐渐增加的。

目前想到了一个方法：

对每个数据类型建立一个表（我想这个项目能用到的数据类型就是浮点数，字符串 
了），表的每项包含：

sample_id ── 这项数据属于哪位病人
item_id ── 这项数据属于哪张表格中的哪一项（血压，心跳，还是医生备注）
item_value ── 这一项的值

再有一个表，可以叫做form_component，写明了哪些表格包含了哪些内容，每项有 
以下内容：
item_id ── 这一项的ID
form_id ── 这一项指明了该项数据属于哪张表格
item_type ── 这一项数据的数据类型
item_name ── 这一项的专业名称

这样的话，如果某张表格新增加一项，那么就在form_component中增加一个元素， 
而对于这一项以后的数据，就存在相应的数据类型中的表里了。

这么做的话，会不会让搜索效率比较低？不过据说只有五千多个人的数据，这样一 
来也就不用担心了。

非常感谢大家的帮助！

-- 
Regards

monnand
Email: monnand在gmail.com
GTalk: monnand在gmail.com

monnand wrote:
> 我把这个项目的背景来介绍一下吧：
>
> 是北京阜城门外医院来做的一个研究。主要是跟踪调查一批心血管病人的用药和
> 健康情况。由于心血管类疾病的致病因素很复杂，因此，还很难确定究竟跟踪哪
> 些参数──比如是否跟踪心跳频率等。这样的话，只能想到一点就写在调查表格里
> 面。而这个调查──准确说是检查──结果，会存入数据库。而对于每个病人，在初
> 次检查后，还需要间隔一定时间后进行几次的复查。之所以需要这么一个平台，
> 一来方便医生整理收集检查结果，二来可以在医生登录系统后提醒医生应该复查
> 哪些病人。
>
阜外医院的冠脉介入治疗很有名的，与你眼下这个项目有关系吗？
> 由于这方面的调查还处于研究阶段，而且就心血管病来讲，不确定性很大。因
> 此， 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:
....

这张表很宽（有数百列），并且用的时候可以肯定多数字段是空的（浪费）。但是
这样在数值分析时方便。否则分析涉及的变量如果有十多个，使用竖表就需要十多
次联合查询，对系统负载不一定大，对人而言是很麻烦的。这样的数据一张表一
行，结构简单是其优点。如果所需观察的研究数据是有限的（比如，当“心率、血
压、……”这样列下去能列完的时候），那么tab_data只需稳定的列数就可以了，列
名也可以更直观一些。

其实还有别的办法，我下面的话会引起数据库愤青的讨论了：这样的统计分析任务
不一定需要或者最好使用关系型数据库。我们的常识是遇到软件项目就选一个关系
型数据库，原因是关系型数据库能解决所有的情况，但是不是说它最适合解决所有
的情况。比如说，对于患者的研究，当数据审核（验证数据正确并从统计意义上可
以用于分析）完成之后，数据不再有个体上的意义，传统关系型数据库擅于维护针
对个体和其数据的关系，这种情况下不重要了。（上面这句是猜需求的，实际需求
还可能有需对患者跟数年的情况从而驳倒我的猜需求。）

非关系型数据有很多种，有些情况下（如部署离线应用程序时）可能最普通的键－
值对应数据库就可以解决很多问题不引起复杂度；有的情况下树型数据库比关系表
更合适（如Directory型数据）等等。就调查类需求而言，比如当调查需求大于分
析需求时（例：政府的随意性应付上级调查），我觉得XML数据库也可以很有效
（其原因几句说不清楚，但是你的数据不是这种情况，因为你的分析需求还可能会
比较强）。

当然这只是想像，实际需求研究是设计的准备工作，工作量可能很大并且涉及内容
很复杂，只有具体研究了需求才能成为评估解决方案的准备。所以我现在说什么解
决方案可能都是空谈。不过你还是可以考虑：

   1. 分析是否是医生的期望之一？如果是，分析有何特点？使用什么分析工具？
      统计分析工具适合接驳的数据和商业智能（BI）类工具需求的数据就很不
      同；如果医院方面觉得分析与你无关，他们自己能做，那么观察他们确定是
      否真的是这样，因为这涉及到整个项目的成功，而非仅软件部分的成功。没
      有全局观念的软件服务商不是好的服务商。
   2. 数据收集过程和分析过程如何连接？（另外一种思路：收集软件做成分析软
      件的前端。现有的开源分析软件有pspp、gretle等等）
   3. 数据质量如何保证？如果没有考虑这一层，低数据质量如果影响了分析，可
      能会在软件设计单位和数据收集单位间扯皮。如果能预先有办法解决或提出
      减少麻烦的办法，好的情况下可以获得研发经费谈判的筹码，不好的情况下
      也会为未来争议做好了准备。
   4. 有无办法和医院协定研发成果开源？这并非不可能！我这里就成功说服客户
      开源其产品，重要的是使客户了解开源对他是有好处的。具体说如果研究成
      果是为了提高研究单位的声誉，那么开源其中部分或全部软件产品，更有利
      于其它医院研究，从而使你的客户声誉提高。问他们你的成果有可能卖给其
      它医院吗？答案也许是不可能的，原因很多，政策上的或没有好的营销办法
      和渠道等。那么，既然不能卖钱，何不开源出去提高原来研究单位的声誉
      呢？反正是没有损失的。

顺便说一下我也有做医院信息产品的经验。

刚才没注意到这一段话所以再写一信做回复。报歉增加了邮件数量。
monnand wrote:

> 这些用户（医生）都不是专业人士，因此“直接采用易用型的数据库产品”也不太
> 可能──准确说来，医院之所以找人做这个东西，就是希望有个方便的系统能完成
> 这个 研究。
>   

如果你已经研究过这类数据库，那么依你说的为准；不然还是值得考察一下这类数
据库产品的适用性的。这类数据库产品的设计用户就是你所说的“非IT专业人士”。
有一个项目上我们的客户在找我们设计软件方案之前的四年时间里都是自己在没有
IT支持的情况下使用这种易用型产品的，其中数据收集界面可以直接拖放操作；四
年后，直到这种数据库因数据量变大才找到我们设计更好的产品。

不过这样一来可能会把一个订制研发业务变成咨询、培训服务业务，对于国际客户
而言往往不是问题，咨询服务一样是要收费的，但是对国内客户可能不好处理，他
们可能认为只有研发是需要收费的。这要看和客户的沟通了。

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

monnand wrote:
>>
>> 有没有考虑这种设计方法？
>>
>>
> 这样的话查询起来确实方便了，起码减掉了不少SQL语句的长度。
> 我这就发邮件问问，如果他们对表格的扩展性要求不是很大，并且对空间占用不
> 是 很在意，这样的结构可以考虑。

看来仍是学校里面的项目了。学校项目是接触实际业务的非常好的机会，恭喜你获
得这样的机会，尤其还是有直接和客户沟通的机会。每一位打算从事企业IT应用的
学生都应该在大学时见过客户，对了解用户需求是很好的机会，可以扫清楚很多对
企业IT服务的误会，不然还以为其实是主要每天在写内核驱动呢。其实我们这行多
数人真的没本事写内核驱动之类，我是实际经营企业服务业务的，基本上没有这样
底层的可以展现复杂逻辑能力的空间，还是理解与应用多。祝贺你已经从理解一些
技术往同时理解需求与应用的方向扩展。

需求分多层，客户提出的不是他们想要的，他们想要的不是他们应该要的，他们应
该要的不是我们想给的。应对需求也分多层，先是客户要什么我们给什么，之后是
客户要什么我们巧妙地提供而不吃亏，再后是我们告诉客户他们应该要什么（通过
对客户业务的深刻理解达到这一层次），最后在我们打算给的和客户应该要的之间
取得好的平衡。其中的学问也是有的，我因为做需求这一块为主，所以谈需求得多
些。技术上我不如人的，能提供点帮助觉得很高兴了。

Zhang Weiwu wrote:
> monnand wrote:
>   
>>> 有没有考虑这种设计方法？
>>>
>>>
>>>       
>> 这样的话查询起来确实方便了，起码减掉了不少SQL语句的长度。
>> 我这就发邮件问问，如果他们对表格的扩展性要求不是很大，并且对空间占用不
>> 是 很在意，这样的结构可以考虑。
>>     
>
> 看来仍是学校里面的项目了。学校项目是接触实际业务的非常好的机会，恭喜你获
> 得这样的机会，尤其还是有直接和客户沟通的机会。每一位打算从事企业IT应用的
> 学生都应该在大学时见过客户，对了解用户需求是很好的机会，可以扫清楚很多对
> 企业IT服务的误会，不然还以为其实是主要每天在写内核驱动呢。其实我们这行多
> 数人真的没本事写内核驱动之类，我是实际经营企业服务业务的，基本上没有这样
> 底层的可以展现复杂逻辑能力的空间，还是理解与应用多。祝贺你已经从理解一些
> 技术往同时理解需求与应用的方向扩展。
>
> 需求分多层，客户提出的不是他们想要的，他们想要的不是他们应该要的，他们应
> 该要的不是我们想给的。应对需求也分多层，先是客户要什么我们给什么，之后是
> 客户要什么我们巧妙地提供而不吃亏，再后是我们告诉客户他们应该要什么（通过
> 对客户业务的深刻理解达到这一层次），最后在我们打算给的和客户应该要的之间
> 取得好的平衡。其中的学问也是有的，我因为做需求这一块为主，所以谈需求得多
> 些。技术上我不如人的，能提供点帮助觉得很高兴了。
>   
这段总结的很精辟！


-- 
夏清然
Xia Qingran
E-mail: qingran at zeuux.org
Gtalk: qingran.xia at gmail.com
MSN: supermanxqr at msn.com

Zhang Weiwu 写道:
> monnand wrote:
>   
>>> 有没有考虑这种设计方法？
>>>
>>>
>>>       
>> 这样的话查询起来确实方便了，起码减掉了不少SQL语句的长度。
>> 我这就发邮件问问，如果他们对表格的扩展性要求不是很大，并且对空间占用不
>> 是 很在意，这样的结构可以考虑。
>>     
>
> 看来仍是学校里面的项目了。学校项目是接触实际业务的非常好的机会，恭喜你获
> 得这样的机会，尤其还是有直接和客户沟通的机会。每一位打算从事企业IT应用的
> 学生都应该在大学时见过客户，对了解用户需求是很好的机会，可以扫清楚很多对
> 企业IT服务的误会，不然还以为其实是主要每天在写内核驱动呢。其实我们这行多
> 数人真的没本事写内核驱动之类，我是实际经营企业服务业务的，基本上没有这样
> 底层的可以展现复杂逻辑能力的空间，还是理解与应用多。祝贺你已经从理解一些
> 技术往同时理解需求与应用的方向扩展。
>   
非常感谢！
其实这个项目应该是老师的朋友关系了。

前几天参加scilab会议的，本来要写个新闻放在邮件列表里，结果一直没腾出时间。
> 需求分多层，客户提出的不是他们想要的，他们想要的不是他们应该要的，他们应
> 该要的不是我们想给的。应对需求也分多层，先是客户要什么我们给什么，之后是
> 客户要什么我们巧妙地提供而不吃亏，再后是我们告诉客户他们应该要什么（通过
> 对客户业务的深刻理解达到这一层次），最后在我们打算给的和客户应该要的之间
> 取得好的平衡。其中的学问也是有的，我因为做需求这一块为主，所以谈需求得多
> 些。技术上我不如人的，能提供点帮助觉得很高兴了。
>   
我已经开始按照你的建议做了。非常感谢！

-- 
Regards

monnand
Email: monnand在gmail.com
GTalk: monnand在gmail.com