真正的实战开始了，根据用户的需求首先就是编写了一大堆的这样那样的文档说明，并根据用户需求分析建立了数据库的库表及其内容。
在建库的过程中我们使用的是微软的Sql Server2000数据库，在分析数据库前也在网上游荡了些时日，发现很多人都很支持Oracle数据库（我并没有使用过Oracle数据库，然而领导决定使用Sql Server2000数据库），听说当中有支持空间数据库的概念，可以将整个地图信息都放入数据库中，不知道大家对此有多少了解。而目前我们却是使用Sql Server2000的数据库的，建立了跟应用系统有关的表（如：权限控制方面的表、用户信息表等等）、通信设备有关的表（如：仪器信息表——其中包含仪器的上行和下行数据或命令的格式）、图层有关的表（如：基本图层表和专题图层表。此部分中的表要和图层一一对应，而且每个表中都有一个字段也是和相应图层中的表文件数据一一对应）和非图层的详细信息表（如：被管理者信息表和警告信息表等。主要是表示系统各个部分数据关系以及用到的系统参数设置的表），不知道这样见表有没有不对的地方？还望知道的人能给些回答。
还有一个关于数据库的问题。在原来本人使用Sql Server2000来建立应用程序数据库时，总是希望能加上表和表之间的约束，这样能够使数据库中的数据保证数据完整性，然而最近却让我将这些约束从物理意义上去除，而逻辑意义上还是存在的，那就需要靠编程等方法来实现逻辑意义这些关系约束。比如一张表是部门，一张表是人员，人员是属于部门的，部门和人员是一对多的关系。过去我是在人员和部门两张表间添加一个外键约束；现在却要求我将这个外键去除，在部门中除了自己的主键“记录ID”外再加入一个唯一性的字段“部门编号”，在人员表中也加入同样的“部门编号”字段，而这两张表之间并没有实际的主外键约束，只有逻辑意义上的关系。不知道这样做和以前的做法哪一个更好些。我个人觉得虽然没有实际上的约束使得表更加灵活，独立性更强，但是还是添加主外键约束的更好些，用户在大部分情况下可能更希望数据的准确，所以保证数据库的完整性应该更好些，你们认为呢？
最近数据库已经建立完成了，现在就是在用.Net来开发系统功能程序和公共类的方法。等到这些事情忙完了，相信就该把重点放到ArcIMS以及MapNet上了。
在建库的过程中我们使用的是微软的Sql Server2000数据库，在分析数据库前也在网上游荡了些时日，发现很多人都很支持Oracle数据库（我并没有使用过Oracle数据库，然而领导决定使用Sql Server2000数据库），听说当中有支持空间数据库的概念，可以将整个地图信息都放入数据库中，不知道大家对此有多少了解。而目前我们却是使用Sql Server2000的数据库的，建立了跟应用系统有关的表（如：权限控制方面的表、用户信息表等等）、通信设备有关的表（如：仪器信息表——其中包含仪器的上行和下行数据或命令的格式）、图层有关的表（如：基本图层表和专题图层表。此部分中的表要和图层一一对应，而且每个表中都有一个字段也是和相应图层中的表文件数据一一对应）和非图层的详细信息表（如：被管理者信息表和警告信息表等。主要是表示系统各个部分数据关系以及用到的系统参数设置的表），不知道这样见表有没有不对的地方？还望知道的人能给些回答。
还有一个关于数据库的问题。在原来本人使用Sql Server2000来建立应用程序数据库时，总是希望能加上表和表之间的约束，这样能够使数据库中的数据保证数据完整性，然而最近却让我将这些约束从物理意义上去除，而逻辑意义上还是存在的，那就需要靠编程等方法来实现逻辑意义这些关系约束。比如一张表是部门，一张表是人员，人员是属于部门的，部门和人员是一对多的关系。过去我是在人员和部门两张表间添加一个外键约束；现在却要求我将这个外键去除，在部门中除了自己的主键“记录ID”外再加入一个唯一性的字段“部门编号”，在人员表中也加入同样的“部门编号”字段，而这两张表之间并没有实际的主外键约束，只有逻辑意义上的关系。不知道这样做和以前的做法哪一个更好些。我个人觉得虽然没有实际上的约束使得表更加灵活，独立性更强，但是还是添加主外键约束的更好些，用户在大部分情况下可能更希望数据的准确，所以保证数据库的完整性应该更好些，你们认为呢？
最近数据库已经建立完成了，现在就是在用.Net来开发系统功能程序和公共类的方法。等到这些事情忙完了，相信就该把重点放到ArcIMS以及MapNet上了。
不过空间数据库的建立也是我头一次建立这样的数据库，其中有什么观点不对的地方还请专业人士给出一些自己的见解和经验。
本文转自刚刚博客园博客，原文链接：http://www.cnblogs.com/lijigang/archive/2007/01/18/621665.html，如需转载请自行联系原作者
