九乡新闻网螺旋的境界线:基于数据字典的通用查询系统（二）数据库组成结构的分析
来源：百度文库 编辑：九乡新闻网 时间：2024/04/28 00:16:49
先说一下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