呵呵,第一次写技术文章,没想到有这么多人关注,谢谢大家哈,有看客咱就接着写,写的不好您就拍砖。
先说一下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
第四种,状态位 比如未处理,已处理等。
最后,说一下表的连接 。
表的连接,在设计时,有内连接,外连接,一对一,一对多等,但是在客户看来,连接的含义是他可以查询哪些附加的信息,比如他在查销售记录时,可以查询这条记录所在的订单,他在查一个订单时,可以列出订单的所有销售记录。
因此,对于各种连接的处理,在用户的层面,只是表示为一种关系的信息。
好了,呵呵,今天的任务完成,分析了数据库中各个元素,明天争取奉上数据库的设计,哈。。
等各位看官交流拍砖,哈~~~~
系列文章连接
二。数据库组成结构的分析。
三。数据库设计。
四。实体类设计
五。算法实现