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曾参与的项目建一个数据库文件，这样可以象管理档案那样管理数据库的变迁。当然最好能有更加自动化的办法