数据库设计经验谈

数据库设计

数据库设计 1

第 1 部分 - 设计数据库之前 3

第 2 部分 - 设计数据库表 3

第 3 部分 - 选择键 3

第 4 部分 - 保证数据完整性 3

第 5 部分 - 各种小技巧 3

第 1 部分 - 设计数据库之前 3

考察现有环境 3

定义标准的对象命名规范 3

工欲善其事, 必先利其器 4

获取数据模式资源手册 4

畅想未来，但不可忘了过去的教训 4

在物理实践之前进行逻辑设计 5

了解你的业务 5

创建数据字典和 ER 图表 5

创建模式 5

从输入输出下手 5

报表技巧 5

理解客户需求 6

第 2 部分 - 设计表和字段 6

检查各种变化 6

采用有意义的字段名 6

采用前缀命名 6

标准化和数据驱动 6

标准化不能过头 7

Microsoft Visual FoxPro 报表技巧 7

不活跃或者不采用的指示符 7

使用角色实体定义属于某类别的列[字段] 7

采用常用实体命名机构数据 8

用户来自世界各地 8

数据重复需要采用分立的数据表 8

每个表中都应该添加的 3 个有用的字段 8

对地址和电话采用多个字段 8

使用多个名称字段 9

提防大小写混用的对象名和特殊字符 9

小心保留词 9

保持字段名和类型的一致性 9

仔细选择数字类型 9

删除标记 10

避免使用触发器 10

包含版本机制 10

给文本字段留足余量 10

列[字段]命名技巧 10

第 3 部分 - 选择键和索引 11

数据采掘要预先计划 11

使用系统生成的主键 11

分解字段用于索引 11

键设计 4 原则 11

别忘了索引 11

不要索引常用的小型表 12

不要把社会保障号码（SSN）或身份证号码（ID）选作键 12不要用用户的键 12

可选键(候选键)有时可做主键 13

别忘了外键 13

第 4 部分 - 保证数据的完整性 13

用约束而非商务规则强制数据完整性 13

分布式数据系统 13

强制指示完整性(参照完整性?) 13

关系 14

采用视图 14

给数据保有和恢复制定计划 14

用存储过程让系统做重活 14

使用查找 14

第 5 部分 - 各种小技巧 14

文档、文档、文档 14

使用常用英语（或者其他任何语言）而不要使用编码 15

保存常用信息 15

测试、测试、反复测试 15

检查设计 15

Microsoft Visual FoxPro 设计技巧 15

一个成功的管理系统，是由：[50% 的业务 + 50% 的软件] 所组成，而 50% 的成功软件又有 [25% 的数据库 + 25% 的程序] 所组成，数据库设计的好坏是一个关键。如果把企业的数据比做生命所必需的血液，那么数据库的设计就是应用中最重要的一部分。有关数据库设计的材料汗牛充栋，大学学位课程里也有专门的讲述。不过，就如我们反复强调的那样，再好的老师也比不过经验的教诲。所以我归纳历年来所走的弯路及体会，并在网上找了些对数据库设计颇有造诣的专业人士给大家传授一些设计数据库的技巧和经验。精选了其中的 60 个最佳技巧，并把这些技巧编写成了本文，为了方便索引其内容划分为 5 个部分：第 1 部分 - 设计数据库之前

这一部分罗列了 12 个基本技巧，包括命名规范和明确业务需求等。

第 2 部分 - 设计数据库表

总共 24 个指南性技巧，涵盖表内字段设计以及应该避免的常见问题等。

第 3 部分 - 选择键

怎么选择键呢？这里有 10 个技巧专门涉及系统生成的主键的正确用法，还有何 时以及如何索引字段以获得最佳性能等。

第 4 部分 - 保证数据完整性

讨论如何保持数据库的清晰和健壮，如何把有害数据降低到最小程度。

第 5 部分 - 各种小技巧

不包括在以上 4 个部分中的其他技巧，五花八门，有了它们希望你的数据库开发工作会更轻松一些。

第 1 部分 - 设计数据库之前

考察现有环境

在设计一个新数据库时，你不但应该仔细研究业务需求而且还要考

察现有的系统。大多数数据库项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求的现有系统（可能没有实现自动计算）。显然，现有系统并不完美，否则你就不必再建立新系统了。但是对旧系统的研究可以让你发现一些可能会忽略的细微问题。一般来说，考察现有系统对你绝对有好处。

定义标准的对象命名规范

一定要定义数据库对象的命名规范。对数据库表来说，从项目一开始就要确定表名是采用复数还是单数形式。此外还要给表的别名定义简单规则（比方说，如果表名是一个单词，别名就取单词的前 4 个字母；如果表名是两个单词，就各取两个单词的前两个字母组成 4 个字母长的别名；如果表的名字由 3 个单词组成，你不妨从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成 4 字母长的别名，其余依次类推）对工作用表来说，表名可以加上前缀WORK_ 后面附上采用该表的应用程序的名字。表内的列[字段]要针对键采用一整套设计规则。比如，如果键是数字类型，你可以用 _N 作为后缀；如果是字符类型则可以采用 _C 后缀。对列[字段]名应该采用标准的前缀和后缀。再如，假如你的表里有好多“money”字段，你不妨给每个列[字段]增加一个 _M 后缀。还有，日期列[字段]最好以 D_ 作为名字打头。

检查表名、报表名和查询名之间的命名规范。你可能会很快就被这些不同的数据库要素的名称搞糊涂了。假如你坚持统一地命名这些数据库的不同组成部分，至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别。

如果采用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符号来标识对象（比如 tbl_Employees）。我在和 SQL Server 打交道的时候还用过 tbl 来索引表，但我用 sp_company （现在用

sp_feft_）标识存储过程，因为在有的时候如果我发现了更好的处理办法往往会保存好几个拷贝。我在实现 SQL Server 2000 时用 udf_（或者类似的标记）标识我编写的函数。

工欲善其事, 必先利其器

采用理想的数据库设计工具，比如：SyBase 公司的PowerDesigner，她支持 PB、VB、Delphi 等语言，通过 ODBC 可以连接市面上流行的 30 多个数据库，包括 dBase、FoxPro、VFP、SQL Server 等，今后有机会我将着重介绍 PowerDesigner 的使用。

获取数据模式资源手册

正在寻求示例模式的人可以阅读《数据模式资源手册》一书，该书

由 Len Silverston、W. H. Inmon 和 Kent Graziano 编写，是一本值得拥有的最佳数据建模图书。该书包括的章节涵盖多种数据领域，比如人员、机构和工作效能等。其他的你还可以参考：[1]萨师煊　王珊

著　数据库系统概论(第二版)高等教育出版社 1991、[2][美] Steven M.Bobrowski 著 Oracle 7 与客户／服务器计算技术从入门到精通　刘建元等译　电子工业出版社，1996、[3]周中元　信息系统建模方法(下)　电子与信息化　1999年第3期，1999

畅想未来，但不可忘了过去的教训

我发现询问用户如何看待未来需求变化非常有用。这样做可以达到两个目的：首先，你可以清楚地了解应用设计在哪个地方应该更具灵活性以及如何避免性能瓶颈；其次，你知道发生事先没有确定的需求变更时用户将和你一样感到吃惊。

一定要记住过去的经验教训！我们开发人员还应该通过分享自己的体会和经验互相帮助。即使用户认为他们再也不需要什么支持了，我们也应该对他们进行这方面的教育，我们都曾经面临过这样的时刻“当初要是这么做了该多好..”。

在物理实践之前进行逻辑设计

在深入物理设计之前要先进行逻辑设计。随着大量的 CASE 工具不断涌现出来，你的设计也可以达到相当高的逻辑水准，你通常可以从整体上更好地了解数据库设计所需要的方方面面。

了解你的业务

在你百分百地确定系统从客户角度满足其需求之前不要在你的

ER（实体关系）模式中加入哪怕一个数据表（怎么，你还没有模式？那请你参看技巧 9）。了解你的企业业务可以在以后的开发阶段节约大量的时间。一旦你明确了业务需求，你就可以自己做出许多决策了。

一旦你认为你已经明确了业务内容，你最好同客户进行一次系统的交流。采用客户的术语并且向他们解释你所想到的和你所听到的。同时还应该用可能、将会和必须等词汇表达出系统的关系基数。这样你就可以让你的客户纠正你自己的理解然后做好下一步的 ER 设计。

创建数据字典和 ER 图表

一定要花点时间创建 ER 图表和数据字典。其中至少应该包含每个字段的数据类型和在每个表内的主外键。创建 ER 图表和数据字典确实有点费时但对其他开发人员要了解整个设计却是完全必要的。越早创建越能有助于避免今后面临的可能混乱，从而可以让任何了解数据库的人都明确如何从数据库中获得数据。

有一份诸如 ER 图表等最新文档其重要性如何强调都不过分，这对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对 SQL 表达式的文档化来说这是完全必要的。

创建模式

一张图表胜过千言万语：开发人员不仅要阅读和实现它，而且还要用它来帮助自己和用户对话。模式有助于提高协作效能，这样在先期的数据库设计中几乎不可能出现大的问题。模式不必弄的很复杂；甚至可以简单到手写在一张纸上就可以了。只是要保证其上的逻辑关系今后能产生效益。

从输入输出下手

在定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。举个简单的例子：假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。

报表技巧

要了解用户通常是如何报告数据的：批处理还是在线提交报表？时间间隔是每天、每周、每月、每个季度还是每年？如果需要的话还可以考虑创建总结表。系统生成的主键在报表中很难管理。用户在具有系统生成主键的表内用副键进行检索往往会返回许多重复数据。这样的检索性能比较低而且容易引起混乱。

理解客户需求

看起来这应该是显而易见的事，但需求就是来自客户（这里要从内部和外部客户的角度考虑）。不要依赖用户写下来的需求，真正的需求在客户的脑袋里。你要让客户解释其需求，而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中。一个不变的真理是：“只有我看见了我才知道我想要的是什么”必然会导致大量的返工，因为数据库没有达到客户从来没有写下来的需求标准。而更糟的是你对他们需求的解释只属于你自己，而且可能是完全错误的。

第 2 部分 - 设计表和字段

检查各种变化

我在设计数据库的时候会考虑到哪些数据字段将来可能会发生变更。比方说，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存储客户信息时，我倾向于在单独的一个

数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。

采用有意义的字段名

有一回我参加开发过一个项目，其中有从其他程序员那里继承的程序，那个程序员喜欢用屏幕上显示数据指示用语命名字段，这也不赖，但不幸的是，她还喜欢用一些奇怪的命名法，其命名采用了匈牙利命名和控制序号的组合形式，比如 cbo1、txt2、txt2_b 等等。

除非你在使用只面向你的缩写字段名的系统，否则请尽可能地把字段描述的清楚些。当然，也别做过头了，比如

Customer_Shipping_Address_Street_Line_1，虽然很富有说明性，但没人愿意键入这么长的名字，具体尺度就在你的把握中。

采用前缀命名

如果多个表里有好多同一类型的字段（比如 FirstName），你不妨用特定表的前缀（比如 CusLastName）来帮助你标识字段。

时效性数据应包括“最近更新日期/时间”字段。时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用。标准化和数据驱动

数据的标准化不仅方便了自己而且也方便了其他人。比方说，假如你的用户界面要访问外部数据源（文件、XML 文档、其他数据库等），你不妨把相应的连接和路径信息存储在用户界面支持表里。还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状态等），那么产生工作流的数据也可以存放在数据库里。预先安排总需要付出努力，但如果这些过程采用数据驱动而非硬编码的方式，那么策略变更和维护都会方便得多。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。

标准化不能过头

对那些不熟悉标准化一词（normalization）的人而言，标准化可以保证表内的字段都是最基础的要素，而这一措施有助于消除数据库中的数据冗余。标准化有好几种形式，但 Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，3NF 规定：

* 表内的每一个值都只能被表达一次。

* 表内的每一行都应该被唯一的标识（有唯一键）。

* 表内不应该存储依赖于其他键的非键信息。

遵守 3NF 标准的数据库具有以下特点：有一组表专门存放通过键连

接起来的关联数据。比方说，某个存放客户及其有关定单的 3NF 数据库就可能有两个表：Customer 和 Order。Order 表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向 Customer 表里包含该客户信息的那一行。

更高层次的标准化也有，但更标准是否就一定更好呢？答案是不一定。事实上，对某些项目来说，甚至就连 3NF 都可能给数据库引入太高的复杂性。

为了效率的缘故，对表不进行标准化有时也是必要的，这样的例子很多。曾经有个开发餐饮分析软件的活就是用非标准化表把查询时间从平均 40 秒降低到了两秒左右。虽然我不得不这么做，但我绝不把数据表的非标准化当作当然的设计理念。而具体的操作不过是一种派生。所以如果表出了问题重新产生非标准化的表是完全可能的。Microsoft Visual FoxPro 报表技巧

如果你正在使用 Microsoft Visual FoxPro，你可以用对用户友好的字段名来代替编号的名称：比如用 Customer Name 代替 txtCNaM。这样，当你用向导程序 [Wizards，台湾人称为‘精灵’] 创建表单和报表时，其名字会让那些不是程序员的人更容易阅读。

不活跃或者不采用的指示符

增加一个字段表示所在记录是否在业务中不再活跃挺有用的。不管是客户、员工还是其他什么人，这样做都能有助于再运行查询的时候过滤活跃或者不活跃状态。同时还消除了新用户在采用数据时所面临的一些问题，比如，某些记录可能不再为他们所用，再删除的时候可以起到一定的防范作用。

使用角色实体定义属于某类别的列[字段]在需要对属于特定类别或者具有特定角色的事物做定义时，可以用角色实体来创建特定的时间关联关系，从而可以实现自我文档化。

这里的含义不是让 PERSON 实体带有 Title 字段，而是说，为什么不用 PERSON 实体和 PERSON_TYPE 实体来描述人员呢？比方说，当John Smith, Engineer 提升为 John Smith, Director 乃至最后爬到John Smith, CIO 的高位，而所有你要做的不过是改变两个表 PERSON 和 PERSON_TYPE 之间关系的键值，同时增加一个日期/时间字段来知道变化是何时发生的。这样，你的 PERSON_TYPE 表就包含了所有 PERSON 的可能类型，比如 Associate、Engineer、Director、CIO 或者 CEO 等。

还有个替代办法就是改变 PERSON 记录来反映新头衔的变化，不过这样一来在时间上无法跟踪个人所处位置的具体时间。

采用常用实体命名机构数据

组织数据的最简单办法就是采用常用名字，比如：PERSON、ORGANIZATION、ADDRESS 和 PHONE 等等。当你把这些常用的一般名字组合起来或者创建特定的相应副实体时，你就得到了自己用的特殊版本。开始的时候采用一般术语的主要原因在于所有的具体用户都能对抽象事物具体化。

有了这些抽象表示，你就可以在第 2 级标识中采用自己的特殊名称，比如，PERSON 可能是 Employee、Spouse、Patient、Client、Customer、Vendor 或者 Teacher 等。同样的，ORGANIZATION 也可能是 MyCompany、MyDepartment、Competitor、Hospital、Warehouse、Government 等。最后 ADDRESS 可以具体为 Site、Location、Home、Work、Client、Vendor、Corporate 和 FieldOffice 等。

采用一般抽象术语来标识“事物”的类别可以让你在关联数据以满足业务要求方面获得巨大的灵活性，同时这样做还可以显著降低数据存储所需的冗余量。

用户来自世界各地

在设计用到网络或者具有其他国际特性的数据库时，一定要记住大多数国家都有不同的字段格式，比如邮政编码等，有些国家，比如新西兰就没有邮政编码一说。

数据重复需要采用分立的数据表

如果你发现自己在重复输入数据，请创建新表和新的关系。

每个表中都应该添加的 3 个有用的字段* dRecordCreationDate，在 VB 下默认是 Now()，而在 SQL Server 下默认为 GETDATE()

* sRecordCreator，在 SQL Server 下默认为 NOT NULL DEFAULT USER

* nRecordVersion，记录的版本标记；有助于准确说明记录中出现null 数据或者丢失数据的原因

对地址和电话采用多个字段

描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和 Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。

过分标准化可要小心，这样做可能会导致性能上出现问题。虽然地址和电话表分离通常可以达到最佳状态，但是如果需要经常访问这类信

息，或许在其父表中存放“首选”信息（比如 Customer 等）更为妥当些。非标准化和加速访问之间的妥协是有一定意义的。

使用多个名称字段

我觉得很吃惊，许多人在数据库里就给 name 留一个字段。我觉得只有刚入门的开发人员才会这么做，但实际上网上这种做法非常普遍。我建议应该把姓氏和名字当作两个字段来处理，然后在查询的时候再把他们组合起来。

我最常用的是在同一表中创建一个计算列[字段]，通过它可以自动地连接标准化后的字段，这样数据变动的时候它也跟着变。不过，这样做在采用建模软件时得很机灵才行。总之，采用连接字段的方式可以有效的隔离用户应用和开发人员界面。

提防大小写混用的对象名和特殊字符

过去最令我恼火的事情之一就是数据库里有大小写混用的对象名，比如 CustomerData。这一问题从 Access 到 Oracle 数据库都存在。我不喜欢采用这种大小写混用的对象命名方法，结果还不得不手工修改名字。想想看，这种数据库/应用程序能混到采用更强大数据库的那一天吗？采用全部大写而且包含下划符的名字具有更好的可读性（CUSTOMER_DATA），绝对不要在对象名的字符之间留空格。

小心保留词

要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突，比如，最近我编写的一个 ODBC 连接程序里有个表，其中就用了DESC 作为说明字段名。后果可想而知！DESC 是 DESCENDING 缩写后的保留词。表里的一个 SELECT * 语句倒是能用，但我得到的却是一大堆毫无用处的信息。

保持字段名和类型的一致性

在命名字段并为其指定数据类型的时候一定要保证一致性。假如字段在某个表中叫做“agreement_number”，你就别在另一个表里把名字改成“ref1”。假如数据类型在一个表里是整数，那在另一个表里可就别变成字符型了。记住，你干完自己的活了，其他人还要用你的数据库呢。

仔细选择数字类型

在 SQL 中使用 smallint 和 tinyint 类型要特别小心，比如，假如你想看看月销售总额，你的总额字段类型是 smallint，那么，如果总额超过了 $32,767 你就不能进行计算操作了。

删除标记

在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行；最好采用清除数据程序而且要仔细维护索引整体性。

避免使用触发器

触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。

包含版本机制

建议你在数据库中引入版本控制机制来确定使用中的数据库的版本。无论如何你都要实现这一要求。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。虽然你可以通过检查新字段或者索引来确定数据库结构的版本，但我发现把版本信息直接存放到数据库中不更为方便吗？。

给文本字段留足余量

ID 类型的文本字段，比如客户 ID 或定单号等等都应该设置得比一般想象更大，因为时间不长你多半就会因为要添加额外的字符而难堪不已。比方说，假设你的客户 ID 为 10 位数长。那你应该把数据库表字段的长度设为 12 或者 13 个字符长。这算浪费空间吗？是有一点，但也没你想象的那么多：一个字段加长 3 个字符在有 1 百万条记录，再加上一点索引的情况下才不过让整个数据库多占据 3MB 的空间。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。身份证的号码从 15 位变成 18 位就是最好和最惨痛的例子。列[字段]命名技巧

我们发现，假如你给每个表的列[字段]名都采用统一的前缀，那么在编写 SQL 表达式的时候会得到大大的简化。这样做也确实有缺点，比如破坏了自动表连接工具的作用，后者把公共列[字段]名同某些数据库联系起来，不过就连这些工具有时不也连接错误嘛。举个简单的例子，假设有两个表：

Customer 和 Order。Customer 表的前缀是 cu_，所以该表内的子段名如下：cu_name_id、cu_surname、cu_initials 和cu_address 等。Order 表的前缀是 or_，所以子段名是：

or_order_id、or_cust_name_id、or_quantity 和 or_description 等。

这样从数据库中选出全部数据的 SQL 语句可以写成如下所示：

Select * From Customer, Order Where cu_surname = "MYNAME" ;

and cu_name_id = or_cust_name_id and or_quantity = 1

在没有这些前缀的情况下则写成这个样子（用别名来区分）：

Select * From Customer, Order Where Customer.surname = "MYNAME" ;

and https://www.wendangku.net/doc/ab9461697.html,_id = Order.cust_name_id and Order.quantity = 1

第 1 个 SQL 语句没少键入多少字符。但如果查询涉及到 5 个表乃至更多的列[字段]你就知道这个技巧多有用了。

第 3 部分 - 选择键和索引

数据采掘要预先计划

我所在的某一客户部门一度要处理 8 万多份联系方式，同时填写每个客户的必要数据（这绝对不是小活）。我从中还要确定出一组客户作为市场目标。当我从最开始设计表和字段的时候，我试图不在主索引里增加太多的字段以便加快数据库的运行速度。然后我意识到特定的组查询和信息采掘既不准确速度也不快。结果只好在主索引中重建而且合并了数据字段。我发现有一个指示计划相当关键——当我想创建系统类型查找时为什么要采用号码作为主索引字段呢？我可以用传真号码进行检索，但是它几乎就象系统类型一样对我来说并不重要。采用后者作为主字段，数据库更新后重新索引和检索就快多了。

可操作数据仓库（ODS）和数据仓库（DW）这两种环境下的数据索引是有差别的。在 DW 环境下，你要考虑销售部门是如何组织销售活动的。他们并不是数据库管理员，但是他们确定表内的键信息。这里设计人员或者数据库工作人员应该分析数据库结构从而确定出性能和正确输出之间的最佳条件。

使用系统生成的主键

这类同技巧 1，但我觉得有必要在这里重复提醒大家。假如你总是在设计数据库的时候采用系统生成的键作为主键，那么你实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。

采用系统生成键作为主键还有一个优点：当你拥有一致的键结构时，找到逻辑缺陷很容易。

分解字段用于索引

为了分离命名字段和包含字段以支持用户定义的报表，请考虑分解其他字段（甚至主键）为其组成要素以便用户可以对其进行索引。索引将加快 SQL 和报表生成器脚本的执行速度。比方说，我通常在必须使

用 SQL LIKE 表达式的情况下创建报表，因为 case number 字段无法分解为 year、serial number、case type 和 defendant code 等要素。性能也会变坏。假如年度和类型字段可以分解为索引字段那么这些报表运行起来就会快多了。

键设计 4 原则

* 为关联字段创建外键。

* 所有的键都必须唯一。

* 避免使用复合键。

* 外键总是关联唯一的键字段。

别忘了索引

索引是从数据库中获取数据的最高效方式之一。95% 的数据库性能问题都可以采用索引技术得到解决。作为一条规则，我通常对逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列[字段]采用非成组索引。不过，索引就象是盐，太多了菜就咸了。你得考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。

大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。还有，不要索引 memo/note 字段，不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。

不要索引常用的小型表

不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。

不要把社会保障号码（SSN）或身份证号码（ID）选作键

永远都不要使用 SSN 或 ID 作为数据库的键。除了隐私原因以外，须知政府越来越趋向于不准许把 SSN 或 ID 用作除收入相关以外的其他目的，SSN 或 ID 需要手工输入。永远不要使用手工输入的键作为主键，因为一旦你输入错误，你唯一能做的就是删除整个记录然后从头开始。

我在破解他人的程序时候，我看到很多人把 SSN 或 ID 还曾被用做系列号，当然尽管这么做是非法的。而且人们也都知道这是非法的，但他们已经习惯了。后来，随着盗取身份犯罪案件的增加，我现在的同行正痛苦地从一大摊子数据中把 SSN 或 ID 删除。

不要用用户的键

在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。这样做会迫使你采取以下两个措施：

在创建记录之后对用户编辑字段的行为施加限制。假如你这么做

了，你可能会发现你的应用程序在商务需求突然发生变化，而用

户需要编辑那些不可编辑的字段时缺乏足够的灵活性。当用户在

输入数据之后直到保存记录才发现系统出了问题他们该怎么想？

删除重建？假如记录不可重建是否让用户走开？

* 提出一些检测和纠正键冲突的方法。通常，费点精力也就搞定

了，但是从性能上来看这样做的代价就比较大了。还有，键的纠

正可能会迫使你突破你的数据和商业/用户界面层之间的隔离。

所以还是重提一句老话：你的设计要适应用户而不是让用户来适

应你的设计。

不让主键具有可更新性的原因是在关系模式下，主键实现了不同

表之间的关联。比如，Customer 表有一个主键 CustomerID，而

客户的定单则存放在另一个表里。Order 表的主键可能是

OrderNo 或者 OrderNo、CustomerID 和日期的组合。不管你选

择哪种键设置，你都需要在 Order 表中存放 CustomerID 来保

证你可以给下定单的用户找到其定单记录。

假如你在 Customer 表里修改了 CustomerID，那么你必须找出

Order 表中的所有相关记录对其进行修改。否则，有些定单就会

不属于任何客户——数据库的完整性就算完蛋了。

如果索引完整性规则施加到表一级，那么在不编写大量代码和附

加删除记录的情况下几乎不可能改变某一条记录的键和数据库内

所有关联的记录。而这一过程往往错误丛生所以应该尽量避免。可选键(候选键)有时可做主键

记住，查询数据的不是机器而是人。假如你有可选键，你可能进一步把它用做主键。那样的话，你就拥有了建立强大索引的能力。这样可以阻止使用数据库的人不得不连接数据库从而恰当的过滤数据。在严格控制域表的数据库上，这种负载是比较醒目的。如果可选键真正有用，那就是达到了主键的水准。

我的看法是，假如你有可选键，比如国家表内的 state_code，你不要在现有不能变动的唯一键上创建后续的键。你要做的无非是创建毫无价值的数据。如你因为过度使用表的后续键[别名]建立这种表的关联，操作负载真得需要考虑一下了。

别忘了外键

大多数数据库索引自动创建的主键字段。但别忘了索引外键字段，它们在你想查询主表中的记录及其关联记录时每次都会用到。还有，不要索引 memo/notes 字段而且不要索引大型文本字段（许多字符），这样做会让你的索引占据大量的数据库空间。

第 4 部分 - 保证数据的完整性

用约束而非商务规则强制数据完整性

如果你按照商务规则来处理需求，那么你应当检查商务层次/用户界面：如果商务规则以后发生变化，那么只需要进行更新即可。假如需求源于维护数据完整性的需要，那么在数据库层面上需要施加限制条件。如果你在数据层确实采用了约束，你要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面。除非你的字段命名很冗长，否则字段名本身还不够。

只要有可能，请采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。

分布式数据系统

对分布式系统而言，在你决定是否在各个站点复制所有数据还是把数据保存在一个地方之前应该估计一下未来 5 年或者 10 年的数据量。当你把数据传送到其他站点的时候，最好在数据库字段中设置一些标记。在目的站点收到你的数据之后更新你的标记。为了进行这种数据传输，请写下你自己的批处理或者调度程序以特定时间间隔运行而不要让用户在每天的工作后传输数据。本地拷贝你的维护数据，比如计算常数和利息率等，设置版本号保证数据在每个站点都完全一致。

强制指示完整性(参照完整性?)

没有好办法能在有害数据进入数据库之后消除它，所以你应该在它进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。关系

如果两个实体之间存在多对一关系，而且还有可能转化为多对多关系，那么你最好一开始就设置成多对多关系。从现有的多对一关系转变为多对多关系比一开始就是多对多关系要难得多。

采用视图

为了在你的数据库和你的应用程序代码之间提供另一层抽象，你可以为你的应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。

给数据保有和恢复制定计划

考虑数据保有策略并包含在设计过程中，预先设计你的数据恢复过程。采用可以发布给用户/开发人员的数据字典实现方便的数据识别同时保证对数据源文档化。编写在线更新来“更新查询”供以后万一数据丢失可以重新处理更新。

用存储过程让系统做重活

解决了许多麻烦来产生一个具有高度完整性的数据库解决方案之后，我决定封装一些关联表的功能组，提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。数据库不只是一个存放数据的地方，它也是简化编码之地。

使用查找

控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。

第 5 部分 - 各种小技巧

文档、文档、文档

对所有的快捷方式、命名规范、限制和函数都要编制文档。

采用给表、列[字段]、触发器等加注释的数据库工具。是的，这有点费事，但从长远来看，这样做对开发、支持和跟踪修改非常有用。

取决于你使用的数据库系统，可能有一些软件会给你一些供你很快上手的文档。你可能希望先开始在说，然后获得越来越多的细节。或者你可能希望周期性的预排，在输入新数据同时随着你的进展对每一部分细节化。不管你选择哪种方式，总要对你的数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当你过了一年多时间后再回过头来做第 2 个版本，你犯错的机会将大大减少。

使用常用英语（或者其他任何语言）而不要使用编码

为什么我们经常采用编码（比如 9935A 可能是‘青岛啤酒’的供应

代码，4XF788-Q 可能是帐目编码）？理由很多。但是用户通常都用英语进行思考而不是编码。工作 5 年的会计或许知道 4XF788-Q 是什么东西，但新来的可就不一定了。在创建下拉菜单、列表、报表时最好按照英语名排序。假如你需要编码，那你可以在编码旁附上用户知道的英语。

保存常用信息

让一个表专门存放一般数据库信息非常有用。我常在这个表里存放数据库当前版本、最近检查/修复（对 FoxPro）、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。

测试、测试、反复测试

建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证你选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。

检查设计

在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。

Microsoft Visual FoxPro 设计技巧

对复杂的 Microsoft Visual FoxPro 数据库应用程序而言，可以把所有的主表放在一个数据库容器文件里，然后增加其他数据库表文件和装载同原有数据库有关的特殊文件。根据需要用这些文件连接到主文件中的主表。比如数据输入、数据索引、统计分析、向管理层或者政府部门提供报表以及各类只读查询等。这一措施简化了用户和组权限的分配，而且有利于应用程序函数（存储过程）的分组和划分，从而在程序必须修改的时候易于管理。

数据库课程设计心得体会精选篇

数据库课程设计心得体会精选篇 课程培训活动，四对于提高专业技能的一个很好的方式，下面由小编为大家带来的数据库课程设计心得体会精选范文，仅供参考~ 数据库课程设计心得体会一 两个星期的时间非常快就过去了，这两个星期不敢说自己有多大的进步，获得了多少知识，但起码是了解了项目开发的部分过程。虽说上过数据库上过管理信息系统等相关的课程，但是没有亲身经历过相关的设计工作细节。这次实习证实提供了一个很好的机会。 通过这次课程设计发现这其中需要的很多知识我们没有接触过，去图书馆查资料的时候发现我们前边所学到的仅仅是皮毛，还有很多需要我们掌握的东西我们根本不知道。同时也发现有很多已经学过的东西我们没有理解到位，不能灵活运用于实际，不能很好的用来解决问题，这就需要我们不断的大量的实践，通过不断的自学，不断地发现问题，思考问题，进而解决问题。在这个过程中我们将深刻理解所学知识，同时也可以学到不少很实用的东西。 从各种文档的阅读到开始的需求分析、概念结构设计、逻辑结构设计、物理结构设计。亲身体验了一回系统的设计开发过程。很多东西书上写的很清楚，貌似看着也很简单，

思路非常清晰。但真正需要自己想办法去设计一个系统的时候才发现其中的难度。经常做到后面突然就发现自己一开始的设计有问题，然后又回去翻工，在各种反复中不断完善自己的想法。 我想有这样的问题不止我一个，事后想想是一开始着手做的时候下手过于轻快，或者说是根本不了解自己要做的这个系统是给谁用的。因为没有事先做过仔细的用户调查，不知道整个业务的流程，也不知道用户需要什么功能就忙着开发，这是作为设计开发人员需要特别警惕避免的，不然会给后来的工作带来很大的麻烦，甚至可能会需要全盘推倒重来。所以以后的课程设计要特别注意这一块的设计。 按照要求，我们做的是机票预订系统。说实话，我对这个是一无所知的，没有订过机票，也不知道航空公司是怎么一个流程。盲目开始设计的下场我已经尝过了，结果就是出来一个四不像的设计方案，没有什么实际用处。没有前期的调查，仅从指导书上那几条要求着手是不够的。 在需求分析过程中，我们通过上网查资料，去图书馆查阅相关资料，结合我们的生活经验，根据可行性研究的结果和客户的要求，分析现有情况及问题，采用client/server结构，将机票预定系统划分为两个子系统：客户端子系统，服务器端子系统。在两周的时间里，不断地对程序及各模块进行修改、编译、调试、运行，其间遇到很多问题：由于忘记了一

钢结构最新设计规范

钢结构设计规范GB50017-2003 第一章总则 第1.0.1 条为在钢结构设计中贯彻执行国家的技术经济政策，做到技术先进、经济合理、安全适用、确保质量，特制定本规范。 第1.0.2 条本规范适用于工业与民用房屋和一般构筑物的钢结构设计。 第1.0.3 条本规范的设计原则是根据《建筑结构设计统一标准》（CBJ68-84））制订的。 第1.0.4 条设计钢结构时，应从工程实际情况出发，合理选用材料、结构方案和构造措施，满足结构在运输、安装和使用过程中的强度、稳定性和刚度要求，宜优先采用定型的和标准化的结构和构件，减少制作、安装工作量，符合防火要求，注意结构的抗腐蚀性能。 第1.0.5 条在钢结构设计图纸和钢材订货文件中，应注明所采用的钢号（对普通碳素钢尚应包括钢类、炉种、脱氧程度等）、连接材料的型号（或钢号）和对钢材所要求的机械性能和化学成分的附加保证项目。此外，在钢结构设计图纸中还应注明所要求的焊缝质量级别（焊缝质量级别的检验标准应符合国家现行《钢结构工程施工及验收规范》）。 第1.0.6 条对有特殊设计要求和在特殊情况下的钢结构设计，尚应符合国家现行有关规范的要求。 第二章材料 第2.0.1 条承重结构的钢材，应根据结构的重要性、荷载特征、连接方法、工作温度等不同情况选择其钢号和材质。承重结构的钢材宜采用平炉或氧气转炉3 号钢（沸腾钢或镇静钢）、16Mn钢、16Mnq钢、15MnV钢或15MnVq钢，其质量应分别符合现行标准《普通碳素结构钢技术条件》、《低合金结构钢技术条件》和《桥梁用碳素钢及普通低合金钢钢板技术条件》的规定。 第2.0.2 条下列情况的承重结构不宜采用3 号沸腾钢: 一、焊接结构：重级工作制吊车梁、吊车桁架或类似结构，冬季计算温度等于或低于－ 20C时的轻、中级工作制吊车梁、吊车桁架或类似结构，以及冬季计算温度等于或低于—30 C 时的其它承重结构。 二、非焊接结构：冬季计算温度等于或低于- 20 C时的重级工作制吊车梁、吊车桁架 或类似结构。 注：冬季计算温度应按国家现行《采暖通风和空气调节设计规范》中规定的冬季空气调节室外计算温度确定，对采暖房屋内的结构可按该规定值提高10 C采用。 第2.0.3 条承重结构的钢材应具有抗拉强度、伸长率、屈服强度（或屈服点）和硫、磷含量的合格保证,对焊接结构尚应具有碳含量的合格保证。承重结构的钢材，必要时尚应具有冷弯试验的合格保证。对于重级工作制和吊车起重量等于或大于50 t的中级工作制焊 接吊车梁、吊车桁架或类似结构的钢材，应具有常温冲击韧性的合格保证。但当冬季计算温度等于或低于-20 C时，对于3号钢尚应具有-20C冲击韧性的合格保证；对于16Mn钢、16Mnq钢、15MnV钢或15MnVq钢尚应具有—40C冲击韧性的合格保证。对于重级工作制的非焊接吊车梁、吊车桁架或类似结构的钢材,必要时亦应具有冲击韧性的合格保证。 第2.0.4 条钢铸件应采用现行标准《一般工程用铸造碳钢》中规定的ZG200-400、ZG230-450 、ZG270-500 或ZG310-570 号钢。 第2.0.5 条钢结构的连接材料应符合下列要求: 一、手工焊接采用的焊条，应符合现行标准《碳钢焊条》或《低合金钢焊条》的规定。 选择的焊条型号应与主体金属强度相适应。对重级工作制吊车梁、吊车桁架或类似结构，宜采用低氢型焊条。 二、自动焊接或半自动焊接采用的焊丝和焊剂，应与主体金属强度相适应。焊丝应符合现行标准《焊接用钢丝》的规定。

结构设计学习心得体会

结构设计学习心得体会范文 1、拜模仿为师，从模仿中学习，不断提高 通常的设计，80-90%都是对已有的技术进行模仿、综合后搞出来的。充分利用他人的经验和过去的经验，使之为自己服务，不断进步。 2、对设计要迷恋不舍 设计人员要有美学观，安稳观，能区分产品美与不美，安定与不安定。其次设计人员要为用户设身处地着想，站在用户立场上体验。信心来自对设计的迷恋，像迷恋情人那样迷恋设计，使出全部精力和才华，这就是信心的基础，也是征服用户，为用户喜欢的奥妙所在。 3、形状和结构产生于力 机器产品都在负载下工作，以最弱部分的强度为依据进行设计，查清受载情况，以受力分析为靠山。（在电子设备产品设计中：塑料件以刚度校核为主、金属件以强度校核为主）。 4、图纸比理论重要，事实又比图纸重要 设计者必需用设计好的图纸来表达思想，图纸合理地处理了理论和工程问题，这就是图纸重于理论的意思；实际是设计人员的源泉，当听到不能按照图纸制造或用户意见时，应该认真对待，切忌草率。 5、使用后才能更深理解 厂内试验合格，实际使用中还会发生问题，因为用户现场的条件和制造厂的条件不同；工人不一定已经掌握了操作要领，维护保养不方便。所以设计不要只满足于当初的目标和要求，在使用现场搜集情况，发现各种问题，改进设计，保证产品质量，使生产保持正常，降低成本，降低消耗。 6、不要一味追求高精度 装配中因误差大而不能正常装配，往往是加工车间和设计部门之间扯皮、埋怨的根源，于是设计人员缩小公差范围。产品的成本是按精度的几何级数上升的，设计者笔头上稍微疏忽，成本可能直线上升。几个符合精度的零件不一定能装起来，这是尺寸链问题。在尺寸链的某一环节留出调整位置，装配后临时加工，就能达到装配目的，不一定把精度定得很严。搞设计要做到产品使用可靠，操作方便，制造容易，维护简单。要做到这些，需要刻苦锻炼，努力学习，决非一日之功。 7、多用标准零件、通用零件 机械制造业已经越来越专业化，要想什么都靠自己工厂制造，这是既不经济又是过时的思想。搞一个新产品的设计，应尽可能的采用通用零件和标准零件，这样做既能缩短生产周期，也便于互换和降低成本。随着工业的不断发展，专业化也必然会大力发展，设计人员应该了解专业化的发展，熟悉市场能提供的通用零件、标准零件和其它

数据库课程设计心得体会

数据库课程设计心得体会 数据库课程设计心得体会 数据库课程设计大赛的尘嚣渐渐远去,怀着对这次大赛的些许不舍,怀着对当初课程设计开始时候的豪情万丈的决心的留恋,怀着通过这次课程设计积累的信心与斗志,我开始写这篇文章,为自己的足迹留下哪怕是微不足道但是对自己弥足珍贵的痕迹并期望与大家共勉。 首先,让我的记忆追溯到大二暑假,在老大的指引下(老大劝我学https://www.wendangku.net/doc/ab9461697.html,),我接触到microsoft 公司的.net产品。那个时候我已经学过vc 和asp,因为windows程序设计实验的课的关系,接触过vb,但是没有专门去学他,因为习惯了c++里面的class,int,觉得vb的sub,var 看着就不是很顺心。我是一个好奇心很强的人,突然看到了一个号称“.net是用于创建下一代应用程序的理想而又现实的开发工具”,而且主推c#语言,由于对c语言的一贯好感,我几乎是立刻对他产生了兴趣。我就开始了对c#的学习,任何语言都不是孤立存在的,所以数据交互是很重要的,暑假的时候我把我们这学期的课本数据库系统概论看了一遍。我记得以前用c语言编程的时候,数据是在内存中申请空间,譬如使用数组等等。很耗费内存空间。这个时候就是数据库站出来的时候啦,于是我又装上了sql server2000,以前学asp的时候用的是access,那个时候只是照着人家做,理论是什么也不是很清楚。 通过一个暑假的学习,基本搞清楚了理论方面的东西,具体怎么用也不是很清楚。但是这为这学期的课程设计打下了铺垫。 来到学校后,随着这学期的数据库课程大赛开始了,我有一个看法就是我自己应该具备的能力不是我会多少,而是我应该具备快速学会东西的能力。遇到什么就学什么。我们有时候很容易被一些专业名词说吓着,包括什么建模,软件工程,数据分析,数据挖掘等等。我身边就有很多同学被这些纸老虎所唬住,而没有勇气去接触他们,总是说这个太难了之类的退堂鼓的话,他们低估了自己的潜力同时也压抑住了他们自己的好奇心。其实都是纸老虎,又不是什么国家科研难题,只是去用一些工具,发明工具是很难,但是用一个工具就容易多了,just do it!我记得我做这个数据库之前,我们老师说要做好前期分析,我就在网上搜索用什么分析工具好。最后我选择了roseuml建模工具。在此之前,我脑袋里面没有软件建模的思想,什么uml 建模对我而言就是一张空白的纸。但是真正接触后并没有想象的那么难,有什么不懂的上网去搜索,这是一个信息横流的世界,有google,baidu就没有不能解决的知识难题。以及后来的数据库分析的时候用到的powerdesigner也是一样。 开发的时候我想过用什么架构,c/s模式?模式有很多,怎么选择?我就上网搜索现在最流行的架构是什么。结果搜到了mvc架构,就是你啦。我决定用这个架构,不会,没关系,咱学。just do it!前期工作准备好后,那么我就得把我暑假学的.net加以实践。这个时候我更加深入的了解了利用https://www.wendangku.net/doc/ab9461697.html,操纵数据库的知识。并且对数据库里面的存储过程有了比较深入的了解。经过大概2个多星期的奋斗,我完成了我的数据库课程设计--基于.net数据集的图书馆管理系统。并最后非常荣幸的获得了大赛的一等奖以及以及新技术应用奖。 与其临渊羡鱼,不如退而结网。这次数据库课程设计给我的最大的印象就是如果自己有了兴趣,就动手去做,困难在你的勇气和毅力下是抬不了头的。从做这个数据库开始无论遇到什么困难,我都没有一丝的放弃的念头。出于对知识的渴望,出于对新技术的好奇,出于对一切未知的求知。我完成了这次数据库课程设计,不过这只是我学习路上的驿站,未来十年.net 的核心技术就是xml[至少微软是这么宣传的],我会继续学习它,包括jave公司的j2ee我也很想试试,语言本来就是相通的,just do it!语言并不重要毕竟它仅仅是工具,用好一个工具并不是一件值得为外人道的事情,主要是了解学习思想。古语说的好:学无止境啊! 我很庆幸我参加了这次数据库大赛,让我确实打开了眼界。 (最后,很感激学校给了我们这次动手实践的机会,让我们学生有了一个共同学习,增长

钢结构最新设计规范方案

钢结构设计规GB50017-2003 第一章总则 第1.0.1条为在钢结构设计中贯彻执行国家的技术经济政策，做到技术先进、经济合理、安全适用、确保质量，特制定本规。 第1.0.2条本规适用于工业与民用房屋和一般构筑物的钢结构设计。 第1.0.3条本规的设计原则是根据《建筑结构设计统一标准》(CBJ68-84)）制订的。 第1.0.4条设计钢结构时，应从工程实际情况出发，合理选用材料、结构方案和构造措施，满足结构在运输、安装和使用过程中的强度、稳定性和刚度要求，宜优先采用定型的和标准化的结构和构件，减少制作、安装工作量，符合防火要求，注意结构的抗腐蚀性能。 第1.0.5条在钢结构设计图纸和钢材订货文件中，应注明所采用的钢号（对普通碳素钢尚应包括钢类、炉种、脱氧程度等）、连接材料的型号（或钢号）和对钢材所要求的机械性能和化学成分的附加保证项目。此外，在钢结构设计图纸中还应注明所要求的焊缝质量级别（焊缝质量级别的检验标准应符合国家现行《钢结构工程施工及验收规》）。 第1.0.6条对有特殊设计要求和在特殊情况下的钢结构设计，尚应符合国家现行有关规的要求。 第二章材料 第2.0.1条承重结构的钢材，应根据结构的重要性、荷载特征、连接方法、工作温度等不同情况选择其钢号和材质。承重结构的钢材宜采用平炉或氧气转炉3号钢（沸腾钢或镇静钢）、16Mn钢、16Mnq钢、15MnV钢或15MnVq钢，其质量应分别符合现行标准《普通碳素结构钢技术条件》、《低合金结构钢技术条件》和《桥梁用碳素钢及普通低合金钢钢板技术条件》的规定。 第2.0.2条下列情况的承重结构不宜采用3号沸腾钢: 一、焊接结构：重级工作制吊车梁、吊车桁架或类似结构，冬季计算温度等于或低于－20℃时的轻、中级工作制吊车梁、吊车桁架或类似结构，以及冬季计算温度等于或低于－30℃时的其它承重结构。 二、非焊接结构：冬季计算温度等于或低于－20℃时的重级工作制吊车梁、吊车桁架或类似结构。 注：冬季计算温度应按国家现行《采暖通风和空气调节设计规》中规定的冬季空气调节室外计算温度确定，对采暖房屋的结构可按该规定值提高10℃采用。 第2.0.3条承重结构的钢材应具有抗拉强度、伸长率、屈服强度（或屈服点）和硫、磷含量的合格保证,对焊接结构尚应具有碳含量的合格保证。承重结构的钢材，必要时尚应具有冷弯试验的合格保证。对于重级工作制和吊车起重量等于或大于50ｔ的中级工作制焊接吊车梁、吊车桁架或类似结构的钢材，应具有常温冲击韧性的合格保证。但当冬季计算温度等于或低于－20℃时，对于3号钢尚应具有－20℃冲击韧性的合格保证；对于16Mn钢、16Mnq钢、15MnV钢或15MnVq钢尚应具有－40℃冲击韧性的合格保证。对于重级工作制的非焊接吊车梁、吊车桁架或类似结构的钢材,必要时亦应具有冲击韧性的合格保证。 第 2.0.4条钢铸件应采用现行标准《一般工程用铸造碳钢》中规定的ZG200-400、ZG230-450、ZG270-500或ZG310-570号钢。 第2.0.5条钢结构的连接材料应符合下列要求: 一、手工焊接采用的焊条，应符合现行标准《碳钢焊条》或《低合金钢焊条》的规定。选择的焊条型号应与主体金属强度相适应。对重级工作制吊车梁、吊车桁架或类似结构，宜采用低氢型焊条。

MySQL数据库设计经验分享

MySQL数据库设计经验分享 其实这个经验分享并不仅仅针对MySQL，之所以加上这个关键字其实是为了给搜索引擎看的，呵呵。这篇文章的目标是为了拓宽新手的思路，对于老鸟可能没什么帮助了。 文章主要涉及以下方面的内容： 1.数据完整性约束的意义：数据的第一道防线； 2.避免冗余字段：请不要认为这是一种弹性或者灵活性的体现； 3.请尽可能的收集数据：这是一种境界； 4.为什么建立索引：不仅仅是速度； 5.事务、触发器与存储过程：这是一扇门； 数据完整性约束的意义 很多新手创建的数据库非常的简单，一堆字段扔进去就搞定了，反正脚本会搞定一切。但是，你有没有反思过一个问题，写脚本的也是人，是人就会犯错误，犯了错误就可能搞乱数据，而数据是一切应用的基础。因此，我建议你们能够静下来，细心的，花费更多的时间来研究如何更好地设计数据库结构。 主键是必须的 这是我的第一个建议，每个表必须具有主键，而且最好是使用单独的一个字段作为主键，这样从根源上扼杀了出现两条完全相同的数据的可能性。 你可能需要额外的唯一键 例如用户信息表中，除了用户编号以外，其登录名称也应该是唯一的，不要指望以后可以在程序中处理这个情况，现在就做，只要把它标记为唯一键，就算程序中忘了判断也不会让错误的数据被存储进来。 字段的类型和长度 请努力使用与数据匹配的类型和适当的长度，虽然你可以把时间保存为varchar类型，但是明显还是datetime类型更好，因为你不可能把2013-02-30之类的日期保存到datetime 类型的字段中。字段的长度也是需要考虑的，过长虽然比过短带来的麻烦小很多，但是浪费了很多空间。

默认值 尽量为字段设置默认值，例如字段is_read用来表示用户是否已经阅读过这条留言，1表示已读，请为它设一个默认值0来代表未读，而不是在日后的查询语句中通过is_read<> 1或者is_read = IS NULL OR is_read = 0来判断。 允许为NULL吗？ 这个问题需要思考，而不是一概允许或一概不允许这种模式化的判定。同时，建议不要将NULL作为一个特殊的值来使用。 外键约束是必不可少的 你必须理解和开始使用外键，并且明白外键约束的用法，这是维护数据完整性很重要的一环。建立外键的同时你会对程序的业务逻辑有更清晰的认识。正确的使用它防止误删具有依存关系的数据，同时通过级联删除保证在删除的时候不留下任何垃圾。 避免冗余字段 千万不要认为冗余字段能够使数据表更有弹性、更灵活。首先来说冗余的字段必然都是允许为NULL的，因为没有适合的代码为这些字段赋值（如果有的话那就不是冗余字段了，对吗）。这只会增加数据表的体积。事实上修改表结构仅需几分钟，真正的麻烦还是来自于为新字段添加相应的业务逻辑。 而且事物总是在变化的，今天你觉得未来可能会用到这个字段，但是可能下个星期就不这么想了，一个月之后你根本不记得当初留了这么一个字段。所以，删了吧。 尽可能的收集数据 其实这有点跑题，因为这不仅仅是数据库设计的事儿，程序员可能也要付出一些时间。我一贯的观点就是“数据是一切应用的基础”，尽量的收集它们，以后也许会有用（如果这个应用有一个长远的预期的话，否则你可以忽略这点）。 我无法想象Google，百度或者淘宝明天会做什么，但是我能肯定它们的业务调整的依据就是来自这些捕获的数据。 尽可能的收集数据是指在不增加用户操作指令的前提下尽可能的收集一些相关信息。比如各种时间、浏览页面的轨迹等等。我甚至怀疑以后某些应用会收集用户击键频率这样的信息，然后利用它来检测账号是否被盗。 此外，我觉得应该尽量在插入/修改/删除数据的时候多做一些事情，相对来说，这些操

结构设计人员年终总结

工作总结 光阴似箭，岁月如梭，转眼间我来公司已经快四年了，在这段时间里我过得是很充实的，因为专业知识一直在不断的积累，专业能力一直在不断的大幅度提高；在这里我还是要深深的感谢公司对我的信任与培养，给了我那么多的学习和成长的机会，还有要感谢每一位与我合作过的同事伙伴，是你们的配合与帮助，才能使我成长的这么快。经过了几年的相处，给我感触最深的是公司更像是一个温暖的大家庭，因为无论在工作、生活和学习上公司都给予了极大的关怀和包容。公司需要发展，而公司的发展和我们每一个成员是密不可分的，作为公司的一名设计人员，我们更应该为它在前进的道路上贡献一份力量，而这份力量则来自我们做好本职工作，做一名合格的设计人员。要想有所提高，有所突破就必须学会自我总结，下面就对我这几年的工作和学习作如下总结。 来到公司的第一年，是收获最多的一年。因为5.12特大地震的原因，公司格外繁忙，业务也很多，因此手上的事情也多。从砌体结构到框架结构，再后来到底框结构，这些结构形式在工程中是比较多的，因此也渐渐地掌握了基本建模、绘施工图的要求。因为刚开始接触实际工程，所以经常会出现许许多多的问题。首先反应在结构模型上，经常有漏项的事情发生，还有很多时候是模型与实际受力情况不符或有较大出入；其次是反应在施工图上，依然有很多漏项的情况，然后就是不同专业之间有很多矛盾之处，还有很多施工图上本身的错

漏之处；最后就是在工地现场时，观察能力及现场经验不足，很少发现问题或者发现的问题都是比较小的问题，有很多需要控制的质量问题都是师傅或者其他监督部分所发现的，当发现问题后，如何补救或处理更是摸不着头脑。从建立模型到模型完成，从校核模型到修改模型完成，从模型到出校核图，从修改后的校核图到再次校核，从施工图到审查回复，从设计到现场，再从现场到设计这些程序的前前后后，不知道出了多少问题，一次次的审核师傅都兢兢业业、不厌其烦地一一执行，自己所出问题，公司都一次次的解决。正是因为这么多的问题和失误，才让我不断的掌握专业知识，第一次有了理论结合实践的亲身体会。 到了第二年，因为处在灾后重建当中，所以任务依然很多，这一年里在专业知识方面有了很大的提高，但依然问题层出不穷，归根揭底是因为对各种规范不熟悉，常出现与规范不符的现象。当时最突出的问题就是基础埋深超深，在这个问题上公司可以说是费尽心力，因为自己的一时疏忽，给公司带来太多麻烦，而最后公司用一颗包容的心来承担这一切，在这里再次感谢公司及公司的领导们。经过超深事件后，大家都深刻地意识到：设计必须严谨，必须认真对待，必须尽最大努力来完成任何一项设计，任何一个小小的疏漏都可能把我们推向深渊。在工地现场方面，经过第一年的积累，对于比较常见的问题基本上能够解决，但实际工程则是复杂的，基本上不同的工地都会出现不同的问题，而这些问题更是变化莫测的。遇到这种情况后，就将不能现场立即解答的问题带回公司，向经验丰富的工程师们请教，最

数据库设计心得体会(精选多篇)

数据库设计心得体会(精选多篇) 跟老板做了两个算是比较大的项目，数据库主体都是我设计的。第一个感觉很失败；第二个现在正在用，虽然总结了第一个的教训，但感觉还是有些遗憾。把这过程中的一些心得记在这里，以便日后用到时来查阅。若以后还有机会再设计数据库——现在倒还有些期待，呵呵，再有新的体会，也全部补充到这里。 1.尽量使用数据冗余。 随着磁盘容量的大幅飙升，这一点已经不会产生什么问题。当然冗余归冗余，不能把数据的关联弄的乱七八糟的。 本科数据库课程中学的知识直接拿来，在实际中会出大问题。满足三级范式的数据库结构会让你面对大量的连表查询，应用程序中会用到大量的数据库访问，既繁琐（烦死你）又使程序运行速度减慢。 2.尽量不要使用varchar(max)类型 这一点主要是用动软代码生成器自动生成代码时，如果varchar 的最大长度指定为max，在自动生成代码时，它无法生成这一最大长度，需要手动补进去。 现在感觉用个varchar(1000)就够了。 3.使用预留字段。 数据库表（尤其是动态表格），在你把所有字段都设计好了之后，再添加几个备注字段和预留字段。 之前我觉得这样做没多大意义，因为预留字段的列名是没有实际意义的。这样程序中使用的时候就会让人费解。但现在觉得还是有必

要的，很有必要的，即便在用到时需要自己十分清楚之前预留的无意义字段现在表示什么意义。不过我的第二个数据库中还是没采用，这也是遗憾之处啊。 个人感觉用note1、note2、r1（r表示reserve）、r2、r3，2个备注字段和3个预留字段就足够了,再多的话就不容易记住哪个字段具体表示什么意义了，容易晕。类型就都用varchar(200)吧。 数据库设计心得体会（2）： 在我看来，数据库课程设计主要的目标是利用课程中学到的数据库知识和技术较好的开发设计出数据库应用系统，去解决各行各业化处理的要求。通过这次的课程设计，可以巩固我们对数据库基本原理和基础理论的理解，掌握数据库应用系统设计开发的基本方法，进一步提高我们综合运用所学知识的能力。 当我们这组决定做大学生就业咨询系统时，我们并没有着手写程序。而是大家一起商量这个系统概述、系统目标、系统需求、业务流程分析、数据流程分析和数据词典。当这些都准备好了之后，我们进行模块的分工。每个人都有自己的模块设计，而且写出来的代码要求可以实现相应模块的功能，得到理想的效果。当每个人都把自己的分工做好了，最后会由一个人把这些全部组合搭建在一起。我们使用的是html和php相互嵌套使用，当一个系统做好了之后，我会好好地把程序都看一遍，理会其中的奥秘。 我所负责的是数据库的备份和还原还有一些界面的实现。还记得自己刚接触html的时候，觉得很感兴趣，所以有一段时间几乎到了

学习数据库的心得

学习数据库的心得各位读友大家好，此文档由网络收集而来，欢迎您下载，谢谢 篇一：SQL学习心得 SQL数据库学习心得 经过一个学期的数据库课程的学习，我基本上掌握了创建数据库以及对数据库的操作的基础知识。学习了SQL 数据库中的增、删、改、查等功能，数据库这门课涉及到以前的知识不多，是一门从头学起的课程，即使基础不是很好，只要认真听讲、复习功课，还是一门比较容易掌握的课。 正是由于这门课和以前关系不大，很多知识也从未接触过，因此对于这门课的学习方法就是：理论课上认真听老师讲理论知识，上机课上仔细看老师的演示过程、在电脑上按照老师的演示步骤自己做，遇到自己无法做出来的过程（步骤）请教老师或者同学。 在第一章基础篇里：开篇任务一是

对通讯录程序的主要功能做一个简单的介绍，并根据这些功能使用SQL Server2005设计了对应的数据库AddressList及数据表，并建立数据表之间的关系；了解了通讯录程序数据库AddressList包含的三个表以及表的相关属性。由于我在本学期初参加数学建模竞赛，耽误了几节课程，导致任务一的内容不会做。而C#数据库中的内容一环扣一环，后面的任务往往是在前面的任务基础上做的，所以一步跟不上，步步跟不上。在老师讲后面的任务时而我前面的任务既不太会做，又没有做完，导致在学习上很吃力。之后的任务都是在任务一的基础上的延伸，学习数据库的编写、功能等。在学习数据库和数据表创建和修改时，了解到表是建立关系数据库的基本结构，用来存储数据具有已定义的属性，在表的操作过程中，有查看表信息、查看表属性、修改表中的数据、删除表中 的数据及修改表和删除表的操作。

【结构设计】结构工程师十年设计经验总结

结构工程师十年设计经验总结 1关于箱、筏基础底板挑板的阳角问题： (1)阳角面积在整个基础底面积中所占比例极小,干脆砍了.可砍成直角或斜角. (2)如果底板钢筋双向双排,且在悬挑部分不变,阳角不必加辐射筋,谁见过独立基础加辐射筋的？当然加了也无坏处. (3)如果甲方及老板不是太可恶的话,可将悬挑板的单向板的分布钢筋改为直径12的,别小看这一改,一个工程省个3、2万不成问题. 2关于箱、筏基础底板的挑板问题： 1)从结构角度来讲,如果能出挑板,能调匀边跨底板钢筋,特别是当底板钢筋通长布置时,不会因边跨钢筋而加大整个底板的通长筋,较节约. (2)出挑板后,能降低基底附加应力,当基础形式处在天然地基和其他人工地基的坎上时,加挑板就可能采用天然地基.必要时可加较大跨 度的周圈窗井. (3)能降低整体沉降,当荷载偏心时,在特定部位设挑板,还可调整沉降差和整体倾斜. (4)窗井部位可以认为是挑板上砌墙,不宜再出长挑板.虽然在计算时此处板并不应按挑板计算.当然此问题并不绝对,当有数层地下室,窗井横隔墙较密,且横隔墙能与内部墙体连通时,可灵活考虑.

(5)当地下水位很高,出基础挑板,有利于解决抗浮问题. (6)从建筑角度讲,取消挑板,可方便柔性防水做法.当为多层建筑时,结构也可谦让一下建筑. 3关于箍筋在梁配筋中的比例问题(约10~20%)： 例如一8米跨梁,截面为400X600,配筋：上6根25,截断1/3,下5根25,箍筋范围内加密.纵筋总量：385*9*8=281kg,箍筋： 0395*35*50=69,箍筋/纵筋=1/4,如果双肢箍仅为1/8,箍筋相对纵筋来讲所占比例较小,故不必在箍筋上抠门.且不说要强剪弱弯.已经是构造配箍除外. 4关于梁、板的计算跨度： 一般的手册或教科书上所讲的计算跨度,如净跨的11倍等,这些规定和概念仅适用于常规的结构设计,在应用日广的宽扁梁中是不合适的.梁板结构,简单点讲,可认为是在梁的中心线上有一刚性支座,取消梁的概念,将梁板统一认为是一变截面板.在扁梁结构中,梁高比板厚大不了多少时,应将计算长度取至梁中心,选梁中心处的弯距和梁厚,及梁边弯距和板厚配筋,取二者大值配筋.（借用台阶式独立基础变截面处的概念）柱子也可认为是超大截面梁,所以梁配筋时应取柱边弯距.削峰是正常的,不削峰才有问题. 5纵筋搭接长度为若干倍钢筋直径d,一般情况下,d取钢筋直径的较小值,这是有个前提,即大直径钢筋强度并未充分利用.否则应取钢筋直径的较大值.如框架结构顶层的柱子纵筋有时比下层大,d应取较大的钢筋直径,甚至纵筋应向下延伸一层.其实,两根钢筋放一起,用铁丝捆

数据库设计实践总结

数据库设计实践总结 数据库设计的优劣和体现性能的高低对整个系统软件的生命周期长短具有重要的影响意义，其中辅助数据库设计程序是软件开发和应用最有效的辅助设计工具。以下是的数据库设计实践总结，欢迎阅读。 1.尽量使用数据冗余。 随着磁盘容量的大幅飙升，这一点已经不会产生什么问题。当然冗余归冗余，不能把数据的关联弄的乱七八糟的。 本科数据库课程中学的知识直接拿来，在实际中会出大问题。满足三级范式的数据库结构会让你面对大量的连表查询，应用程序中会用到大量的数据库访问，既繁琐(烦死你)又使程序运行速度减慢。 2.尽量不要使用varmax)类型 这一点主要是用动软代码生成器自动生成代码时，如果varchar 的最大长度指定为max，在自动生成代码时，它无法生成这一最大长度，需要手动补进去。 现在感觉用个var1000)就够了。 3.使用预留字段。 数据库表(尤其是动态表格)，在你把所有字段都设计好了之后，再添加几个备注字段和预留字段。 之前我觉得这样做没多大意义，因为预留字段的列名是没有实际意义的。这样程序中使用的时候就会让人费解。但现在觉得还是有必要的，很有必要的，即便在用到时需要自己十分清楚之前预留的无

意义字段现在表示什么意义。不过我的第二个数据库中还是没采用，这也是遗憾之处埃 个人感觉用note1、note2、r1(r表示reserve)、r2、r3，2个备注字段和3个预留字段就足够了,再多的话就不容易记住哪个字段 具体表示什么意义了，容易晕。类型就都用var200)吧。 在我看来，数据库课程设计主要的目标是利用课程中学到的数 据库知识和技术较好的开发设计出数据库应用系统，去解决各行各业信息化处理的要求。通过这次的课程设计，可以巩固我们对数据库基本原理和基础理论的理解，掌握数据库应用系统设计开发的基本方法，进一步提高我们综合运用所学知识的能力。 当我们这组决定做大学生就业咨询系统时，我们并没有着手写 程序。而是大家一起商量这个系统概述、系统目标、系统需求、业务流程分析、数据流程分析和数据词典。当这些都准备好了之后，我们进行模块的分工。每个人都有自己的模块设计，而且写出来的代码要求可以实现相应模块的功能，得到理想的效果。当每个人都把自己的分工做好了，最后会由一个人把这些全部组合搭建在一起。我们使用的是html和php相互嵌套使用，当一个系统做好了之后，我会好好 地把程序都看一遍，理会其中的奥秘。 我所负责的是数据库的备份和还原还有一些界面的实现。还记 得自己刚接触html的时候，觉得很感兴趣，所以有一段时间几乎到 了痴迷的程度。然而php是我刚接触不久的一种编程语言。不过觉得它的功能真的很强大，可以开发出很多大型的系统。但是在做备份和

《钢结构设计规范》2017最新版对抗震更高要求

两章，“构造要求（原第 8 章）” 中与柱设计相关的内容移入 钢结构设计规范》 2017 最新版— —对抗震更高要求 导读】 目前市面上通用最基础的钢结构设计规范是 GB50017-2003 ， 随着科技的进步，各种计算软件的更新及近年来频发的自然 灾害，尤其是自汶川地震以来，对建筑防灾减灾，尤其是抗 震有更高的要求，基于重重原因，新版《钢结构设计规范》 的修订出台是设计师一直很期待的。 12017 最新版《钢结构 设计规范》主要修订内容如下： 01 术语和符号（第 2 章） 删除了原规范中关于强度的术语 ,增加了本次规范新增内容 的术语。 02 基本设计规定（第 3 章）增加了“结构体系”和“截面板件 宽厚比等级”；“材料选用”及“设计指标”内容移入新章节“材料 第 4 章）”；关于结构计算内容移入新章节“结构分析及稳 定性设计（第 5 章）”；“构造要求（原第8 章）” 输及安装的原则性规定并入本章。 03 受弯构件的计算 （原第 4 章）改为“受弯构件（第 6 章）” 移入本章。 04 轴心受力构件和拉弯、压弯构件的计算（原第 5 章）改 为“轴心受力构件（第 7 章）”及“拉弯、压弯构件（第 8 章）” 中制作、运 增加了腹板开孔的内容，“构造要求” 中与梁设计相关的内容

第7 章。 05 疲劳计算（原第6 章）改为“疲劳计算及防脆断设计（第 16 章）”增加了简便快速验算疲劳强度的方法，“构造要求（原第8 章）”中“提高寒冷地区结构抗脆断能力的要求”移入本章，并增加了抗脆断设计的补充规定。 06 连接计算（原第7章）改为“连接（第11章）”及“节（点第

结构设计总结

十年结构设计经验的总结 1.关于箱、筏基础底板挑板的阳角问题： (1).阳角面积在整个基础底面积中所占比例极小，干脆砍了。可砍成直角或斜角。 (2).如果底板钢筋双向双排，且在悬挑部分不变，阳角不必加辐射筋，谁见过独立基础加辐射筋的？当然加了也无坏处。 (3).如果甲方及老板不是太可恶的话，可将悬挑板的单向板的分布钢筋改为直径12的，别小看这一改，一个工程省个3、2万不成问题。 2.关于箱、筏基础底板的挑板问题： 1).从结构角度来讲，如果能出挑板，能调匀边跨底板钢筋，特别是当底板钢筋通长布置时，不会因边跨钢筋而加大整个底板的通长筋，较节约。 (2).出挑板后，能降低基底附加应力，当基础形式处在天然地基和其他人工地基的坎上时，加挑板就可能采用天然地基。必要时可加较大跨度的周圈窗井。 (3).能降低整体沉降，当荷载偏心时，在特定部位设挑板，还可调整沉降差和整体倾斜。 (4).窗井部位可以认为是挑板上砌墙，不宜再出长挑板。虽然在计算时此处板并不应按挑板计算。当然此问题并不绝对，当有数层地下室，窗井横隔墙较密，且横隔墙能与内部墙体连通时，可灵活考虑。 (5).当地下水位很高，出基础挑板，有利于解决抗浮问题。 (6).从建筑角度讲，取消挑板，可方便柔性防水做法。当为多层建筑时，结构也可谦让一下建筑。 3.关于箍筋在梁配筋中的比例问题(约10~20%)： 例如一8米跨梁，截面为400X600，配筋：上6根25，截断1/3，下5根25，箍筋：8@100/200(4),1000范围内加密。纵筋总量：3.85*9*8=281kg,箍筋：0.395*3.5*50=69,箍筋/纵筋=1/4, 如果双肢箍仅为1/8，箍筋相对纵筋来讲所占比例较小，故不必在箍筋上抠门。且不说要强剪弱弯。已经是构造配箍除外 4.关于梁、板的计算跨度： 一般的手册或教科书上所讲的计算跨度，如净跨的1.1倍等，这些规定和概念仅适用于常规的结构设计，在应用日广的宽扁梁中是不合适的。梁板结构，简单点讲，可认为是在梁的中心线上有一刚性支座，取消梁的概念，将梁板统一认为是一变截面板。在扁梁结构中，梁高比板厚大不了多少时，应将计算长度取至梁中心，选梁中心处的弯距和梁厚，及梁边弯距和板厚配筋，取二者大值配筋。（借用台阶式独立基础变截面处的概念）柱子也可认为是超大截面梁，所以梁配筋时应取柱边弯距。削峰是正常的，不削峰才有问题。 5.纵筋搭接长度为若干倍钢筋直径d，一般情况下，d取钢筋直径的较小值， 这是有个前提，即大直径钢筋强度并未充分利用。否则应取钢筋直径的较大值。如框架结构顶层的柱子纵筋有时比下层大，d应取较大的钢筋直径，甚至纵筋应向下延伸一层。其实，两根钢筋放一起，用铁丝捆一下，能起多大用，还消弱了钢筋与混凝土的握裹力。所以，钢筋如有可能尽量采用机械连接或焊接。

数据库课程设计的个人总结

数据库课程设计的个人总结 在开学的第一周，我参加了院里组织的数据库课程设计，这项任务是分组分工完成的，我们组有五名成员，分别是我们班学号的后五位同学，很荣幸地我被推荐为我们组的组长，在组长的“英明”指导下，全体组员团结奋斗，使得任务完成地比我们预期的要稍早一些，也比预期要漂亮一些，这一点我们都感到很高兴也很自豪。 王婆卖瓜时间过了，言归正传吧。凡是都要有个总结，以下便是我在这个课程设计中的一点心得。 首先我分析一下我们组任务顺利完成的成功之处并总结一些经验，供以后反省参考用。 凡事预则备，不预则废。这是我的座右铭，也是我深有感悟的几句古语之一。在这个项目的开始阶段，老师便让我们做了个进度安排表，我很好的利用了这次机会，花了较多心思作出了一个很详细的进度安排表，之后我们组任务的完成也是严格按照这个进度表进行的。当然我后来去了解了一下别的组的情况，有些组的进度安排表没我们组做完善的一个很重要的原因就是他们对这一周的数据库课程设计到底还没什么概念。导致这种现象的原因有很多方面，一个是基础太差不能理解老师安排的任务（当然这种人比较少），一种是缺乏交流，这个交流包括组内的交流，也包括组间的，更包括与老师之间的，这也就引出了我的第二个心得。

多交流，这是我这次项目的第二个心得。对于这种分工完成的项目，组员之间的交流是极其必要的。如果组员之间不能很好的沟通，不仅会做很多无用功，而且也会做很多重复的工作。组员之间很好点，我们每天都会在qq上或者见面相互交流，并及时修改进度安排表；除此之外，我们还相互帮助解决问题，或者共同解决问题，比如说这次的概念模型的设计，我们组负责设计概念数据模型的同学（赵##）和负责数据需求分析的同学（左##）就经常沟通（因为两者的任务联系比较紧密），共同解决问题，才会做出令我们组员都比较满意的数据概念模型和漂亮的数据需求分析文档；当然最重要的是我们也常会去与老师沟通，老师也在关键的设计地方也给了很多很多的宝贵意见。当然不得不作出检讨的地方是组长这次与老师交流的比较少，反而不及组员，希望在接下来的项目中能有所改观，起好带头作用。我同样也有观察别的组完成情况，发现有些组出现了组长包干或者组长与个别组员的包干的现象，我觉得导致出现这种可怕现象的主要责任在于组长，组长的任务不仅仅参与部分任务的完成，更重要的是分配任务并协调组间关系，是沟通交流的一根主要管道。通俗的讲就是组长上要联系老师，中要与他组交流，下要与组员积极沟通，我觉得这也是组长这个角色的设置的必要所在吧。我真心地希望在我们下一个创新课程j2ee的训练中我们班不要再出现这种现象，每个人都有平等得到锻

关系数据库设计

目录 一 Codd的RDBMS12法则——RDBMS的起源 二关系型数据库设计阶段 三设计原则 四命名规则 数据库设计，一个软件项目成功的基石。很多从业人员都认为，数据库设计其实不那么重要。现实中的情景也相当雷同，开发人员的数量是数据库设计人员的数倍。多数人使用数据库中的一部分，所以也会把数据库设计想的如此简单。其实不然，数据库设计也是门学问。 从笔者的经历看来，笔者更赞成在项目早期由开发者进行数据库设计（后期调优需要DBA）。根据笔者的项目经验，一个精通OOP和ORM的开发者，设计的数据库往往更为合理，更能适应需求的变化，如果追其原因，笔者个人猜测是因为数据库的规范化，与OO的部分思想雷同（如内聚）。而DBA，设计的数据库的优势是能将DBMS的能力发挥到极致，能够使用SQL和DBMS实现很多程序实现的逻辑，与开发者相比，DBA优化过的数据库更为高效和稳定。如标题所示，本文旨在分享一名开发者的数据库设计经验，并不涉及复杂的SQL语句或DBMS使用，因此也不会局限到某种DBMS产品上。真切地希望这篇文章对开发者能有所帮助，也希望读者能帮助笔者查漏补缺。 一?Codd的RDBMS12法则——RDBMS的起源 Edgar Frank Codd（埃德加·弗兰克·科德）被誉为“关系数据库之父”，并因为在数据库管理系统的理论和实践方面的杰出贡献于1981年获图灵奖。在1985年，Codd 博士发布了12条规则，这些规则简明的定义出一个关系型数据库的理念，它们被作为所有关系数据库系统的设计指导性方针。 1.信息法则?关系数据库中的所有信息都用唯一的一种方式表示——表中的值。 2.保证访问法则?依靠表名、主键值和列名的组合，保证能访问每个数据项。 3.空值的系统化处理?支持空值（NULL），以系统化的方式处理空值，空值不依赖于数据类型。 4.基于关系模型的动态联机目录?数据库的描述应该是自描述的，在逻辑级别上和普通数据采用同样 的表示方式，即数据库必须含有描述该数据库结构的系统表或者数据库描述信息应该包含在用 户可以访问的表中。 5.统一的数据子语言法则?一个关系数据库系统可以支持几种语言和多种终端使用方式，但必须至少 有一种语言，它的语句能够一某种定义良好的语法表示为字符串，并能全面地支持以下所有规 则：数据定义、视图定义、数据操作、约束、授权以及事务。（这种语言就是SQL) 6.视图更新法则?所有理论上可以更新的视图也可以由系统更新。 7.高级的插入、更新和删除操作?把一个基础关系或派生关系作为单个操作对象处理的能力不仅适应 于数据的检索，还适用于数据的插入、修改个删除，即在插入、修改和删除操作中数据行被视 作集合。 8.数据的物理独立性?不管数据库的数据在存储表示或访问方式上怎么变化，应用程序和终端活动都 保持着逻辑上的不变性。 9.数据的逻辑独立性?当对表做了理论上不会损害信息的改变时，应用程序和终端活动都会保持逻辑 上的不变性。 10.数据完整性的独立性?专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定 义，而且可以存储在数据目录中，而非程序中。

结构设计经验总结

YJK弹性板参数说明 弹性板荷载计算方式： 有限元方式仅适用于定义为弹性板3或者弹性板6的楼板，不适合弹性膜或者刚性板的计算。 梁板变形协调： 对于弹性膜，一般可设置为不勾选此项。但是对于弹性板3或者弹性板6，则应勾选此项。因为设置弹性板3或弹性板6的目的是使梁与板共同工作，发挥板的面外刚度的作用，减少梁的受力和配筋，此时必须使弹性板中间节点和梁的中间节点变形协调才能实现这种作用。 考虑相对偏移（次梁点铰后负弯矩的由来）： 以前弹性板与梁变形协调时，计算模型是以梁的中和轴和板的中和轴相连的方式计算的，由于一般梁与楼板在梁顶部平齐，实际上梁的中和轴和板中和轴存在竖向的偏差，勾选此参数后软件将在计算中考虑到这种实际的偏差，将在板和梁之间设置一个竖向的偏心刚域，该偏心刚域的长度就是梁的中和轴和板中和轴的实际距离。在生成数据后的计算简图中可以看到用粉色表示的弹性板和梁之间的竖向短线，就是它们之间的偏心刚域。这种计算模型比按照中和轴互相连接的模型得出的梁的负弯矩更小，跨中承受一定的拉力，这些因素在梁的配筋计算中都会考虑。 地震内力按弹性板6计算： 用户对恒活风等荷载工况计算时，对楼板习惯于按照刚性板、弹性膜的模型计算，这种模型不考虑楼板的抗弯承载能力，由梁承担全部荷载内力，此时的楼板成为一种承载力的安全储备。但是从抗震设计强柱弱梁的要求考虑，常造成梁的配筋过大的不好的效果。 勾选此参数则软件仅对地震作用的内力按照全楼弹性板6计算，这样地震计算时让楼板和梁共同抵抗地震作用，可以大座弯矩，从而可明显降低梁的支幅度降低地震作用下梁的支座部分的用钢量。 由于对其他荷载工况仍按照以前习惯的设置，保持恒活风等其他荷载工况的计算结果不变，这样做既没有降低结构的安全储备，又实现了强柱弱梁、减少梁的钢筋用量的效果。