＋设为首页 ＋添加到收藏夹
可能有一点长，请耐心看完，谢了！！
我公司不大不小，3年来做了几百家较大的商场超市和进销存直接客户，基本上都在本地或周围地区。
大家都知道这样的公司，软件经常在改，只要客户提出有要求，并且确实觉得可行，我们就会改，有时数据库结构都会有改动，改了就直接给客户换程序，这样，几百家客户那里用的是什么样的程序都无从知道，虽然是一套系统，但程序和数据库结构都有差异，一旦有旧客户提出进一步修改要求就很头痛，其它这个修改现在的系统可能早有了，但把程序直接给他并不能用，因为数据库结构变动很大，虽然我们的数据库结构修改一般都会以SQL"脚本"记录下来，但时间久了，也不行，因为不知道客户用的是什么时候的数据库！
我们当然不像有的公司做一个升级程序直接从某个版本升级到一个新版本，因为我们的程序改动太多太快，这样对客户的要求反应很快，但是版本没法控制了，当有几百家客户的时候，就不知道客户用的是什么样的版本了。。。
现在的做法，如果是新近的客户，我们一般有数据库修改的脚本，直接执行就行，但如果是很老的客户，我们就直接把他的数据库换成新的，然后把数据库迁移过来。但是这样，维护工作难度加大，公司几个车天天外面跑，也忙不过来。。。
你们的公司有没有类似的情况？如何解决？另一个问题，就是如果既要对客户的要求反应迅速，又能保证软件的质量，应该如何做法？
版本控制问题确实很头疼。
关注…
study
版本控制不好，特别是类似的业务多了容易乱。重新理清头绪吧，也许很费劲，不过理清了就好了。
数据库升级脚本的执行不要用SQL文件直接执行的方法，你写一个程序，由它来执行，同时你将你的脚本文件采用按日期命名的方法，在数据库内存放有每次执行完升级后的当时所发布的数据库版本，数据库升级程序会判断相应的日期来执行合适的升级脚本
我现在的数据库升级就是这样的
这个问题我都头痛了好几年。
是个问题，这就是通用软件和专用软件的矛盾。
你现在把通用软件做成专业软件来维护，肯定累死了。
为什么在开发的早期不进行版本控制呢。
如果有文档在，也可以解决一些问题，然后在重新开始也不算晚，不过长期这样下去肯定不行的，为了今后的人力、物力的节约，改吧。
如果没有文档，那只能整理了，没有文档的项目是没有办法维护的
如果你们愿意，这可能是一个新的市场，
你对你们的客进行低价位的升级，保持各版本中的一致性，而且，你也说了，这些修改，大都经过确认为有必要，有修改价值，那为什么不把有价值的东西记录下来呢统一升级你们的应用系统中呢？
