为了增长数据库中的一个字段 我快要疯了！

由于前人设计的一个表示客户ID的字段设计的只有5个字符长，现在需要升级为6个字符长，我被这个问题折腾地快要疯了！
真不知道怎么会当时需求是5个字符长系统就真设计成了5个字符长的！！！
看来我只能想办法把它从5个长设计到 10个字符长，免得以后再升这个东西了！！最让我崩溃之处在于，这个ID字段所在的表与一大堆至少42个表都建立了关系！！
而且这43每个表的insert，delete，update等都写了触发器，一旦触发就要写日志，这也就罢了，同时还要去更新另外几个无法建立关系的表里面的ID字段！！天啊，让我如何下手啊，刚才我还在想去掉关系，修改所有表这个字段扩长成10，修改所有相关触发器，然后恢复关系，再重新生成相关视图，但只这么一想，我就崩溃了！！
我又想还是先再每个表中新增一个varchar类型的长度为10的NID字段，同时根据ID更新完所有NID，再建立将关系挨个重新建立一遍，然后把客户端程序更新，让其使用NID，就能搞定了！！但这工作量也很大呀
但是无论如何想，我都非常恼火，非常头大！！现在一点好的办法都没有！所有我快要崩溃了！我不知道是为我水平太菜悲哀（我不是专职的开发人员，但很不幸没有人愿意管理我所说的这套系统，公司逼着我这个没有开发经验的人来整这个东西！！），还是为前人留下的烂摊子生气 了！！从来没有这么愤怒过！！今天非常不爽，也来发发牢骚！！

解决方案 »

  1.   

    之前已经因为修改一个触发器方面的bug而让我劳神了一个月！
    今天又突然来这么一下升级！！
    这不是要我的命吗？？
      

  2.   

    alter table tb alter column id char(6) not null
      

  3.   

    SQL code    alter table tb alter column id char(6) not nullto  liangCK
    ====================
    那么这样对某个表的ID进行了修改，系统关系又如何处理呢？其他那40多个表会如何呢？
      

  4.   

    按以下步骤
    1:用SQL企业管理器生成创建整个数据库的sql语句,包括视图触发器,当然也要包括删除语句即DROP
    2:将生成的语句前面部分删除触发器及表间关系的语句选择复制到一个空白的文件中
    3:在刚才创建的文件中扩展所有相关表的字段alter   table   tb   alter   column   id   char(6)   not   null (40多个语句)
    4:从SQL生成的语句中将创建表间关系\触发器\视图分配权限的语句复制到文件中,这样就生成了数据库升级的指令.
    在查询分析器中执行即可完成升级操作.这并不难,只是要小心些,升级前要备份数据库,最好在其他计算机上试好后再在服务器上运行.
      

  5.   

    gfgen所描述的和我想的倒是比较吻合，
    只是我想中间还有一点问题就是如何通过sql语句知道到底一共有哪些具体的表使用了ID作为主键，并且这些相关联的表中该字段又成为了更下一级的哪些表的主键？？
      

  6.   

    笨办法可在企业管理器中挨个查,先在该表的关系中看,然后在在各关联表中看是否有表个这个ID再关联.
    也可以用系统存储过程实现,好象是sp_helpmember英语不好，没记住,可打开事件查看器,看企业关系器是如何查找一个表的关系的.
      

  7.   

    alter   table   tb   alter   column   id   char(6)   not   null 是无法对存在关系的表进行修改的,必须先删除所有关系
      

  8.   

    先将数据库中的所有对象导出脚本(通过企业管理器完成)，
    用grep等工具找到要调整字段涉及的脚本,
    将建表的脚本修改为alter table, 仅保留该字段，并将字段长度调整合适,
    在存储过程、触发器等脚本中找相关变量及临时表字段，调整变量长度及临时表字段长度,
    将所有修改的脚本拿来执行一下。
      

  9.   

    研究一下 5个字符长的 含义， 再来说说 6个字符的含义。 看看能不能用 5个来表示6个。 比如原来的5位 是用数字表示，那么可以扩展为 5位 16进制数来表示， 或用字母来表示。 再甚 可以认为区分大小写， 这样每位可以表示 0-9 a-z A-Z 62中可能性了。 再不行还可以启用 符号来表示， 比如 +-()等等，让每位表示的含义 增多后， 看看能不能不加字长。
      

  10.   

    由于种种原因，这个扩展字段长度的措施我没有实施。
    我看了一下各位的见解和主意，都有各自的道理。在此我提醒各位一句，在设计系统的时候，千万要对这种关键字段的扩展性留有足够的余地；即使不留余地，也要让以后扩展能够改动较小，不能为了适应未来的扩展被迫进行大幅度的修改，而且这种被动的修改是要命的；关系也不要建得太深，尤其3级及以上的关系！！！（其实我自己没怎么学习过sql的理论或者数据库的课程，并不清楚真正合理的结构应该是什么样的深度）上面只是我的个人感悟吧。
    谢谢各位的关注了。
      

  11.   


    赞成确实工作量很大，并且你在修改的过程有可能会出现BUG，认真想一下是不是有替代的方法，并不只有修改这一条路可以走。感觉上面的这种要求有些不合理，这次花N多时间改了客户ID，说不定下次上面又要求改供应商ID，那你就晕菜了，个人觉得forpr说的完全可以满足你们上面的要求，客户ID无非是一个唯一的客户标志而已，5位表示完全足够了，有很多种组合的方式。