【交流】有趣有益，案例分析 11
转眼西西河就四周年了，铁手的宗旨是有趣有益，正琢磨着搞些什么活动能配得上这四个字的，看到河友橡树村的问题，灵光一闪，不如就做个案例分析吧，估计河里有不少人是做应用软件开发的，分析一下，同行交流，总是有益的。


河友橡树村要求的软件，分两步，

初期的要求是这样子的


未来的要求是这样子的


已知情况：
１）橡树村有一些ＶＢ基础
２）橡树村能对ＳＱＬ　ＳＥＲＶＥＲ进行基本操作。

小弟我就不客气，把砖抛出来，大伙不妨写写你们的方案，你们的方案，不必限定技术要求的，各位擅长什么，就写什么，大家交流一下。另外也不妨批评一下小弟的方案，指出不到之处。

橡树村兄也不必客气，如果有需求变化，直接提出来就是，需求变化是正常软件开发的一部分，这样会给这个案例带来更多的乐趣。

请尽量 选转。铁手 荐,最后于2007-07-30 18:20:48改,共1次;

懒厨方案一 1
对前期的要求，客户端用ＡＣＣＥＳＳ，数据库用ＳＱＬ　ＳＥＲＶＥＲ．做开发的时候，可以在开发的机器上，用ＳＱＬ　ＳＥＲＶＥＲ的免费版。开发完毕之后，把数据库移植到正式的服务器上。

对于权限的要求，可以设置不同的ＳＱＬ　ＳＥＲＶＥＲ　Ｒｏｌｅ，让不同的人看不同的Ｔａｂｌｅ／Ｖｉｅｗ。

对于每天新增加的数据，不知数据格式，假设是简单的固定文本格式，可以用Ｂｕｌｋ　Ｃｏｐｙ，在服务器上设置一个任务（Ｃｏｎｔｒｏｌ　Ｐａｎｅｌ　－＞　Ｓｃｈｅｄｕｌｅｄ　Ｔａｓｋｓ），在固定的时间把数据输入数据库。

假如数据格式复杂，可以用ＳＱＬ　ＳＥＲＶＥＲ　的　Ｄａｔａ　Ｔｒａｎｓｆｏｒｍａｔｉｏｎ　Ｓｅｒｖｉｃｅｓ　（ＤＴＳ）处理后再输入。　（ＳＱＬ　ＳＥＲＶＥＲ　２００５　有同样的工具，但不叫　ＤＴＳ，　忘了叫啥了）

这个方案是基于用户不多，要求不高的假设，版本控制，就忽略了。

懒厨方案二 1
对于第二期的要求，有两个假设。

其一是假设客户端没有变化，仅仅是有新的数据要输入，解决方案就很简单了，让网络管理员设置一个ＦＴＰ　Ｓｅｒｖｅｒ，让远处的数据提供者把数据上传过来，定时或者手动把数据抄入数据库即可。

第二个假设，是客户端有较大的改动，数据的分析及处理很复杂，而且需要远处的即时数据（Ｒｅａｌｔｉｍｅ　Ｄａｔａ）。这种开发就比较有趣了。我会把Ａｃｃｅｓｓ移植到ＶＢ．Ｎｅｔ　（或者　ＡＳＰ．Ｎｅｔ，假如想做Ｗｅｂ　Ｂａｓｅｄ的应用程序，好处是远处的用户也很容易使用）。另外，远处还应该设置服务器，来提供这边所需的Ｗｅｂ　Ｓｅｒｖｉｃｅ。

假如是只需要两三个程序员的功夫，用Ｖｉｓｕａｌ　Ｓｏｕｒｃｅ　Ｓａｆｅ来做源码的版本控制就足够了。如果是二三十个程序员的开发，我会推荐Ｒａｔｉｏｎａｌ　ＣｌｅａｒＣａｓｅ．


最后提一下，至于项目管理，测试什么的，我就偷一下懒，暂时不提了。

数据的输入，如果已经有Excel文件的话 1

直接导入SQL Server/Access即可，非常简单，符合橡树的“学生计算机水平较差”的需求。

数据的备份也比较简单，设成每天的自动任务即可。

这其实是用数据库的数据转换、传输等辅助功能完成一些非数据结构的数据控制，有意思。

这个主题挺有意思，鼓励鼓励 1
不过，里面有个很重要的需求必须搞清楚：

如何计算、怎么比较、整理又是什么意思？这些功能应该是这个软件系统的核心吧？

如果只是那样的需求的话 1
Ｖｉｓｕａｌ　Ｓｏｕｒｃｅ　Ｓａｆｅ就足够胜任了。

完全不需要有任何的程序代码啊

而且适合未来需求扩展，Ｖｉｓｕａｌ　Ｓｏｕｒｃｅ　Ｓａｆｅ本身就允许外源访问的

的确如此 1
如果需要处理远程的实时数据还是用web service最好。当年没有这东西就麻烦了，我们原来做的一个系统客户是个大酒厂，在全国各地有许多分公司，系统每天定时拨号连接总公司服务器上传销售数据，服务器端程序汇总输入数据库，前端程序出报表。

agree 1
so I recommend the dataview. He doesn't need to write any code for data download and process, just focus on the data analysis.

这dataview是个面向行业的东西，还是通用的？ 1
能给个链接么？就是好奇。

目前面向行业, 不过我觉得可以定制 2
http://www.sas.com/success/ibm_dataview.html

Dataview是IBM开发的，基于SAS和IBM DB2的SAS 应用。看过IBM的工程师用过，觉得不错。类似做data mining的软件还有corner stone, JMP等等。

挺有意思。看起来象是可以针对其他流程定制。 1
要用这个东西，数据自动采集应该是必需的吧？否则，数据量不够，分析的结果也不具有代表性啊？更别说要做实时分析了。

如果没有理解错的话，DataView是建在OLAP上的吧？分析能力更强？

数据自动采集肯定是的 1
也就是inline-test。offline-test or bench test是另外的东西了。
数据是在生产线上到达某个步骤后批量采集的。采集完后，有权限的工程师就可以分析数据了。我不知道OLAP, dataview整个就是个sas，每一个步骤都有sas script对应。

一直很困惑 1
前面的帖子不少人都提到一个版本控制软件的应用，但我不觉得好用啊。还是举例说明吧。

假设橡树村每天收到３个文本文件，这些文件纪录了３个炉的２４小时温度变化。橡树村需要对比一下不同炉之间的温度差别，其中，一号跟二号炉的数据是公开的，每个用户都可以读的，但三号炉是新工艺，需要保密，只有指定用户才可以看。

在这种情况下，我的做法是把三个炉的数据都先输入ＳＱＬ　ＳＥＲＶＥＲ，创建不同的Ｖｉｅｗ，然后让不同的Ｒｏｌｅ读取各自的Ｖｉｅｗ就是。

请教一下，在这种情况下，如何应用版本控制呢？

例子分析 1
假设橡树村每天收到３个文本文件，这些文件纪录了３个炉的２４小时温度变化。橡树村需要对比一下不同炉之间的温度差别，其中，一号跟二号炉的数据是公开的，每个用户都可以读的，但三号炉是新工艺，需要保密，只有指定用户才可以看。

建立两个文件夹，其中一个存放一号和二号数据，所有用户都可以对一号和二号数据进行读取，另外一个设定权限就可以了，文件流的所有操作可以在WINDOWS下完成，再“拖”到版本管理软件中

另外文件对比功能也可以由版本控制软件的“修改对比”功能来实现。

用数据库来实现这样的功能的确可以，但是有点杀鸡用牛刀了。个人认为，在开发资源比较少的情况下---如果是学校的研究室那就另当别论了，学生实践嘛---发掘现有软件的实用化功能才是王道啊

社会河蟹

倒也！ 1
原来是这个意思。

我想象的情形比这个复杂，例如这些文件是每分钟的纪录，而且橡树村需要知道的是具体温差，然后再根据温差来画曲线。。。。。。。

那也可以 1
问题是你的数据是如何更新的问题，比如其中包括了怎么写到数据库中的操作。

简单来说吧，如果是按秒计算的话，也就是每秒填入若干组数据的话，那么确实用数据库比较好，但问题是如果用大型数据库的话，价格昂贵不说，明显就是浪费了。而如果用ACESS的话，据我所知，它是有连接数限制的，似乎只有不到20个链接可以同时使用，而数据更新又要浪费一个链接...似乎用MYSQL是一个不错的选择，但是MYSQL开发并不适合普通用户，更不用说它的VIEW功能也似乎并不太强（两年甚至就压根没有这个功能），CLOUD之流又明显缺乏基础用户界面...总之，对于一个要求远程链接的，用户数在50左右的，开发以及数据可以由普通用户完成的，在数据读取方面相对强大的项目来说，独立数据库的选择太难了。

而数据如果是按天排入的话，还是版本控制比较好了。

呵呵，微软也有免费的东西的 1
ＭＳＤＥ　（ＳＱＬ　ＳＥＲＶＥＲ　２０００　的免费版），数据库大小的限制是２Ｇ

ＳＱＬ　ＳＥＲＶＥＲ　Ｅｘｐｒｅｓｓ　（２００５的免费版），数据库大小的限制是４Ｇ，

一般的数据处理，绰绰有余了。需要处理更多数据的用户，一般也不是穷人，也不会在乎那点钱了。

大型数据库和价格昂贵不一定划得上等号 1
就拿mysql来说，至少TB级以下的数据库基本上就够用了。以开发方面来看，除非是要用sleepycat之类的嵌入式数据库或支持jdo的OO数据库，oracle、SQL server、sybase、mysql这些以sql做为基本query language的基本上没什么大差别。
从这个项目来说，如果只是数据文件共享的问题，找一个content management的免费软件就可以实现了。如果设计到数据的分析、比较、整理就可大可小了，每天生成的数据文件就算只有几十k，但如果全是数字，几年累积下来的话也相当可观了。