数据库设计

Mybatis 一. 入门 1. JDBC 回顾 (1). 准备数据库 新建 mybatis_learn 数据库 执行 sql 脚本 1 -- ---------------------------- 2 -- Table structure for `Blog` 3 -- ---------------------------- 4 DROP TABLE IF EXISTS `Blog`; 5 CREATE TABLE `Blog` ( 6 `id` int(11) NOT NULL AUTO_INCREMENT, 7 `author` varchar(128) NOT NULL COMMENT '作者', 8 `title` varchar(128) NOT NULL COMMENT '博客标题', 9 PRIMARY KEY (`id`) 10 ) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8; 11 ​ 12 -- ---------------------------- 13 -- Records of Blog 14 -- ---------------------------- 15 INSERT INTO `Blog` VALUES ('1', '张三', 'Java基础概述'); 16 INSERT

本文链接： http://www.openphp.cn/index.php/art.../100/index.html 一、数据库设计过程 　　数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 　　数据库设计中需求分析阶段综合各个用户的应用需求（现实世界的需求），在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式（信息世界模型），用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图（VIEW）形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 　　1. 需求分析阶段 　　需求收集和分析，结果得到数据字典描述的数据需求（和数据流图描述的处理需求）。 　　需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 　　需求分析的方法：调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 　　常用的调查方法有： 跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 　

目的：设计一个车票的数据库，完成一些基本的查询、增删功能。 数据表结构分析； 各个字段分析； 基本数据库、表的建立，数据录入； 复杂查询的实现简要分析。 1 数据库结构分析； 1.1 客户表 目的：查询客户的所有信息。 输出字段：身份证号（主键）、姓名、用户名、联系电话、籍贯、类型（学生还是普通） 1.2 订票单表 目的：查询某一客户订单票的信息 输入in：姓名 输出：订单编号，订票时间，乘车日期，订票数量 1.3车票表 输出：车次，出发站，目的站，座位类型，座位号，车票价格，发车时间，到站时间 二、表设计 create database ticketSystem; use ticketSystem; 表1 客户表结构 create table users( id_number varchar(18) primary key, name varchar(10) not null, tel char(11), username varchar(16) not null, hometown varchar(18), type varchar(18) ); insert into users values('522131199901016666','张三','13899998888','zhangsan666','贵州','学生票'); insert into users values(

1.hibernate的常用接口 （1） Configucation:负责加载Hibernate的配置及映射信息，启动Hibernate,根据连接到数据库的信息来创建 SessionFactory对象。 （2） SessionFactory: 初始化Hibernate，创建Session对象。他是线程安全的，通常采用单子模式创建此对象。 （3）Session :负责保存·修改·删除·查询·加载对象，这个session不是线程安全的，使用Threadlocal来得到session （相当于创建了一个副本）。 （4）Transaction: 事务处理 开启事务的方法 Transaction tx= session.beginTransaction(); 提交事务 tx.commit(); (5) Query和Criteria：Query是执行数据库查询，Query接口包装了一个HQL语句，HQL语句是面向对象的，它引用类名 和属性名， 而不是表名和字段名。Criteria完全封装了基于字符串形式的查询语句，比Query接口更加面向对象，擅长 动态查询。 2.hibernate体系结构 3.hibernate的工作原理 (1)hibernate如何连接数据库？ 配置文件Hibernate.cfg.xml文件中定义了和数据库进行连接的信息，包括数据库方言.jdbc驱动.用户名

1. 数据库设计范式概述 　　在设计数据库时，要遵循的规范就是设计范式。 　　设计关系型数据库时，要遵循不同的规范，设计出合理的数据库。 　　目前设计范式有第一范式(1NF)到第六范式(6NF)六个等级的范式，每个范式都是呈递次规范，要做到下一范式需要先实现上一级范式(就像俄罗斯套娃似的，虽然这么比喻不是很恰当)。 　　主流的是第一范式、第二范式、第三范式，只要实现了前三个范式，基本上可以称得上是一个合理、高效且安全的数据库。因为后三种范式较为严苛，故暂不讨论。 2. 第一范式 　　(1) 要求 　　1) 第一范式是关系型数据库的基础，只要是不符合第一范式，就称不上关系型数据库。 　　2) 第一范式的要求是，每一列的属性都是不可分割的基本数据项， 表中的属性不能有可以拆分的属性 。如果出现重复的属性，就需要重新定义一个新的实体，新的实体由重复的属性构成。 　　3) 总而言之，第一范式就是禁止重复的列存在，一个实体的数据在表中只能出现一次。 　　(2) 缺陷 　　1) 存在严重的数据冗余(复用性低，不知道比喻的合不合适)。 　　2) 部分属性要加入新的数据，但又无法构成一个实体时无法增加。 　　3) 删除一个实体可能导致其他属性的丢失。 3. 第二范式 　　(1) 要求 　　1) 第二范式是基于第一范式的规范。 　　2) 要求数据库表中的每个实例或行必须可以被唯一地区分。要

1、概述 评论功能已经成为APP和网站开发中的必备功能。本文主要介绍评论功能的数据库设计。 评论功能最主要的是发表评论和回复评论（删除功能在后台）。评论功能的拓展功能体现有以下几方面： （1）单篇文章的评论数量和信息展示； （2）从时间维度，按照时间倒叙的方式展示动态的用户评论信息； （3）不同栏目，不同模块，不同时间维度的评论排行展示； （4）精华评论的单独推荐和聚合展示； （5）评论后直接分享到绑定的第三方平台； （6）点赞数、回复数等维度的排行等。 评论的后台管理： （1）删除； （2）推荐； （3）精华； （4）屏蔽，敏感关键字的库的完善、自动屏蔽或者替换功能。 本篇文章主要分析几种客户端评论数据表的设计。 2、数据表设计 2.1 一问一答模式 (1)需求分析 大部分APP采用简单的评论设计即可，即是一问一答模式，比如微信朋友圈的评论功能的设计。如： A：今天天气真好！ B @ A :今天天气确实不错！ 1 2 这种设计简单、直接，也满足了用户评论、回复的基本要求，对于没有大量用户评论的APP需求足够。 （2）数据库设计 这种场景下一般评论较少，评论不活跃，可以不区分评论和回复，统一看成评论。区别是，有些评论是直接评论主题，而有些是@其他用户，使用一张表就可以达到效果，评论表设计如下： 表字段 字段说明 id 主键 topic_id 主题id topic_type 主题类型

原文链接: 　　 http://blog.csdn.net/ztchun/article/details/71106117 　　 1、概述 评论功能已经成为APP和网站开发中的必备功能。本文主要介绍评论功能的数据库设计。 评论功能最主要的是发表评论和回复评论（删除功能在后台）。评论功能的拓展功能体现有以下几方面： （1）单篇文章的评论数量和信息展示； （2）从时间维度，按照时间倒叙的方式展示动态的用户评论信息； （3）不同栏目，不同模块，不同时间维度的评论排行展示； （4）精华评论的单独推荐和聚合展示； （5）评论后直接分享到绑定的第三方平台； （6）点赞数、回复数等维度的排行等。 评论的后台管理： （1）删除； （2）推荐； （3）精华； （4）屏蔽，敏感关键字的库的完善、自动屏蔽或者替换功能。 本篇文章主要分析几种客户端评论数据表的设计。 2、数据表设计 2.1 一问一答模式 (1)需求分析 大部分APP采用简单的评论设计即可，即是一问一答模式，比如微信朋友圈的评论功能的设计。如： A：今天天气真好！ B @ A :今天天气确实不错！ 这种设计简单、直接，也满足了用户评论、回复的基本要求，对于没有大量用户评论的APP需求足够。 （2）数据库设计 这种场景下一般评论较少，评论不活跃，可以不区分评论和回复，统一看成评论。区别是，有些评论是直接评论主题，而有些是@其他用户

在目前的企业信息系统中，数据库还是最佳的数据存储方式，虽然已经有很多的书籍在指导我们进行数据库设计，但应该那种方式是设计数据库的表结构的最好方法、设计时应遵从什么样的原则、四个范式如何能够用一种方式达到顺畅的应用等是我一直在思考和总结的问题，下文是我针对这几个问题根据自己的设计经历准备总结的一篇文章的提纲，欢迎大家一块进行探讨，集思广益。其中提到了领域建模的概念，但未作详细解释，希望以后能够有时间我们针对这个命题进行深入探讨。 1)不应该针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。 2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。对象要符合封装的特性，确保与职责相关的数据项被定义在一个对象之内，这些数据项能够完整描述该职责，不会出现职责描述缺失。并且一个对象有且只有一项职责，如果一个对象要负责两个或两个以上的职责，应进行分拆。 3)根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属性

第一方面：开发速度的对比 就开发速度而言，Hibernate的真正掌握要比Mybatis来得难些。Mybatis框架相对简单很容易上手，但也相对简陋些。个人觉得要用好Mybatis还是首先要先理解好Hibernate。 比起两者的开发速度，不仅仅要考虑到两者的特性及性能，更要根据项目需求去考虑究竟哪一个更适合项目开发，比如：一个项目中用到的复杂查询基本没有，就是简单的增删改查，这样选择hibernate效率就很快了，因为基本的sql语句已经被封装好了，根本不需要你去写sql语句，这就节省了大量的时间，但是对于一个大型项目，复杂语句较多，这样再去选择hibernate就不是一个太好的选择，选择 mybatis 就会加快许多，而且语句的管理也比较方便。 第二方面：开发工作量的对比 Hibernate和MyBatis都有相应的代码生成工具。可以生成简单基本的DAO层方法。针对高级查询，Mybatis需要手动编写SQL语句，以及ResultMap。而Hibernate有良好的映射机制，开发者无需关心SQL的生成与结果映射，可以更专注于业务流程。 第三方面：sql优化方面 Hibernate的查询会将表中的所有字段查询出来，这一点会有性能消耗。Hibernate也可以自己写SQL来指定需要查询的字段，但这样就破坏了Hibernate开发的简洁性。而Mybatis的SQL是手动编写的

最近做了一个小项目完整的数据库设计,想总结一些设计上的所得,希望大家多多指教。 有时一个项目，普通程序员一般不会去接触数据库设计，一般都有专业的DBA或是老程序员去设计，下面是我推测的几点可能原因： 1：新手对项目了解不深，正好这是老鸟的长处。 2：新手对局部的关注往往大于整体，很难考虑的特别周全。 3：数据库设计的好坏在某种程度上直接影响项目的复杂度以及性能。 第一：我们要知道什么是范式 ，为什么说到数据库设计总要提到一个名词：范式。范式：符合某一种级别的关系模式的集合。设计数据库必须遵循一定的规则,在关系数据库中，这种规则就是范式。 第二：范式的分类。 关系数据库中的关系必须满足一定的要求，目前关系数据库有六种范式：第一范式、第二范式、第三范式、第四范式、第五范式和第六范式。满足最低要求的是第一范式，其余范式以次类推。这么多的分类并不一定要求全部满足，平时我们通常是达到第三范式就行。 第三：范式的作用？ 1:优点：是将其转化为一些表的过程，这种方法可以使从数据库得到的结果更加明确。 2:缺点：可能使数据库产生重复数据，从而导致创建多余的表。 3:是在识别数据库中的数据元素、关系，以及定义所需的表和各表中的项目这些初始工作之后的一个细化的过程。 4:设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，也不会发生插入、删除和更新操作异常