数据库设计

https://www.cnblogs.com/qcloud1001/p/10509688.html 来源： https://www.cnblogs.com/yaohuimo/p/12306046.html

1. Alpha 冲刺第二天 成员 任务分工 田先强 进行部分后端编程，整理编程思路 王建木 进行部分后端编程 王鑫 撰写博客，完成部分数据库设计 翟堂贵 界面设计 吴庭威 完成部分前端设计 李昕洪 完成部分前端设计 辛博 学习SQL数据库使用 2.明日各个成员的任务安排 成员 任务分工 田先强 进行部分后端编程 王建木 攥写博客，进行部分后端编程 王鑫 完成数据库设计 翟堂贵 界面设计 吴庭威 完成部分前端设计 李昕洪 完成部分前端设计 辛博 完成数据库设计 3.整个项目预期的任务量 任务量为25 4.团队成员贡献值的计算规则 贡献值=工作难度✖完成情况 5.当天站立式会议照片 6.Leangoo的看板截图 7.燃尽图 8.项目整体的进展情况 刚刚起步，还有很多东西需要学习 来源： https://www.cnblogs.com/txq1997/p/10085321.html

1.PreparedStatement是预编译的,对于批量处理可以大大提高效率. 也叫JDBC存储过程 2.使用 Statement 对象。在对数据库只执行一次性存取的时侯，用 Statement 对象进行处理。PreparedStatement 对象的开销比Statement大，对于一次性操作并不会带来额外的好处。 3.statement每次执行sql语句，相关数据库都要执行sql语句的编译，preparedstatement是预编译得, preparedstatement支持批处理 4. Code Fragment 1: String updateString = "UPDATE COFFEES SET SALES = 75 " + "WHERE COF_NAME LIKE ′Colombian′"; stmt.executeUpdate(updateString); Code Fragment 2: PreparedStatement updateSales = con.prepareStatement("UPDATE COFFEES SET SALES = ? WHERE COF_NAME LIKE ? "); updateSales.setInt(1, 75); updateSales.setString(2, "Colombian"); updateSales

轉自: http://hi.baidu.com/circledong/blog/item/ec56e1101549cf79cb80c463.html 我们在开发系统的时候，经常会遇到系统需要权限控制，而权限的控制程度不同有不同的设计方案。 1. 基于角色的权限设计 这种方案是最常见也是比较简单的方案，不过通常有这种设计已经够了，所以微软就设计出这种方案的通用做法，这种方案对于每一个操作不做控制，只是在程序中根据角色对是否具有操作的权限进行控制；这里我们就不做详述 2. 基于操作的权限设计 这种模式下每一个操作都在数据库中有记录，用户是否拥有该操作的权限也在数据库中有记录，结构如下： 但是如果直接使用上面的设计，会导致数据库中的UserAction 这张表数据量非常大，所以我们需要进一步设计提高效率，请看方案3 3. 基于角色和操作的权限设计 如上图所示，我们在添加了Role ，和RoleAction 表，这样子就可以减少UserAction 中的记录，并且使设计更灵活一点。 但是这种方案在用户需求的考验之下也可能显得不够灵活够用，例如当用户要求临时给某位普通员工某操作权限时，我们就需要新增加一种新的用户角色，但是这种用户角色是不必要的，因为它只是一种临时的角色，如果添加一种角色还需要在收回此普通员工权限时删除此角色，我们需要设计一种更合适的结构来满足用户对权限设置的要求。 4. 2

第 4 章 O/R Mapping基础 目录 映射声明(Mapping declaration) Schema hibernate-mapping class id 联合ID(composite-id) 识别器（discriminator） 版本（version）(可选) 时间戳（timestamp ）(可选) property 多对一（many-to-one） 一对一(one-to-one) 组件（component） 子类(subclass) 连接的子类（joined-subclass） map, set, list, bag 引用（import） NHibernate的类型 实体（Entities）和值（values） 基本值类型 自定义值类型 映射到"任意"(any)类型 SQL中引号包围的标识符 映射文件的模块化（Modular mapping files） 映射声明(Mapping declaration) 对象和关系数据库之间的映射是用一个XML文档(XML document)来定义的。这个映射文档被设计为易读的，并且可以手工修改。映射语言是以.NET为中心的，意味着映射是按照持久化类的定义来创建的，而非表的定义。 请注意，虽然很多Hibernate用户选择手工定义XML映射文档，也有一些工具来生成映射文档，包括XDoclet,Middlegen和AndroMDA.

系列文章 [Nhibernate]体系结构 [NHibernate]ISessionFactory配置 [NHibernate]持久化类(Persistent Classes) 引言 对象和关系数据库之间的映射是用一个XML文档（XML document）来定义的。这个映射文档被设计为易读的，并且拒绝恶意手工修改。映射语言以.NET为中心的，意味着映射是持久化类的定义来创建的，而非表的定义。 请注意，虽然很多Hibernate用户选择手工定义XML映射文档，也有一些工具来生成映射文档，包括XDoclet，Middlegn和AndroMDA（这里是Nhibernate文档中移除没有从Hibernate文档中转换过来的部分），NHibernate中并没有像XDoclet，Middlegn和AndroMDA这样的工具，在运用中，一般使用代码生成器来生成XML配置文档。 一个映射的例子 1 <?xml version="1.0" ?> 2 <hibernate-mapping xmlns="urn:nhibernate-mapping-2.0" 3 namespace="Eg" assembly="Eg"> 4 <class name="Cat" table="CATS" discriminator-value="C"> 5 <id name="Id" column="uid" type=

数据库设计三范式 来源： https://www.cnblogs.com/ZengBlogs/p/12287193.html

第一章-需求分析 数据库设计的概念 数据库的设计，就是根据业务系统的具体需求，结合我们所选用的DBMS，为这个业务系统构造出最有的数据存储模型。并建立好数据库中的表结构及表与表之间的关联关系的过程。使之能 有效 的对应系统中的数据进行存储，并可以 高效 的对已经存储的数据进行访问。 数据库设计的步骤 需求分析----->逻辑设计----->物理设计----->维护优化 数据库需求分析的作用点： 数据是什么 数据有哪些属性 数据和属性各自的特点有哪些 使用ER图对数据库进行逻辑建模 数据管理系统的选择，根据数据库自身的特点把逻辑设计转换为物理设计 后期维护 新的需求进行建表，建新表之前也要做好前三步，防止后期出现的问题 索引优化 大表拆分 需求分析 为什么要进行需求分析？ 为了设计最优化的数据库，便于后期的扩展和维护，数据越来越多，越来越大会浪费空间，越来越杂乱，是很难处理和维护的 了解系统中索要存储的数据 了解数据的存储特点，比如有的数据有时效性，有的没有，有时效性的可以采取定期清理 了解数据的生命周期， 要搞清楚的一些问题 实体及实体之间的关系（1对1,1对多，多对多） 实体所包含的属性有什么？属性有很多，哪些属性是可以标识出这个实体的 那些属性或属性的组合可以唯一标识一个实体 存储上有什么特性，增长量是什么样？ 实例分析 第二章-逻辑设计 逻辑设计要做什么

数据库设计的三大范式 为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就叫做范式。 范式就是符合某一种设计要求的总结，要想设计一个结构合理的关系型数据库，必须满足一定的范式。 在实际开发中最常见的设计范式有三个： 1、第一范式*（确保每列保持原子性） 第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库满足第一范式。 第一范式的合理遵循需要根据系统给的实际需求来确定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成为一个数据库表的字段就行，但是如果系统经常访问“地址”属性中的“城市”部分，那么一定要把“地址”这个属性重新拆分为省份、城市、详细地址等多个部分来进行存储，这样对地址中某一个部分操作的时候将非常方便，这样设计才算满足数据库的第一范式。如下图。 上图所示的用户信息遵循第一范式的要求，这样对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。 2、第二范式（避免数据的重复，意思就是一张表只描述一件事情,一张表中不能同时出现订单信息与产品信息） 第二范式在第一范式的基础上更进一层，第二范式需要确保数据库表中每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中

明天数据库考试。。。看到了一篇写的极好的关于三大范式理解的文章，现收藏于下 为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。 在实际开发中最为常见的设计范式有三个： 1 ．第一范式(确保每列保持原子性) 第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。 第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。 上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。 2 ．第二范式(确保表中的每列都和主键相关) 第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据