Open caiwang opened 9 years ago
Issue by unissoft-bj Monday Dec 08, 2014 at 11:45 GMT Originally opened as https://github.com/caiwang/ihostsrc/issues/7
会务系统的user数据 需要持续、重复使用 会议筹备过程,也是建立预注册用户的过程 需要有一个小型工作系统,协助会务组提取user数据,发短信,接收并处理短信(待开发)
一种情况是会务组持有ihost,ihost上的数据持续更新。这种情况需要一个数据备份的方案 另一种情况是会务组租用ihost,会议结束后ihost返还,这种情况需要一个数据导出,以及下次再导入的方案
实际上还可能有更复杂的情况,类似于github上的多个分支、合并。中汽中心有多个单位都要组织会议,如果建立一个集中的资源池,每个会务组都成为一个分支,然后合并到资源池,这个有点复杂,先不做考虑了
第一种情况最简单,我们先看第一种方案。不考虑效率的话,感觉github可以用。我现在这个ihost数据库dump出来是4M,如果排除wlpkt(wireless packet)表的话,是1M多。如果我们自己建一个github,为每个ihost建一个repository,在repository中为该ihost曾参与的项目建一个数据库文件,这样可以象管理档案那样管理数据库的变迁。当然最好能有更加自动化的办法
会务系统的user数据 需要持续、重复使用 会议筹备过程,也是建立预注册用户的过程 需要有一个小型工作系统,协助会务组提取user数据,发短信,接收并处理短信(待开发)
一种情况是会务组持有ihost,ihost上的数据持续更新。这种情况需要一个数据备份的方案 另一种情况是会务组租用ihost,会议结束后ihost返还,这种情况需要一个数据导出,以及下次再导入的方案
实际上还可能有更复杂的情况,类似于github上的多个分支、合并。中汽中心有多个单位都要组织会议,如果建立一个集中的资源池,每个会务组都成为一个分支,然后合并到资源池,这个有点复杂,先不做考虑了
第一种情况最简单,我们先看第一种方案。不考虑效率的话,感觉github可以用。我现在这个ihost数据库dump出来是4M,如果排除wlpkt(wireless packet)表的话,是1M多。如果我们自己建一个github,为每个ihost建一个repository,在repository中为该ihost曾参与的项目建一个数据库文件,这样可以象管理档案那样管理数据库的变迁。当然最好能有更加自动化的办法