螺旋的境界线:基于数据字典的通用查询系统(二)数据库组成结构的分析
来源:百度文库 编辑:九乡新闻网 时间:2024/05/10 06:48:48
先说一下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
第四种,状态位 比如未处理,已处理等。
最后,说一下表的连接 。
表的连接,在设计时,有内连接,外连接,一对一,一对多等,但是在客户看来,连接的含义是他可以查询哪些附加的信息,比如他在查销售记录时,可以查询这条记录所在的订单,他在查一个订单时,可以列出订单的所有销售记录。
因此,对于各种连接的处理,在用户的层面,只是表示为一种关系的信息。
好了,呵呵,今天的任务完成,分析了数据库中各个元素,明天争取奉上数据库的设计
好了,接着我们的话题,遵守承诺,今天主题是对数据库组成结构的分析。
我们日常在设计,使用数据库时,主要考虑以下几内容。
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
第四种,状态位 比如未处理,已处理等。
最后,说一下表的连接 。
表的连接,在设计时,有内连接,外连接,一对一,一对多等,但是在客户看来,连接的含义是他可以查询哪些附加的信息,比如他在查销售记录时,可以查询这条记录所在的订单,他在查一个订单时,可以列出订单的所有销售记录。
因此,对于各种连接的处理,在用户的层面,只是表示为一种关系的信息。
好了,呵呵,今天的任务完成,分析了数据库中各个元素,明天争取奉上数据库的设计
基于数据字典的通用查询系统(二)数据库组成结构的分析
基于DSP的USB口数据采集分析系统设计
数据恢复-->数据恢复之硬盘组成结构完全分析
数据库数据字典
通用润滑脂的组成
基于DSP的实时图像数据采集系统设计c6000
经络系统的组成
基于Verilog的VGA驱动设计(二)VGA硬件结构
Windows下虚拟ASM磁盘搭建基于ASM的Oracle 10g数据库系统
基于ERP系统的制造业库存分析方法
基于树的索引结构
基于RBAC模型的通用权限管理系统的设计(数据模型)的扩展
基于RBAC模型的通用权限管理系统的设计(数据模型)的扩展【转】 -...
跨服务器数据库数据查询
基于SOA的数据共享与交换系统的设计与实现
经络系统的组成1
穴 经络系统的组成
CNC系统的组成形式
可编程控制器的软件系统组成
基于OpenCV和VC6.0的数据监控系统设计
利用表格数据分析合金组成的中考计算题解析
音箱的组成结构及选购技巧
BIOS SLIC 2.1的组成结构
张仲景术的结构组成 QZone Editor