基于数据字典的通用查询系统（二）数据库组成结构的分析
呵呵，第一次写技术文章，没想到有这么多人关注，谢谢大家哈，有看客咱就接着写，写的不好您就拍砖。
先说一下SQL注入的问题，这个确实没有考虑，因为原来一直在做winform，经验甚少，很多都是摸索着来的，所以对这部分不大了解。
好了，接着我们的话题，遵守承诺，今天主题是对数据库组成结构的分析。
我们日常在设计，使用数据库时，主要考虑以下几内容。
1. 表
在一般的数据库中，一般的表都是对应一种实体的相关信息，如一张订单，订单中的一条记录。
2. 表中的列
表中的列表明了实体的每一个属性。
3. 列的数据结构
是用整型，浮点，还是日期，字符串 ，列的数据结构取决于列所要表达的信息。
4. 表和表之间的关系
即表和表之间是怎样进行关联的，也就是实体信息之间的关联方式。
下面沿用上一篇的方式 ，对这些结构在我们这个模块中的地位进行分析。
首先，从数据库中的元素到实体的表示是有一个映射关系的，如一张订单，我们平时和用户表达时，是一张订单，但是在数据库中，应该是表orders,
而所说的订单号，应该是表orders,中的no列。
类似的，进一步说，其实在用户构建查询时，这些操作也是必须的，如他们选择的大于，我们在sql中应该表达为”>”,他们选择并且，我们应当表达为“and”,即如上一篇中的一个回复所说，应当:
You need provide a middle tier to seperate your DB and your client.
this tier provides bussinss-related column list to your client.
这种Middle Tire就要求我们再以后的设计中，对于第每一个有意义的class都要至少有两个属性，一个是显示给用户的，一个是用来组成sql语句的。
表和列的对于我们来说比较好处理。
这里主要说一下数据结构。
要考虑以下几个问题。
1. 用户所见的数据结构，和真实的数据结构不是一一对应的。
比如，我们在数据库中，数值类型就有int,double,decimal,串有varchar,nchar…等等，但是对于要查询信息的用户来讲，他不需要知道这么具体的东西，他只要知道一种属性是数值，是字符串就可以。
2. 用户见的数据结构，和真的结构是有偏差的。
这个，最典型的就是时间的处理，一些数据库的设计为了处理方便，把日期用8位的串存储，如20081217，也有的直接用datetime存储，但是不管用什么进行存储，这个属性反映到用户就是实实在在的时间 。
3. 用户见的数据结构，需要一定的附加信息。
典型的例子就是状态位，我们常会用一个int 或tinyint来存储一条记录的状态，比如0表示未处理，1表示正在处理，2表示已经处理等。
你没有用必要让用户知道0，1，2的含义，但是你要能让他通过查询能够准确的表达自己的意思。即，他可以去查“今天有多少张订单已经处理”，而不是”今天有多少张订单状态为2”，呵呵，这就又回到我们前面说的那个middle tier的问题了。
结合上面这几种情况。我们可以大概的把数据分成四种
第一种，表示数值的数据，可以是int,可以是decimal,…
第二种，字符串 ，这个不用多解释了吧。
第三种，日期和时间，可以是datetime,也可以是char
第四种，状态位 比如未处理，已处理等。
最后，说一下表的连接 。
表的连接，在设计时，有内连接，外连接，一对一，一对多等，但是在客户看来，连接的含义是他可以查询哪些附加的信息，比如他在查销售记录时，可以查询这条记录所在的订单，他在查一个订单时，可以列出订单的所有销售记录。
因此，对于各种连接的处理，在用户的层面，只是表示为一种关系的信息。
好了，呵呵，今天的任务完成，分析了数据库中各个元素，明天争取奉上数据库的设计，哈。。
等各位看官交流拍砖，哈~~~~
系列文章连接
二。数据库组成结构的分析。
三。数据库设计。
四。实体类设计
五。算法实现
