数据库设计

版权声明：欢迎转载 https://blog.csdn.net/liaoqianwen123/article/details/25322151 常见问答 1． 试述数据库系统有哪些特点（特别是相对于文件系统）? ①数据共享。特别是实现数据字段的共享。②较高的数据独立性。③面向总体的数据结构话模型。④可控冗余度。 ⑤数据的统一管理和控制。 2． 简述关系的性质? ①随意两个元组不能全同。②元组是非排序的。③属性是非排序的。④属性必须有不同的名称。而不同属性能够来自一个域。 ⑤同一属性名处的诸属性值（同列）是同类型数据。且必须来自同一个域。 3．数据库设计过程包含哪几个主要阶段？哪些阶段独立于数据库管理系统？ 哪些阶段依赖于数据库管理系统。 4个主要阶段：需求分析、概念设计、逻辑设计和物理设计；需求分析和概念设计独立于数据库管理系统，逻辑设计和物理设计依赖于数据库管理系统。 4. 试述数据字典的含义和作用? 数据字典 也常称为 数据文件夹或系统文件夹 ，它是以数据库有关信息为对象建立起来的数据库； 数据字典总是包含着数据库的各级模式所做的定义及各种描写叙述 。起着系统状态的文件夹表的作用，它帮助用户、数据库管理员和数据库系统本身使用和管理数据库的系统。 5．简述你对数据模型的理解。 数据模型 是严格定义的一组概念的集合。这些概念精确地描写叙述了系统的静态特性、动态特性、完整性约束条件。

什么 mybatis MyBatis是一个支持普通SQL查询，存储过程和高级映射的优秀持久层框架; Mybatis消除了几乎所有的JDBC代码和参数的手工设置以及对结果集的检索封装。Mybatis可以使用简单的XML或注解用于配置和原始映射，将接口和Java的POJO（Plain Old Java Objects，普通的Java对象）映射成数据库中的记录 优点 1、简单易学 mybatis本身就很小且简单。没有任何第三方依赖，最简单安装只要两个jar文件+配置几个sql映射文件易于学习，易于使用，通过文档和源代码，可以比较完全的掌握它的设计思路和实现 2、灵活 mybatis不会对应用程序或者数据库的现有设计强加任何影响。 sql写在xml里，便于统一管理和优化。通过sql基本上可以实现我们不使用数据访问框架可以实现的所有功能，或许更多。 3、解除sql与程序代码的耦合 通过提供DAL层，将业务逻辑和数据访问逻辑分离，使系统的设计更清晰，更易维护，更易单元测试。sql和代码的分离，提高了可维护性。 4、提供映射标签，支持对象与数据库的orm字段关系映射 5、提供对象关系映射标签，支持对象关系组建维护 6、提供xml标签，支持编写动态sql。 缺点 1、编写SQL语句时工作量很大，尤其是字段多、关联表多时，更是如此。 2、SQL语句依赖于数据库，导致数据库移植性差，不能更换数据库。

MyBatis：入门及第一个程序 本人使用 环境 ： jdk 1.8 MySql 5.0.8（+Navicat for MySQL） IDEA Maven 3.1.1 一、什么是 Mybatis ？ MyBatis 是一款优秀的 持久层框架 。 MyBatis 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集的过程 MyBatis 可以使用简单的 XML 或注解来配置和映射原生信息，将接口和 Java 的 实体类 【Plain Old Java Objects,普通的 Java对象】映射成数据库中的记录。 MyBatis 本是apache的一个开源项目ibatis, 2010年这个项目由apache 迁移到了google code，并且改名为MyBatis 。 2013年11月迁移到 Github 。 Mybatis官方文档 : http://www.mybatis.org/mybatis-3/zh/index.html GitHub : https://github.com/mybatis/mybatis-3 为什么需要Mybatis Mybatis就是帮助程序猿将数据存入数据库中 , 和从数据库中取数据 . 传统的jdbc操作 , 有很多重复代码块 .比如 : 数据取出时的封装 , 数据库的建立连接等等… , 通过框架可以减少重复代码,提高开发效率 .

目的： 有效的存储，高效的访问。 优良的设计特点 1.减少数据冗余 2.避免数据异常 3.节约存储空间 4.高效的数据访问 数据库设计步骤 1.需求分析 2.逻辑设计ER建模 3.物理设计（Mysql、Oracle、Sql server） 4.维护优化（新需求建表、索引优化、大表拆分） 需求分析 搞清楚实体与实体之间的关系？ 实体包含哪些属性？ 实体的唯一标识是什么？ 对于日志类的实体，可以进行分库分表设计，定期归档。 电商实例， 用户模块、商品模块、订单模块、购物车模块、供应商模块。 用户模块，包含属性：用户名、密码、电话、邮箱、身份证号、地址、姓名、昵称... 可选唯一标识，用户名、身份证、电话、邮箱。 存储特点，随系统上线逐渐增加，需要永久存储。 商品模块，包含属性：商品编码、商品名称、商品描述、商品分类、供应商名称、价格 可选唯一标识（商品编码）、（商品名称、供应商名称） 存储特点：对于下线商品可以归档存储（不要删除）。 订单模块，包括属性：订单号、用户姓名、电话、收货地址、商品编号、商品名称、数量、价格、订单状态、支付状态、订单类型... 可用唯一标识，订单号。 存储特点：永久存储（分库分表） 购物车模块，包括属性：用户名、商品编号、商品名称、商品价格，商品分类，加入时间，商品数量... 可选唯一标识：（用户名、商品编号、加入时间）、（购物车编号） 存储特点：不用永久存储

做完教务系统的需求分析 , 接下来就是对数据库的设计 . 数据库设计是 web 开发中特别重要的一个环节 , 好的数据库设计不仅能让我们实现软件时得心应手 . 对后期的维护 , 升级也是至关重要的 . 记得牛腩在新闻发布系统中这样说过 , 数据库设计完成了 , 那么这个软件也就完成了 70% 的工作 . 可见其重要性 . 对数据库的设计 , 主要是依赖界面设计来做的 . 界面反映了用户的直接需求 . 把这些需求转换成数据库中的表 . 再为这些表添加主键 , 外键等约束 . 以确保数据关系的合理性 . 然后再根据业务的流程去梳理数据库数据的流向是否得当 . 在这里我解释一下自己做数据库设计的一些思路和体会 . 对数据库字段的确定 , 主要是依赖界面中需要添加那些信息 , 需要处理那些信息 , 将对应信息分类到相应的表中 . 这里不说如何确定和提取字段了 , 因为自己感觉也说不清楚 , 当你见得数据库多了 , 你就会自然而然的把他们分出来 . 这里主要说一下对数据库三范式的理解和应用 . 第一范式:数据库表中的字段都是单一属性的，不可再分 对于第一范式 , 还是比较好理解的 , 说白了就是说一个列不能有多个值 , 每一个字段都是不可拆分的 . 比如数据库有这样一个字段 : 父母 . 显然这是不行的 . 因为父母属于两个独立的个体 , 完全可以拆分 . 如果把他们设置为一个字段 .

1. 概述 mybatis的真正强大在于它的映射语句。由于它的异常强大，映射器的XML文件就显得相对简单，如果拿它跟具有相同功能的JDBC代码进行对比，省掉将近95%的代码。mybatis是针对SQL构建的，并且比普通方法做的更好。 SQL映射文件有几个顶级元素（按照它们被定义的顺序）： select：查询 cache-ref：其他命名空间缓存配置的引用 resultMap：是最复杂也是最强大的元素，用来描述如果和数据库结果集中加载对象 parameterMap：已经废弃 sql：可被其他语句引用的可重用语句块 insert：插入 update：更新 delete：删除 cache：给定命名空间的缓存配置 2. select 查询语句是mybatis中最常用的元素之一，多数应用也都是查询比修改要频繁。 <select id="selectPerson" parameterType="int" resultType="hashmap"> SELECT * FROM PERSON WHERE ID = #{id} </select> 这个语句被称作selectPerson，接受一个int类型的参数，并返回一个HashMap类型的对象，其中的key是列名，value是结果行中的对应值。 #{id} 这个高速mybatis创建一个预处理语句参数，通过JDBC，这样一个参数在SQL中会由一个

Hibernate是对JDBC的轻量级封装，因此在很多情况下Hibernate的性能比直接使用JDBC存取数据库要低。然而，通过正确的方法和策略，在使用Hibernate的时候还是可以非常接近直接使用JDBC时的效率的，并且，在有些情况下还有可能高于使用JDBC时的执行效率。 　　在进行Hibernate性能优化时，需要从以下几个方面进行考虑： 　　数据库设计调整。 　　HQL优化。 　　API的正确使用(如根据不同的业务类型选用不同的集合及查询API)。 　　主配置参数(日志、查询缓存、fetch_size、batch_size等)。 　　映射文件优化(ID生成策略、二级缓存、延迟加载、关联优化)。 　　一级缓存的管理。 　　针对二级缓存，还有许多特有的策略。 　　事务控制策略。 　　数据的查询性能往往是影响一个应用系统性能的主要因素。对查询性能的影响会涉及到系统软件开发的各个阶段，例如，良好的设计、正确的查询方法、适当的缓存都有利于系统性能的提升。 　　系统性能的提升设计到系统中的各个方面，是一个相互平衡的过程，需要在应用的各个阶段都要考虑。并且在开发、运行的过程中要不断地调整和优化才能逐步提升系统的性能。 　　 设计阶段的考虑问题 　　一个良好的数据库结构有利于系统性能的提升。这里所说的良好结构的数据库并不单纯是指满足数据库设计范式的数据库结构。这是因为

1、创建数据库 输入数据库名，选择字符集（utf8），选择排序规则（utf8_unicode_ci） 2、创建表 根据业务输入字段名 选择合适的数据类型 根据业务选择字段长度 根据需要选择是否为NULL 选择当前表主键列 输入每个字段的注释，以备后面业务修改或其他人员作参考 输入表注释 表字段范围（主键列【设置自动】+业务字段+基础字段【创建人，创建时间，最后修改人，最后修改时间，删除状态，扩展字段】） 3、创建索引 为表中的字段创建索引，提高检索效率 4、创建外键 为表中的字段关联其他表字段设置外键 来源： 51CTO 作者： 素颜猪 链接： https://blog.51cto.com/suyanzhu/2474424

背景 马上春节了，又到了火车票的销售旺季，一票难求的问题依旧存在吗？ 还记得10年前春节前买火车票得在放票前1天搬个小板凳去排队，对于热门路线，排一个晚上都有可能买不到票。 随着互联网的发展，几年前建设了12306网上购票系统，可以从电脑上买票，但是不要以为在电脑上就能买到票。 我记得12306刚推出时，经常发生12306网站打不开，无法付款的问题。 为什么呢？ 原因很简单，春节期间网上购票的人可能达到几亿的级别，而且放票日期是同一天同一个时间点，也就是说同一时刻12306要接受几亿用户的访问。 处理能力和实际的访问需求更不上，带来的结果就是网站打不开，系统不稳定的现象。 后来12306想了分线路分时段开启的办法，想办法把不同线路的用户错开时间来访问12306的网站，但是这个方法起初的效果不明显，并不是所有用户都知道的（就好像你临时通知今天不上班，但还是有用户会来单位的），所以大多数用户还是集中在一个点去访问12306的网站。 随着硬件的发展，技术的演进，12306的系统越来越趋于成熟，稳定性和响应速度也越来越好。 据说现在很多商家还开通了云抢票业务，本质上是让你不要冲击12306系统了，把需求提前收集，在放票时，这些系统会进行排队与合并购买，这种手段可以减少12306的访问并发。 抢火车票是很有意思的一个课题，对IT人的智商以及IT系统的健壮性

数据库设计范式是一个很重要的概念，但是这个重要程度只是适合于参考。使用数据库设计范式，可以让数据表更好的进行数据的保存，因为在合理的设计，如果数据量一大也肯定会存在性能上的问题，所以在开发中，唯一可以称为设计的宝典——设计的时候尽量避免日后的程序出现多表关联查询。 第一范式 所谓的第一范式指的是数据表中的数据列不可再分。例如，现有如下一张表： CREATE TABLE member( mid NUMBER PRIMARY KEY, name VARCHAR2(200) NOT NULL, contact VARCHAR2(200) ) 这个时候设计的就不合理，因为联系方式由多种数据所组成（电话、地址、email、手机、邮政编码等），所以这种设计是不符合第一范式的，现在可以修改设计如下： CREATE TABLE member( mid NUMBER PRIMARY KEY, name VARCHAR2(200) NOT NULL, address VARCHAR2(200), zipcode VARCHAR2(6), mobile VARCHAR2(20), tel VARCHAR2(20) ) 但是在这里有两点需要说明。 1、关于姓名，在国外的表设计姓名也分为姓和名两类，但是在中国就是姓名保存。 2、关于生日，生日有专门的数据类型（DATE），所以不能将其设置为生日年、生日月