数据库面对不同业务逻辑约束条件的选择

数据表的约束我觉得还是很有用的,至少在数据库优化方面还是用的比较多的,可以大大的提高检索效率,作用也是比较明显的,另外一点,表的约束可以在某种程度上简化程序代码端的业务逻辑量,这寄存于DBMS上面,其维护性我绝得韩式比较高的,这一般类型的数据库里面,我们常见的约束有:主键,外键,为空,唯一等,这四类是比较常见的约束,我绝对约束的实质应该是为真实的业务逻辑而服务的,否则则没有意义,所以,面对不同的业务逻辑逐一的进行分析:

1:什么情况下使用主键:

主键的含义是唯一且不为空,所以根据这个规范,能够满足的业务逻辑有很多的,列如我们常见的ID值,必须存在而且不存在为空的情况,一般来说一个表的会有一个主键,至少方面以后的操作,因为无论无论dql语句还是dml语句都得需要唯一不为空的标识符当做索引值,而且,无特殊的逻辑要求,会要求主键自增张:auto_increment;这样也是符合一般的逻辑要求的,还可以提高检索速度。

2:什么情况下使用外键:

表的外键其实就是主表对于本表的一个约束,说白了就是就是在外键字段要求的范围内,表示的是一个主从关系,例如部门表和员工表的关系。部门表是一个主表,有一个主键值,那么如果员工表想要和主表建立主从关系就要建立一个外键,这里必须明白一个地方,什么所谓的建立外键都在建立在从表里面的,主表和普通的操作没有任何区别,在从表建立的外键就是一个指定主表主键的关系,这样的话就构成了一个约束关系,比如说一个员工属于哪一个部门的关系这样距可以确立了,当然还要注意的是,外键不一定是指向主表的主键,还可能是unique值,就是外键唯一,当然符合业务逻辑,还有外键值也是可以为空的,至于这要一开始我也是不理解的,既然建立了外键确立了约束条件那为什么还可以为空,但是我又结合实际的业务逻辑想一下,如果一个新员工没有确定部门但需要加入数据库那怎么办,所以外键为空值就符合一般的业务逻辑了。

3:什么情况下使用不为空not null

这个的意思就非常的好理解了,就不多做介绍,但是业务逻辑还是有必要说一下,以前这个约束条件我用的就不是很合理,不管什么我都是不为空,虽然效率高了,但是这是非常的不科学的,比如所一个注册表会有很多信息,什么为空什么不为空都得要根据实际的业务逻辑想一下,需要这么想一下,首先应该要根据业务需求来选择,如用户名,密码,邮箱,年龄,生日,身份证号这几个注册表字段信息,首先用户名,密码,邮箱(一般来说登录或者找回密码用到)是必不可少的,所以是一定不能为空的,而年龄和生日在一般的无特殊需求的情况下是可以不填写的,如果设置了不为空,那么非得强迫用户填写吗,还有就是身份证号码,这个其实不太恰当,身份证号作为用户比较隐私的东西,如果说网站需必须要要身份号这样信息时可以不为空,反之可以为空,默认即可。

4:什么情况下使用unique:

这个约束的意义是唯一但可以为空,为空是和主键唯一的区别,这个约束相对来说还是比较有用的,如部门的名字,当然是唯一的,但是有的新部门没有名字也是可以为空的,但是有的时候肯定会有这样的需求,一个表想要多个主键,这是可以用unique结合not null代替一下,毕竟unique可以用多个的,然而如果你还想为唯一性指明条件的话也是可以的,这也是允许的。

综上总结:所有的约束条件的建立都应该根据业务实际需求而建立

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-11-18 06:49:42

数据库面对不同业务逻辑约束条件的选择的相关文章

业务逻辑实现方式选择

当业务逻辑相对复杂的时候,我的大脑中总会浮现出这样或者那样的解决方案,这些解决方案中有曾经使用过的和未使用过的.当面对这样的选择的时候,我的大脑是比较混乱的,总是想要去在开始还没有去做就抽象出一层,或者通通的放到一条sql中来完成,总感觉这样的方式是快捷的. 而实际中,我们在做这个页面的时候,前面已经有类似的页面,这个要做的页面也只是在上一个页面的基础上进行了些许的改动,那我为什么不把已经做好的页面直接拿过来,改动一些需要变化的部分,而不是自己去创造一套新的解决方案,或者实现方案,这样的每一步都

面对数据丢失、数据错误、业务逻辑发生变化时,可以这么解决。

根据福克斯新闻在20日的报道,美国田纳西州一名14岁男孩Jackson成功在家中打造出核融合实验的小型聚变反应器,成功结合2个氘原子.释出一颗中子. 关键是,Jackson所需的零件是从网上购买,或自己改装的.而且仅用一年时间就打造出了反应器.美媒称,他可能打破了全球最年轻核科学家Taylor Wilson的纪录,是年纪最小的完成制作了核聚变反应器的"科学家". 嗯,还是别人家的孩子,惹不起惹不起!然而没有对比就没有伤害,说出来不怕你们笑话我(们): 面对数据丢失的我 我在公司负责统计

DRF项目之通过业务逻辑选择数据集和序列化器

在REST后台开发中,我们需要通过业务逻辑来选择数据集或者序列化器. 选择数据集: # 重写get_queryset实现通过业务逻辑选择指定数据集 def get_queryset(self): ''' 通过前段传递过来的keyword选择指定数据集 :return: ''' # 获取keyword keyword = self.request.query_params.get('keyword') # 通过前段传递过来的keyword选择指定数据集 if keyword: users = Us

减少存储过程封装业务逻辑-web开发与传统软件开发的思维模式不同

本篇文章讨论并不是:不要使用存储过程,因为有些事情还是要存储过程来完成,不可能不用.而是关于:"业务逻辑是不是要封装在存储过程中实现,这样子php.java等就是调用存储过程". 业务逻辑,通俗说就是:比如要取数据的操作,取出会员编号为x的数据,原来我们一般是封装成函数,或者直接编写sql语句查询.现在是交给数据库的存储过程去完成. +------------------------------------------------------------ 写这篇文章的缘由 +-----

微软-创建业务逻辑层

https://msdn.microsoft.com/zh-cn/dd255899 简介 在教程一中创建的数据访问层 (DAL) 将数据访问逻辑与表示逻辑清晰地分离开来.然而,尽管 DAL 从表示层中清晰地分离出数据访问层细节,它却并没有实施任何可能采用的业务规则.例如,我们想让我们的应用程序在 Discontinued 字段设为 1 时禁止对 Products 表的 CategoryID 或 SupplierID 字段的修改,还有,我们可能想实施一些资历规则以便禁止发生这样的情况:雇员被其后入

MVC5 网站开发之四 业务逻辑层的架构和基本功能

一.业务逻辑层的架构 Ninesky.Core包含两个命名空间Ninesky.Core和 Ninesky.Core.Types. Ninesky.Core包含模型和功能实现,Ninesky.Core.Types是项目用到的一些类型的定义. 1.Ninesky.Core命名空间的结构   NineskyContext-数据上下文 ContextFactory- 获取数据上下文的工厂类  BaseManager-基础类,实现了一些常用数据访问方法,提供其他管理类继承. Category-栏目模型.

在 ASP.NET 中创建数据访问和业务逻辑层(转)

.NET Framework 4 当在 ASP.NET 中处理数据时,可从使用通用软件模式中受益.其中一种模式是将数据访问代码与控制数据访问或提供其他业务规则的业务逻辑代码分开.在此模式中,这两个层均与表示层分离.表示层由网站用户有权查看或更改数据的页面组成. ASP.NET 可通过多种方式提供数据访问.业务逻辑和表示形式之间的分离.例如,数据源模型(包括 LinqDataSource 和 ObjectDataSource 等服务器控件)可将表示层与数据访问代码和业务逻辑分离. 另一种模式是将数

系统架构师-基础到企业应用架构-业务逻辑层

一.上章回顾 上章我们主要讲述了系统设计规范与原则中的具体原则与规范及如何实现满足规范的设计,我们也讲述了通过分离功能点的方式来实现,而在软件开发过程中的具 体实现方式简单的分为面向过程与面向对象的开发方式,而目前更多的是面向对象的开发设计方式.并且我们也讲述了该如何通过设计手段去分析功能点及设计分离 点,应该如何在设计的过程中分析的角度及如何去满足设计规范与原则.首先我们通过下图来回顾下上章要点: 二.摘要 本文将已架构的方式去分析分层结构中的业务层的设计,如何写出来内聚度,高耦合的业务逻辑层

翻译:使用 ASP.NET MVC 4, EF, Knockoutjs and Bootstrap 设计和开发站点 - 6 - 业务逻辑

Part 3: 设计逻辑层:核心开发 如前所述,我们的解决方案如下所示: 下面我们讨论整个应用的结构,根据应用中不同组件的逻辑相关性,分离到不同的层中,层与层之间的通讯通过或者不通过限制.分层属于架构风格,在应用的长时间生命周期中,解决维护和扩展问题.所以,让我们在解决方案中添加一个类库项目,命名为 Application.Common. Application.Common : 这是一个类库项目, 提供公共功能,可以被不同的业务逻辑层使用.例如:安全,日志,跟踪,验证等等. 定义在这个层中的组