loading请求处理中...

浅谈数据库设计都有哪些原则?_数据结构程序之关于建表的知识

2021-12-01 06:24:16 阅读 15003次 标签: 数据库设计 作者: chenliwen666
    提到数据库,我以为不能不先谈数据结构。1996年,在我初入大学学习计算机编程时,当时的教师就通知咱们说:计算机程序=数据结构+算法。虽然如今的程序开发已由面向进程为主逐渐过渡到面向对象为主,但我还是深深附和8年前教师的通知咱们的公式:计算机程序=数据结构+算法。面向对象的程序开发,要做的榜首件事即是,先剖析全部程序中需处置的数据,从中提取出笼统模板,以这个笼统模板设计类,再在其间逐渐添加处置其数据的函数(即算法),最终,再给类中的数据成员和函数区分拜访权限,然后完成封装。下面进入正题,首先按我个人所接触过的程序给数据库设计人员的功底分一下类:

  1、没有系统学习过数据结构的程序员。这类程序员的作品往往只是他们的即兴玩具,他们往往习惯只设计有限的几个表,实现某类功能的数据全部塞在一个表中,各表之间几乎毫无关联。网上不少的免费管理软件都是这样的东西,当程序功能有限,数据量不多的时候,其程序运行起来没有什么问题,但是如果用其管理比较重要的数据,风险性非常大。
  2、系统学习过数据结构,但是还没有开发过对程序效率要求比较高的管理软件的程序员。这类人多半刚从学校毕业不久,他们在设计数据库表结构时,严格按照教科书上的规定,死扣E-R图和3NF(别灰心,所有的数据库设计高手都是从这一步开始的)。他们的作品,对于一般的access型轻量级的管理软件,已经够用。但是一旦该系统需要添加新功能,原有的数据库表差不多得进行大换血。
  3、第二类程序员,在经历过数次程序效率的提升,以及功能升级的折腾后,终于升级成为数据库设计的老鸟,第一类程序员眼中的高人。这类程序员可以胜任二十个表以上的中型商业数据管理系统的开发工作。他们知道该在什么样的情况下保留一定的冗余数据来提高程序效率,而且其设计的数据库可拓展性较好,当用户需要添加新功能时,原有数据库表只需做少量修改即可。
  4、在经历过上十个类似数据库管理软件的重复设计后,第三类程序员中坚持下来没有转行,而是希望从中找出“偷懒”窍门的有心人会慢慢觉悟,从而完成量变到质变的转换。他们所设计的数据库表结构有一定的远见,能够预测到未来功能升级所需要的数据,从而预先留下伏笔。这类程序员目前大多晋级成数据挖掘方面的高级软件开发人员。
  5、第三类程序员或第四类程序员,在对现有的各家数据库管理系统的原理和开发都有一定的钻研后,要么在其基础上进行二次开发,要么自行开发一套有自主版权的通用数据库管理系统。
  我个人正处于第三类的末期,所以下面所列出的一些设计技巧只适合第二类和部分第三类数据库设计人员。同时,由于我很少碰到有兴趣在这方面深钻下去的同行,所以文中难免出现错误和遗漏,在此先行声明,欢迎大家指正,不要藏私哦8)
  一、树型关系的数据表
  不少程序员在进行数据库设计的时候都遇到过树型关系的数据,例如常见的类别表,即一个大类,下面有若干个子类,某些子类又有子类这样的情况。当类别不确定,用户希望可以在任意类别下添加新的子类,或者删除某个类别和其下的所有子类,而且预计以后其数量会逐步增长,此时我们就会考虑用一个数据表来保存这些数据。
  二、商品信息表的设计
  假设你是一家百货公司电脑部的开发人员,某天老板要求你为公司开发一套网上电子商务平台,该百货公司有数千种商品出售,不过目前仅打算先在网上销售数十种方便运输的商品,当然,以后可能会陆续在该电子商务平台上增加新的商品出售。现在开始进行该平台数据库的商品信息表的设计。每种出售的商品都会有相同的属性,如商品编号,商品名称,商品所属类别,相关信息,供货厂商,内含件数,库存,进货价,销售价,优惠价。
  三、多用户及其权限管理的设计
  开发数据库管理类的软件,不可能不考虑多用户和用户权限设置的问题。尽管目前市面上的大、中型的后台数据库系统软件都提供了多用户,以及细至某个数据库内某张表的权限设置的功能,我个人建议:一套成熟的数据库管理软件,还是应该自行设计用户管理这块功能,原因有二:
  1.那些大、中型后台数据库系统软件所提供的多用户及其权限设置都是针对数据库的共有属性,并不一定能完全满足某些特例的需求;
  2.不要过多的依赖后台数据库系统软件的某些特殊功能,多种大、中型后台数据库系统软件之间并不完全兼容。否则一旦日后需要转换数据库平台或后台数据库系统软件版本升级,之前的架构设计很可能无法重用。
  下面看看如何自行设计一套比较灵活的多用户管理模块,即该数据库管理软件的系统管理员可以自行添加新用户,修改已有用户的权限,删除已有用户。首先,分析用户需求,列出该数据库管理软件所有需要实现的功能;然后,根据一定的联系对这些功能进行分类,即把某类用户需使用的功能归为一类;最后开始建表,这边给出一个数据库设计实例: 
功能表(Function_table)
名称     类型    约束条件   说明
f_id          int        无重复     功能标识,主键
f_name        char(20)    不允许为空   功能名称,不允许重复
f_desc        char(50)    允许为空     功能描述
用户组表(User_group)
名称     类型    约束条件   说明
group_id      int         无重复        用户组标识,主键
group_name    char(20)    不允许为空    用户组名称
group_power   char(100)   不允许为空    用户组权限表,内容为功能表f_id的集合
用户表(User_table)
名称     类型    约束条件   说明
user_id       int         无重复        用户标识,主键
user_name     char(20)    无重复        用户名
user_pwd      char(20)    不允许为空    用户密码
user_type     int         不允许为空    所属用户组标识,和User_group.group_id关联
  采用这种用户组的架构设计,当需要添加新用户时,只需指定新用户所属的用户组;当以后系统需要添加新功能或对旧有功能权限进行修改时,只用操作功能表和用户组表的记录,原有用户的功能即可相应随之变化。当然,这种架构设计把数据库管理软件的功能判定移到了前台,使得前台开发相对复杂一些。但是,当用户数较大(10人以上),或日后软件升级的概率较大时,这个代价是值得的。
  四、冗余数据的取舍
  上篇的“树型关系的数据表”中保留了一个冗余字段,这里的例子更进一步——添加了一个冗余表。先看看例子:我原先所在的公司为了解决员工的工作餐,和附近的一家小餐馆联系,每天吃饭记账,费用按人数平摊,月底由公司现金结算,每个人每个月的工作餐费从工资中扣除。当然,每天吃饭的人员和人数都不是固定的,而且,由于每顿工作餐的所点的菜色不同,每顿的花费也不相同。例如,星期一中餐5人花费40元,晚餐2人花费20,星期二中餐6人花费36元,晚餐3人花费18元。为了方便计算每个人每个月的工作餐费,我写了一个简陋的就餐记账管理程序,数据库里有3个表:
员工表(Clerk_table)
名称     类型    约束条件   说明
clerk_id      int         无重复        员工标识,主键
clerk_name    char(10)    不允许为空    员工姓名
每餐总表(Eatdata1)
名称     类型    约束条件   说明
totle_id      int         无重复        每餐总表标识,主键
persons       char(100)   不允许为空    就餐员工的员工标识集合
eat_date      datetime    不允许为空    就餐日期
eat_type      char(1)     不允许为空    就餐类型,用来区分中、晚餐
totle_price   money       不允许为空    每餐总花费
persons_num   int         不允许为空    就餐人数
就餐计费细表(Eatdata2)
名称     类型    约束条件   说明
id            int         无重复        就餐计费细表标识,主键
t_id          int         不允许为空    每餐总表标识,和Eatdata1.totle_id关联
c_id          int         不允许为空    员工标识标识,和Clerk_table.clerk_id关联
price         money       不允许为空    每人每餐花费
  其中,就餐计费细表(Eatdata2)的记录就是把每餐总表(Eatdata1)的一条记录按就餐员工平摊拆开,是个不折不扣的冗余表。当然,也可以把每餐总表(Eatdata1)的部分字段合并到就餐计费细表(Eatdata2)中,这样每餐总表(Eatdata1)就成了冗余表,不过这样所设计出来的就餐计费细表重复数据更多,相比来说还是上面的方案好些。但是,就是就餐计费细表(Eatdata2)这个冗余表,在做每月每人餐费统计的时候,大大简化了编程的复杂度,只用类似这么一条查询语句即可统计出每人每月的寄餐次数和餐费总帐:
SELECT clerk_name AS personname,COUNT(c_id) as eattimes,SUM(price) AS ptprice FROM Eatdata2 JOIN Clerk_tabsle ON (c_id=clerk_id) JOIN eatdata1 ON (totleid=tid) WHERE eat_date>=CONVERT(datetime,'"&the_date&"') AND eat_date  想象一下,如果不用这个冗余表,每次统计每人每月的餐费总帐时会多麻烦,程序效率也够呛。那么,到底什么时候可以增加一定的冗余数据呢?我认为有2个原则:
  1、用户的整体需求。当用户更多的关注于,对数据库程序设计的规范记录按一定的算法进行处理后,再列出的数据。如果该算法可以直接利用后台数据库系统的内嵌函数来完成,此时可以适当的增加冗余字段,甚至冗余表来保存这些经过算法处理后的数据。要知道,对于大批量数据的查询,修改或删除,后台数据库系统的效率远远高于我们自己编写的代码。
  2、简化开发的复杂度。现代软件开发,完成相同的功能,办法有很多。尽管不用需求程序员通晓绝大部分的开发工具和渠道,可是仍是需求了解哪种办法调配哪种开发工具的程序更简练,功率更高一些。冗余数据的实质就是用空间换时间,尤其是目前硬件的开展远远高于软件,所以恰当的冗余是可以接受的。不过我仍是在最终再着重一下:不要过多的依靠渠道和开发工具的特性来简化开发,这个度要是没把握好的话,后期维护升级会栽大跟头的。
       一品威客网汇聚了数百万专业的综合性网站资讯型网站团购网站电子商务网站宣传展示型网站手机WAP网站程序功能开发数据库设计接口开发服务器系统等优秀威客人才,只要您在网站发布任务需求,就能够吸引众多威客给您献上最好的创意服务。

推荐更多与“浅谈数据库设计都有哪些原则?_数据结构程序之关于建表的知识”相关推荐:

 java网站开发 | 外贸网站建设 | vs2010网站开发 | 手机wap网站开发 | 企业制作wap网站

 网站开发流程 | 团购网站开发 | 数据库设计方法 | 商城jsp网站开发 | wap网站开发教程

 手机网站制作 | 网站开发框架 | 微信3g网站开发 | 数据库设计注意点企业手机网站建设

             




 

数据库设计公司推荐

成为一品威客服务商,百万订单等您来有奖注册中

留言( 展开评论

快速发任务

价格是多少?怎样找到合适的人才?

官方顾问免费为您解答

 
数据库设计相关任务
DESIGN TASK 更多
中学广播站LOGO设计

¥500 已有40人投标

椅子外观设计

¥10000 已有0人投标

为幼儿园设计园徽

¥500 已有58人投标

中式甜品海报设计

¥200 已有0人投标

拆除设备机械设计,微信沟通

¥10000 已有0人投标

老酒店客房翻新求设计效果图

¥500 已有0人投标

东魁杨梅包装箱设计

¥1080 已有0人投标