浅谈数据库设计二三事

作为程序员,程序设计前的数据库设计非常重要,这将直接关系到紧接着的代码编写工作,这里谈谈有关数据库设计过程中的一些细节问题。

 一.数据表主键的字段选择(ID,Code,Number)

ID(编号)一般是选择GUID,这种格式的字符串是一串全球唯一的字符串。当程序需要调用不同平台上的相同结构的数据库时,建议使用guid来作为主键。这样做的好处是,当在某一平台上汇总不同平台的数据时,同一表中的数据汇总不会出现因为主键相同而无法正常汇总的情况。Code(编码)一般是一串非全数字的字符串,比如字母混合数字格式的字符串。特别是,在设计存在多级关联关系的对象模型时。比如人员部门结构,商品多级分类等树状结构关系的对象模型时(见下图)。

如上图所示的部门结构,在数据库中设置一个部门的编码Code,结构如图中加色的数字。这样做的好处是可以很容易根据这样的编码来取到部门的信息。比如,要获取分局3(0103)下面所属的所有所一级的人员信息,则可截取表中部门编码的前四位,判断其是否等于0103,这样即可获得分局3下面所有所一级的部门编码,再从人员信息表中读取人员信息就非常简单了。Number(序号)一般用在标识记录需要连续计数时,通常是系统自增长生成或者程序自动生成得到。比如某一实物存在多个时,可以使用序号来进行区分。比如图书馆中,一模一样的图书存在多本的时候,可以用一个序号来区别。同时,这样还可以很直观的看出这个对象有多少个相同的个体记录,前提是数据未删除过。设计数据库的时候可以根据具体的情况加以选择,从而达到事半功倍的效果。

        二.空间换时间的思想

当一张主表和多张从表存在主外键关系时,通常的做法是在主表中存取从表记录的主键信息。这样读取信息的时候,就需要联合两张以及两张以上的表进行数据读取和组合得到我们需要的信息。数据库思想中,有提到数据库设计应尽可能避免数据冗余,这样可以节省数据存储所占的空间。但是,在当今社会。硬件技术飞快发展的年代,存储介质的存储空间已经可以越来越大,基本不用考虑数据库占用的问题。尽管存储介质的发展很快,但是电脑的处理速度却难以跟上。所以,设计数据库的时候,尽可能考虑怎么使得操作能够快速响应,以节省用户等待的时间。这就是空间换时间的思想。比如说,主表中需要存储用户表中的用户姓名,用户表数据量很大,那么可以考虑在主表中直接存储用户的姓名而不是保存用户信息记录的主键信息。这样,只查询主表即可得到我们需要的信息,而不需要再去联合用户表去查询了。当然,这里也不是通用的做法,有几点需要注意。首先这个涉及从表的字段应该是基本上不会再和其他的业务过程产生联系的,比如我只需要在查询的时候显示这个名字而不需要对其再错查询或者修改等其他一系列的业务操作。另外呢,这个数据需要作为历史记录去查阅,那么就尽可能存储信息本体而不是信息本体所在表记录的主键了。否则,当从表信息修改之后,再次查询记录的时候就会发现与实际情况不符的情况。比如某家公司的快递寄送人是公司的前台,但是前台总会有人事变动,人不在,但是工号还在,会移交给新人使用。那么记录寄件人的信息时就直接保存寄件人的姓名。有时候,我们还会选择将从表的主键以及信息主体直接存储在主表中。比如保存用户的名字同时存储用户的工号。这样,在检索的时候就可以根据工号直接得到主表信息,同时得到用户的工号和姓名。虽然这样做存在数据冗余的情况,但是为了查询的效率,这样做未尝不是一种好办法。

最后,提一下。数据库的设计应该以实际情况为主,理论为辅,兼顾执行效率。不同情况下,这些做法不一定都适合,具体情况具体分析吧。

时间: 2024-10-22 17:37:24

浅谈数据库设计二三事的相关文章

浅谈数据库设计技巧(转)

说到数据库,我认为不能不先谈数据结构.1996年,在我初入大学学习计算机编程时,当时的老师就告诉我们说:计算机程序=数据结构+算法.尽管现在的程序开发已由面向过程为主逐步过渡到面向对象为主,但我还是深深赞同8年前老师的告诉我们的公式:计算机程序=数据结构+算法.面向对象的程序开发,要做的第一件事就是,先分析整个程序中需处理的数据,从中提取出抽象模板,以这个抽象模板设计类,再在其中逐步添加处理其数据的函数(即算法),最后,再给类中的数据成员和函数划分访问权限,从而实现封装. 数据库的最初雏形据说源

浅谈数据库设计

浅谈数据库设计 数据库设计的重要性:好的数据库设计有下面的一些作用: 1.首先充分体现系统的需求,数据库是为应用服务的,好的数据库设计应该首先能满足应用系统的业务需求,准确的表达数据间关系. 2.保证数据的准确性和一致性,通过主外键.非空.限制.唯一索引等保证数据的健壮. 3.提高数据的查询效率,通过合理表结构,安排物理存储分区.增加索引等方式,提高数据的读取速度,提高查询效率. 4.有好的扩展性,在必要时能根据需求扩展数据结构. 在系统设计中对数据库的设计应考虑哪些设计原则  数据库是整个软件

浅谈数据库框架,见笑,请多指正

浅谈数据库框架,见笑,请多指正 http://weibo.com/p/1001603724746155003486 一友说"插件式存储又割裂了SQL引擎的完整逻辑...总体而言在现有框架下MySQL的优化器没有多大改进的价值". 我们且做个技术分析: 1 插件式框架,可以静态/动态加载组件,方便在同类不同属家的模块间切换,这种设计是良好的. 很多软件的设计都采用了"微内核+插件"这样的方式构筑了强大的应用.如Ecplise生态圈. 2 数据库范围内, MySQL的属

浅谈数据库并发控制 - 锁和 MVCC

在学习几年编程之后,你会发现所有的问题都没有简单.快捷的解决方案,很多问题都需要权衡和妥协,而本文介绍的就是数据库在并发性能和可串行化之间做的权衡和妥协 - 并发控制机制. 如果数据库中的所有事务都是串行执行的,那么它非常容易成为整个应用的性能瓶颈,虽然说没法水平扩展的节点在最后都会成为瓶颈,但是串行执行事务的数据库会加速这一过程:而并发(Concurrency)使一切事情的发生都有了可能,它能够解决一定的性能问题,但是它会带来更多诡异的错误. 引入了并发事务之后,如果不对事务的执行进行控制就会

浅谈数据库去重

关于sql去重,我简单谈一下自己的简介,如果各位有建议或有不明白的欢迎多多指出.推荐网址:www.4-yecao.com 关于sql去重最常见的有两种方式:DISTINCT和ROW_NUMBER(),当然了ROW_NUMBER()除了去重还有很多其他比较重要的功能,一会我给大家简单说说我自己在实际中用到的. 假如有张UserInfo表,如下图: 现在我们要去掉完全重复的数据:SELECT DISTINCT * FROM dbo.UserInfo结果如下图: 但是现在有个新的需求,要把名字为‘张三

透过微博浅谈移动设计规则

[透过微博浅谈移动设计规则]1)清晰的界面布局;2)熟悉的操作控件;3)合理的信息结构;4)可靠的触控范围;5)会呼吸的空间;6)统一的视觉风格;7)舒适的文字排版;8)高质量的图片展示.古有京城八大件,今有爽爷八定律,大家随便感受一下 本文作者 打酱油的孩纸 透过微博浅谈移动设计规则

浅谈数据库之存储过程

浅谈数据库之存储过程 什么是存储过程 如果你接触过其他的编程语言,那么就好理解了,存储过程就像是方法一样. 竟然他是方法那么他就有类似的方法名,方法要传递的变量和返回结果,所以存储过程有存储过程名有存储过程参数也有返回值. 存储过程的优点:    存储过程的能力大大增强了SQL语言的功能和灵活性. 可保证数据的安全性和完整性. 通过存储过程可以使没有权限的用户在控制之下间接地存取数据库,从而保证数据的安全. 通过存储过程可以使相关的动作在一起发生,从而可以维护数据库的完整性. 在运行存储过程前,

浅谈嵌入式软件设计

浅谈嵌入式软件设计 本文在21IC的公众号文章<多年嵌入式编程工程师经验分享:换个角度来编程>基础上结合自己理解而写,部分图片以及文字说明均来自互联网. 前后台模型 模型介绍 当开发过程中不使用OS时,几乎所有的嵌入式程序归根结底都是一个由无法停止的循环为结构构成的,即常见的while(1)或for(;;),用流程图表示就是这样: graph TD stop[结束] start[查询IO或外设状态] --> section1[执行相关业务逻辑] section1 --> condi

数据库设计二《函数依赖和三范式》

函数依赖: 定义:R(U)是在属性集U上的关系模式,X,Y是U的子集.若对于R(U)的任意一个可能关系r,r中的不可能存在两个元组在X上的属性值相等,而在Y上的属性值不等,则称X函数确定Y,或者Y函数依赖X,记作X--->Y. 单纯的概念有点难以理解,通过例子1:属性集U,关系模式R(U),子集X,Y,可能关系r1. 可以理解为X能唯一确定Y,则X--->Y.常用为主键------>其他属性 函数依赖和三范式 函数依赖的分类:完全依赖,部分依赖,传递依赖. 完全依赖和一范式 完全依赖:X