数据库设计
首先在数据库的选择上，我们使用了SQL Server。在项目的开始阶段，我们考虑过使用哪种数据库，但很快就定下来了。使用SQL Server最大的原因是以前的项目就是用它，必须继承下来。如果这是全新的项目，那估计选的还是SQL Server。如果用SQL Server跟MySQL去比的话，前者是商业性产品，估计会稳定一点。我们对什么性能、大并发量这样的需求是不强的，数据的安全和稳定是最重要的。到了后面，上位机同时支持了SQLite。我们的上位机完成以后，我们发现，上位机的安装不到10秒，而数据库的安装需要半个小时以上。我感觉这是有点本末倒置的。支持SQLite之后，要使用我们的上位机，安装变得十分简便。当然，我们还不敢把SQLite的版本放在一些重要项目上。
上位机使用的数据表主要有三个。
（1）采集数据表。
（2）设备信息表。
（3）因子信息表。
设备信息表和因子信息表的设计并不难，内容我们也已经在上一节里讨论，这里就不赘述了。
采集数据表是用来保存测量的数据的，设计要点有：
（1）数据一般是一分钟保存一条，如果保存10年以上的话，就会有五百多万条数据。
（2）查询的时候，会查分钟数据、小时数据、日数据、年数据等。
（3）每个站点的因子数量是不一样的，有的只有十个不到的因子，有的有两三百个因子。
（4）设备是经常发生变化的，有时候增加一台设备，有时候换掉一台设备，采集数据表的表结构需要动态变化。
根据上面的需求，我们做了这样的设计：
（1）一个数据用两列存储，一个存数值，一个存状态。在存数值的时候，我们用了float类型，因为采集到的数据都是这个类型。但是我们在统计的时候，还有存储大整数的时候遇到了问题。所以还是建议用double去存储数据。
（2）列有时候多，有时候少，但数据库不能没有一个规定的格式。我们把列数定为100，也就是最多存储50个数据。如果超过了50，我们使用分页的方法。例如第38个数据，它在第38列，第0页。而第72个数据，它在第22列，第1页。这种设计其实在查询的时候是比较复杂的，性能也是比较差的。但超过50个数据的站点并不多。
（3）在因子信息表里面，记录了某个因子对应采集数据表里的第几列。要查询一个数据，必须结果因子信息表和采集数据表。
（4）当设备、因子发生变化的时候，采集数据表里的数据不发生变化，只是因子信息表里的对应关系发生改变。
在数据库里加入页的设计其实是不太好的，我们建议按照下面的设计：
（1）最初的列数是0，当添加因子的时候，动态添加列。这样的话，在首次改变结构的时候可能会慢一点，但后面的查询会变得简单。
（2）列删除了意味着数据就不见了，很多时候我们需要先把数据备份好再去删除列。