㈠ 数据库设计
说起数据库设计，相信大家都明白怎么回事，但说起数据库设计的重要性，我想大家也只是停留在概念上而已，到底如何重要？怎么重要呢？今天就将我至今为止的理解向大家阐述下。
一个不良的数据库设计，必然会造成很多问题，轻则增减字段，重则系统无法运行。我先来说说数据库设计不合理的表现吧：
1. 与需求不符
因为这个原因造成的改动量往往是最大。如果进入编码阶段的话，很可能会直接让你崩溃掉。
2. 性能低下
含有大数据量的表之间的关联过多；没有合理的字段设计来用于查询而造成的SQL查询语句很复杂；对于大数据量的表没有采用有效的手段去处理；滥用视图等。
3. 数据完整性丧失
含有主外键关系的表之间关联字段的设计方式不合理，造成更新与删除操作后程序容易出错或不完善；使用了已经删除或丢失掉的数据。
4. 可扩展性性太差
表设计的与业务绑定的太紧密、单一，造成表的可拓展性、可修改性太差，无法新需求的要求。
5. 非必要数据冗余量太大
没用的垃圾数据存储过多，不仅占用资源，还影响查询效率。
6. 不利于计算或统计
缺少必要的联系性或统计性字段或用于计算统计的字段分散于多个表中，造成计算统计的步骤繁琐，甚至无法计算统计。
7. 没有详尽的数据记录信息
缺少必要的字段，造成无法跟踪数据变化、用户操作，也无法进行数据分析。
8. 表之间的耦合性太大
多张表之间关联的过于紧密，造成一张表发生变化而影响到其他表。
9. 字段设计考虑不周
字段长度过短或字段类型过于明确，造成可发挥、可拓展的空间太小。
大多数的程序员对于软件开发的出发点认识不是很明确，总是认为实现功能才是重要的，在简单了解完基本需求后就急忙进入编码阶段，对于数据库设计思考的比较少、比较简单，大多设计都只停留在表面上，这往往是要命的，会为系统留下很多隐患。要么是写代码开发过程中才发现问题，要么就是系统上线运转后没多久就出现问题，还有可能给后期维护增加了很多工作量。如果到了那个时候再想修改数据库设计或进行优化等同于推翻重来。
数据库是整个软件应用的根基，是软件设计的起点，它起着决定性的质变作用，因此我们必须对数据库设计高度重视起来，培养设计良好数据库的习惯，是一个优秀的软件设计师所必须具备的基本素质条件！
那么我们要做到什么程度才是对的呢？下面就说说数据库设计的原则
1. 数据库设计最起码要占用整个项目开发的40%以上的时间
数据库是需求的直观反应和表现，因此设计时必须要切实符合用户的需求，要多次与用户沟通交流来细化需求，将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确，就要分析不确定的因素，设计表时就要事先预留出可变通的字段，正所谓“有备无患”。
2. 数据库设计不仅仅停留于页面demo的表面
页面内容所需要的字段，在数据库设计中只是一部分，还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段，因此数据库设计绝对不是简单的基本数据存储，还有逻辑数据存储。
3. 数据库设计完成后，项目80%的设计开发在你脑海中就已经完成了
每个字段的设计都是有他必要的意义的，你在设计每一个字段的同时，就应该已经想清楚程序中如何去运用这些字段，多张表的联系在程序中是如何体现的。换句话说，你完成数据库设计后，程序中所有的实现思路和实现方式在你的脑海中就已经考虑过了。如果达不到这种程度，那当进入编码阶段后，才发现要运用的技术或实现的方式数据库无法支持，这时再改动数据库就会很麻烦，会造成一系列不可预测的问题。
4. 数据库设计时就要考虑到效率和优化问题
一开始就要分析哪些表会存储较多的数据量，对于数据量较大的表的设计往往是粗粒度的，也会冗余一些必要的字段，已达到尽量用最少的表、最弱的表关系去存储海量的数据。并且在设计表时，一般都会对主键建立聚集索引，含有大数据量的表更是要建立索引以提供查询性能。对于含有计算、数据交互、统计这类需求时，还要考虑是否有必要采用存储过程。
5. 添加必要的（冗余）字段
像“创建时间”、“修改时间”、“备注”、“操作用户IP”和一些用于其他需求（如统计）的字段等，在每张表中必须都要有，不是说只有系统中用到的数据才会存到数据库中，一些冗余字段是为了便于日后维护、分析、拓展而添加的，这点是非常重要的，比如黑客攻击，篡改了数据，我们便就可以根据修改时间和操作用户IP来查找定位。
6. 设计合理的表关联
若多张表之间的关系复杂，建议采用第三张映射表来关联维护两张表之间的关系，以降低表之间的直接耦合度。若多张表涉及到大数据量的问题，表结构尽量简单，关联也要尽可能避免。
7. 设计表时不加主外键等约束性关联，系统编码阶段完成后再添加约束性关联
这样做的目的是有利于团队并行开发，减少编码时所遇到的问题，表之间的关系靠程序来控制。编码完成后再加关联并进行测试。不过也有一些公司的做法是干脆就不加表关联。
8. 选择合适的主键生成策略
主键生成策略大致可分：int自增长类型（identity、sequence）、手动增长类型（建立单独一张表来维护）、手动维护类型（如userId）、字符串类型（uuid、guid）。int型的优点是使用简单、效率高，但多表之间数据合并时就很容易出现问题，手动增长类型和字符串类型能很好解决多表数据合并的问题，但同样也都有缺点：前者的缺点是增加了一次数据库访问来获取主键，并且又多维护一张主键表，增加了复杂度；而后者是非常占用存储空间，且表关联查询的效率低下，索引的效率也不高，跟int类型正好相反。
终上所述，我们可见数据库设计在整个软件开发的起到的举足轻重的作用，尤其是我说的设计原则的第一点，数据库与需求是相辅相成的，我经常把软件开发比作汽车制造。汽车制造会经过图纸设计，模型制作，样车制造，小批量试生产，最后是批量生产等步骤。整个过程环环相扣，后一过程是建立在前一过程正确的前提基础之上的。如果在图纸设计阶段发现了一个纰漏，我们可以重新进行图纸设计，如果到了样车制造阶段发现这个错误，那么我们就要把从图纸设计到样车制造的阶段重来，越到后面发现设计上的问题，所付出的代价越大，修改的难度也越大。
数据库设计难度其实要比单纯的技术实现的难很多，他充分体现了一个人的全局设计能力和掌控能力，所以在今后的项目中大家一定要着重培养这方面的能力，这里我将我的经验分享给了大家，希望能对大家有所帮助。
㈡ 试述数据库设计的基本步骤.
答：（1）需求分析阶段：需求收集和分析,得到数据字典和数据流图.（2）概念结构设计阶段：对用户需求综合、归纳与抽象,形成概念模型,用E-R图表示.（3）逻辑结构设计阶段：将概念结构转换为某个DBMS所支持的数据模型.（4）数据库物理设计阶段：为逻辑数据模型选取一个最适合应用环境的物理结构.（5）数据库实施阶段：建立数据库,编制与调试应用程序,组织数据入库,程序试运行.（6）数据库运行和维护阶段：对数据库系统进行评价、调整与修改.
㈢ 数据库软件架构设计的要点
数据库软件架构设计，要关注哪些要点？
方法/步骤
在IT系统架构设计中，数据库的设计，占据着很重要的地位。那么主要面临哪些问题，需要考虑哪些因素呢？
面对数据量过大的问题，通常需要通过分片技术来解决，目前应用较多的是哈希分片。
因为通过范围简单分片，可能造成各库的压力不均；而统一路由，会增加访问前查询的压力。
通过主从复制的分组，既可以解决可用性的问题，还可以实现一定的性能提升。
数据库的软件架构设计，要关注可用性、性能、一致性和扩展性四个方面。
解决可用性的主要思路就是冗余——站点冗余、服务冗余、数据冗余……
冗余带来的可用性问题，就是数据一致性的问题，要保证数据一致性，可以考虑双写同步。
扩展性能一般有三种方式——增加索引、增加从库和增加缓存，要结合实际情况分析应用。
架构的设计是一个动态优化的过程，要综合考虑几个方面的因素，寻找合适的平衡点。
㈣ 数据库设计
根据以上数据内容分析，当前遥感综合调查基础数据库主要由各个专题数据库（以矢量数据为主）、公共数据库（既有矢量数据又有栅格数据，前者如1∶25万基础地理数据，后者如1∶25万DEM数据库和1∶25万ETM＋遥感影像）等构成，同时整个系统还必须具备自身的扩展机制，随着用户和应用的不断变化，数据库的内容也必将随之变化。因此，遥感综合调查基础数据库设计的主导思想是，利用ArcSDE技术提供的Multiuser Geodatabase模型组织复杂的空间数据，建立一个开放的、灵活的空间数据库。
Geodatabase由矢量要素数据集、栅格数据集、TIN数据集、空间域、规则等部件构成。它对通常所要处理和表达的地理空间要素，如矢量、栅格、三维表面、网络、地址等进行了统一的描述，并引入了这些地理空间要素的行为、规则和关系（ESRI,2001）。而遥感综合调查基础数据库只存储其中的矢量要素数据集、栅格数据集等几种类型。基于Geodatabase的遥感综合调查数据模型如图11.4所示。
设计Geodatabase与设计普通的数据库是相同的，也分成两个基本步骤——逻辑数据模型的表达和数据库模型的物理实施，即逻辑设计和物理设计。逻辑设计是空间数据在用户或应用中的表现形式，物理设计主要是空间数据在存储介质里的具体储存方式。逻辑数据模型是对所要研究的现实世界的有关数据而建立的一个抽象的关联结构，以描述这些数据之间的逻辑关系。它完全独立于具体系统实现和处理过程，区别于物理数据模型，即它不是一个在数据库管理系统中的表结构，不化解或消除实体间的多对多关系，更接近于现实世界，是一个访问数据的基本视图。可以说逻辑层是物理层的表现，而物理层是逻辑层的基础。
图11.4基于GeoDatabase的遥感综合调查数据模型
图11.5逻辑层与物理层的联系
从逻辑设计的角度来看，本系统基础数据库的设计思路是：数据库→子库→图层→空间实体，库可以包含多个子库，子库用来存放不同比例尺或不同用途的空间数据，再根据项目设计书的要求对每一个子库做大类和图层的划分。从物理设计的角度来看，最终反映在ArcSDE的物理数据库模型则是GEODATABASE→FEATUREDATASET→FEATURECLASS→FEATURE（如图11.5）所示。
㈤ SQL数据库设计
帐号 int(4) 主键
社区昵称 varchar(20) 大小可变把20该成你规定的社区昵称大小
密码 varchar(20) 大小可变把20该成你规定的密码长度
电子邮箱 varchar(50)
性别 bit(1) 0代表女1代表男或者反之
所属学院 int(4) 字典表里所属学院的ID
真实姓名 varchar(20)
出生日期 varchar(10) 用“-”把用户选择的“年-月-日”这样组合起来
籍贯 int(4) 字典表里籍贯的ID
提示问题 int(4) 字典表里提示问题的ID
问题答案 varchar(20) 大小可变把20该成你规定的问题答案大小
证件类型 int(4) 字典表里证件类型的ID
证件号码 varchar(20)
几个复选框(干嘛用的)
字段名称你就自己取吧。
再建一个字典表
id int(4) 主键
名称 varchar(20) 放籍贯，学院，证件类型，提示问题的名称等
类型 int(4) 是个标记，说明这个名称是那类（1是籍贯，2是学院，3是证件类型，4是提示问题等）