MYSQL编程：数据库计划指南（转）

怀疑这些功能在MySQL5.0中的成熟性。充其量它们在MySQL中被支持的时间也就一年左右，而在MySQL学习教程其他关系型数据库中则已经存在了近10年的时间。计划|数据|数据库|数据库计划假如把企业的数据比做性命所必须的血液，那末数据库的计划就是使用中最主要的一部分。有关数据库计划的质料汗牛充栋，年夜学学位课程里也有专门的报告。不外，就如我们重复夸大的那样，再好的先生也比不外履历的教导。以是经由过程对数据库计划很有成就的专业人士的反应精选，暨以给人人教授一些计划数据库的技能和履历。

第1部分—计划数据库之前

这一部分排列了12个基础技能，包含定名标准和明白营业需求等。

1.考查现有情况

在计划一个新数据库时，你不仅应当细心研讨营业需求并且还要考查现有的体系。年夜多半数据库

项目都不是重新入手下手创建的；一般，机构内总会存在用来满意特定需求的现有体系（大概没有实

现主动盘算）。明显，现有体系其实不完善，不然你就不用再创建新体系了。可是对旧体系的研讨

可让你发明一些大概会疏忽的渺小成绩。一样平常来讲，考查现有体系对你相对有优点。
—LamontAdams

我已经接办过一个为区域运输公司开辟的数据库项目，活不难，用的是Access数据库。我设置

了一些项目计划参数，并且同客户一道对这些参数举行了评价，事前还检察了开辟情况下所接纳

的事情形式，比及最初部署使用的时分，只见终端上出了几个提醒符然后立马在我眼前翘辫子

了！抓耳挠腮的折腾了好几个小时，我才意想到，本来这家公司的收集上跑着两个数据库使用，

而对收集的会见必要明白和严厉的用户帐号及其会见权限。分明了这一点，成绩水到渠成：只需

接纳客户的体系便可。这个项目给我的教导就是：记着，假设你在诸如Access大概Interbase这

类大众情况下开辟使用程序，必定要从外表动手深切体系外部弄分明你面对的情况究竟是怎样回

事。

—kg


2.界说尺度的工具定名标准

必定要界说数据库工具的定名标准。对数据库表来讲，从项目一入手下手就要断定表名是接纳单数还

是双数情势。别的还要给表的别号界说复杂划定规矩（例如说，假如表名是一个单词，别号就取单词

的前4个字母；假如表名是两个单词，就各取两个单词的前两个字母构成4个字母长的别号；如

果表的名字由3个单词构成，你无妨重新两个单词中各取一个然后从最初一个单词中再掏出两个

字母，了局仍是构成4字母长的别号，其他顺次类推）对事情用表来讲，表名能够加上前缀

WORK_前面附上接纳该表的使用程序的名字。表内的列要针对键接纳一整套计划划定规矩。好比，

假如键是数字范例，你能够用_NO作为后缀；假如是字符范例则能够接纳_CODE后缀。对列名

应当接纳尺度的前缀和后缀。再如，假设你的内外有很多多少“money”字段，你无妨给每一个列增添

一个_AMT后缀。另有，日期列最好以DATE_作为名字打头。

—richard

反省表名、报表名和查询名之间的定名标准。你大概会很快就被这些分歧的数据库要素的称号弄

懵懂了。假设你保持一致地定名这些数据库的分歧构成部分，最少你应当在这些工具名字的开首

用table、query大概report等前缀加以区分。

—rrydenm

假如接纳了MicrosoftAccess，你能够用qry、rpt、tbl和mod等标记来标识工具（好比

tbl_Employees）。我在和SQLServer（大概Oracle）打交道的时分还用过tbl来索引表，但我

用sp_company（如今用sp_feft_）标识存储历程，由于在有的时分假如我发明了更好的处置办

法常常会保留好几个拷贝。我在完成SQLServer2000时用udf_（大概相似的标志）标识我编

写的函数。

—TimothyJ.Bruce




3.事后企图
上个世纪80年月初，我还在利用资产帐目体系和System38平台，当时我卖力计划一切的日期
字段，如许在不费甚么力量的情形下未来就能够轻松处置2000年成绩了。很多人给我说就别往

办理这一成绩了，由于要处置起来太贫苦了（这活着人皆知的Y2K成绩之前好久了）。我反击说

只需事后企图从此就不会碰到年夜贫苦。了局我只用了两周的工夫就把程序全体改完了。由于事后

企图的好，厥后Y2K成绩对该体系的伤害降到了最低水平（比来传闻该程序乃至到了1995年都

还运转在AS/400体系上，独一呈现的小成绩是从代码中删除正文费了点光阴）。

—generalist


4.猎取数据形式资本手册

正在追求示例形式的人能够浏览《数据形式资本手册》一书，该书由LenSilverston、W.H.

Inmon和KentGraziano编写，是一本值得具有的最好数据建模图书。该书包含的章节涵盖多种

数据范畴，好比职员、机构和事情效能等。

—minstrelmike


5.憧憬将来，但不成忘了已往的教导

我发明扣问用户怎样对待将来需求变更十分有效。如许做能够到达两个目标：起首，你能够分明

地懂得使用计划在哪一个中央应当更具天真性和怎样制止功能瓶颈；其次，你晓得产生事前没有

断定的需求变动时用户将和你一样感应受惊。

—chrisdk

必定要记着已往的履历教导！我们开辟职员还应当经由过程分享本人的体味和履历相互匡助。即便用

户以为他们不再必要甚么撑持了，我们也应当对他们举行这方面的教导，我们都已经面对过这

样的时候“现在如果这么做了该多好??”。

—dhattrem



6.在物理理论之行进行逻辑计划

在深切物理计划之前要先辈行逻辑计划。跟着大批的CASE工具不休出现出来，你的计划也能够

到达相称高的逻辑水准，你一般能够从全体上更好地懂得数据库计划所必要的各个方面。

—chardove



7.懂得你的营业

在你百分百地断定体系从客户角度满意其需求之前不要在你的ER（实体干系）形式中到场哪怕

一个数据表（怎样，你还没有形式？那请你参看技能9）。懂得你的企业营业能够在今后的开辟

阶段勤俭大批的工夫。一旦你明白了营业需求，你就能够本人做出很多决议了。

—rangel

一旦你以为你已明白了营业内容，你最好同客户举行一次体系的交换。接纳客户的术语而且向

他们注释你所想到的和你所听到的。同时还应当用大概、将会和必需等辞汇表达出体系的干系基

数。如许你就能够让你的客户改正你本人的了解然后做好下一步的ER计划。

—teburlew




8.创立数据字典和ER图表
必定要花点工夫创立ER图表和数据字典。个中最少应当包括每一个字段的数据范例和在每一个表内
的主外键。创立ER图表和数据字典的确有点费时但对其他开辟职员要懂得全部计划倒是完整必

要的。越早创立越能有助于制止从此面对的大概凌乱，从而可让任何懂得数据库的人都明白如

何从数据库中取得数据。

—bgumbert

有一份诸如ER图表等最新文档其主要性怎样夸大都不外分，这对标明表之间干系很有效，而数

据字典则申明了每一个字段的用处和任何大概存在的别号。对SQL表达式的文档化来讲这是完

全需要的。

—vanduin.chris.cj



9.创立形式

一张图表赛过千言万语：开辟职员不但要浏览和完成它，并且还要用它来匡助本人和用户对话。

形式有助于进步合作效能，如许在先期的数据库计划中几近不成能呈现年夜的成绩。形式不用弄的

很庞大；乃至能够复杂得手写在一张纸上就能够了。只是要包管其上的逻辑干系从此能发生效

益。

—DanaDaigle



10.从输出输入动手

在界说数据库表和字段需求（输出）时，起首应反省现有的大概已计划出的报表、查询和视图

（输入）以决意为了撑持这些输入哪些是需要的表和字段。举个复杂的例子：假设客户必要一个

报表依照邮政编码排序、分段和乞降，你要包管个中包含了独自的邮政编码字段而不要把邮政编

码糅进地点字段里。

—peter.marshall



11.报表技能

要懂得用户一般是怎样呈报数据的：批处置仍是在线提交报表？工夫距离是天天、每周、每个月、

每一个季度仍是每一年？假如必要的话还能够思索创立总结表。体系天生的主键在报表中很难办理。

用户在具有体系天生主键的表内用副键举行检索常常会前往很多反复数据。如许的检干脆能对照

低并且简单引发凌乱。

—kol



12.了解客户需求

看起来这应当是不言而喻的事，但需求就是来自客户（这里要从外部和内部客户的角度思索）。

不要依附用户写上去的需求，真实的需求在客户的脑壳里。你要让客户注释其需求，并且跟着开

发的持续，还要常常扣问客户包管其需求仍旧在开辟的目标当中。一个稳定的真谛是：“只要我

瞥见了我才晓得我想要的是甚么”一定会招致大批的返工，由于数据库没有到达客户历来没有写

上去的需求尺度。而更糟的是你对他们需求的注释只属于你本人，并且多是完整毛病的。
—kgilson

第2部分—计划数据库表
统共24个指南性技能，涵盖表内字段计划和应当制止的罕见成绩等。



1.反省各类变更

我在计划数据库的时分会思索到哪些数据字段未来大概会产生变动。例如说，姓氏就是云云（注

意是东方人的姓氏，好比女性娶亲后从夫姓等）。以是，在创建体系存储客户信息时，我偏向于

在独自的一个数据内外存储姓氏字段，并且还附加肇端日和停止日等字段，如许就能够跟踪这一

数据条目标变更。

—ShropshireLad



2.接纳成心义的字段名

有一回我列入开辟过一个项目，个中有从其他程序员那边承继的程序，谁人程序员喜好用屏幕上

显现数据唆使用语定名字段，这也不赖，但不幸的是，她还喜好用一些奇异的定名法，其定名采

用了匈牙利定名和把持序号的组合情势，好比cbo1、txt2、txt2_b等等。

除非你在利用只面向你的缩写字段名的体系，不然请尽量地把字段形貌的分明些。固然，也别

做过火了，好比Customer_Shipping_Address_Street_Line_1I固然很富有申明性，但没人乐意

键进这么长的名字，详细标准就在你的掌控中。

—LamontAdams



3.接纳前缀定名

假如多个内外有很多多少统一范例的字段（好比FirstName），你无妨用特定表的前缀（好比

CusLastName）来匡助你标识字段。

—notoriousDOG



4.时效性数据
时效性数据应包含“比来更新日期/工夫”字段。工夫标志对查找数据成绩的缘故原由、按日期从头处

理/重载数据和扫除旧数据出格有效。

—kol



5.尺度化和数据驱动

数据的尺度化不但便利了本人并且也便利了其别人。例如说，假设你的用户界面要会见内部数据

源（文件、XML文档、其他数据库等），你无妨把响应的毗连和路径信息存储在用户界面撑持表

里。另有，假如用户界面实行事情流之类的义务（发送邮件、打印信笺、修正纪录形态等），那

么发生事情流的数据也能够寄存在数据库里。事后布置总必要支付勉力，但假如这些历程接纳数

据驱动而非硬编码的体例，那末战略变动和保护城市便利很多。现实上，假如历程是数据驱动

的，你就能够把相称年夜的义务推给用户，由用户来保护本人的事情流历程。

—tduvall



6.尺度化不克不及过火

对那些不熟习尺度化一词（normalization）的人而言，尺度化能够包管表内的字段都是最基本的

要素，而这一措施有助于打消数据库中的数据冗余。尺度化有好几种情势，但ThirdNormal

Form（3NF）一般被以为在功能、扩大性和数据完全性方面到达了最好均衡。复杂来讲，3NF规

定：



·表内的每个值都只能被表达一次。
·表内的每行都应当被独一的标识（有独一键）。
·表内不该该存储依附于其他键的非键信息。

恪守3NF尺度的数据库具有以下特性：有一组表专门寄存经由过程键毗连起来的联系关系数据。例如说，

某个寄存客户及其有关订单的3NF数据库便可能有两个表：Customer和Order。Order表不包

含订单联系关系客户的任何信息，但表内会寄存一个键值，该键指向Customer内外包括该客户信息

的那一行。

更高条理的尺度化也有，但更尺度是不是就必定更好呢？谜底是纷歧定。现实上，对某些项目来

说，乃至就连3NF都大概给数据库引进太高的庞大性。

—LamontAdams



为了效力的原因，对表不举行尺度化偶然也是需要的，如许的例子良多。已经有个开辟财政剖析

软件的活就是用非尺度化表把查询工夫从均匀40秒下降到了两秒摆布。固然我不能不这么做，

但我毫不把数据表的非尺度化看成固然的计划理念。而详细的操纵不外是一种派生。以是假如表

出了成绩从头发生非尺度化的表是完整大概的。

—epepke


7.MicrosoftAccess报表技能

假如你正在利用MicrosoftAccess，你能够用对用户友爱的字段名来取代编号的称号：好比用

CustomerName取代txtCNaM。如许，当你用导游程序创立表单和报表时，其名字会让那些不

是程序员的人更简单浏览。

—jwoodruf


8.不活泼大概不接纳的唆使符

增添一个字段暗示地点纪录是不是在营业中不再活泼挺有效的。不论是客户、员工仍是其他甚么

人，如许做都能有助于再运转查询的时分过滤活泼大概不活泼形态。同时还打消了新用户在接纳

数据时所面对的一些成绩，好比，某些纪录大概不再为他们所用，再删除的时分能够起到必定的

提防感化。

—theoden



9.利用脚色实体界说属于某种别的列

在必要对属于特定种别大概具有特定脚色的事物做界说时，能够用脚色实体来创立特定的工夫关

联干系，从而能够完成自我文档化。

这里的寄义不是让PERSON实体带有Title字段，而是说，为何不必PERSON实体和

PERSON_TYPE实体来形貌职员呢？然后，例如说，当JohnSmith,Engineer提拔为John

Smith,Director以致最初爬到JohnSmith,CIO的高位，而一切你要做的不外是改动两个表

PERSON和PERSON_TYPE之间干系的键值，同时增添一个日期/工夫字段来晓得变更是什么时候

产生的。如许，你的PERSON_TYPE表就包括了一切PERSON的大概范例，好比Associate、

Engineer、Director、CIO大概CEO等。

另有个替换举措就是改动PERSON纪录来反应新头衔的变更，不外如许一来在工夫上没法跟踪

团体所处地位的详细工夫。
—teburlew



10.接纳经常使用实体定名机构数据

构造数据的最复杂举措就是接纳经常使用名字，好比：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等。

接纳一样平常笼统术语来标识“事物”的种别可让你在联系关系数据以满意营业请求方面取得伟大的灵

活性，同时如许做还能够明显下降数据存储所需的冗余量。

—teburlew



11.用户来自天下各地

在计划用到收集大概具有其他国际特征的数据库时，必定要记着年夜多半国度都有分歧的字段格

式，好比邮政编码等，有些国度，好比新西兰就没有邮政编码一说。

—billh



12.数据反复必要接纳分立的数据表

假如你发明本人在反复输出数据，请创立新表和新的干系。

—AlanRash



13.每一个表中都应当增加的3个有效的字段

·dRecordCreationDate，在VB下默许是Now()，而在SQLServer下默许为GETDATE()

·sRecordCreator，在SQLServer下默许为NOTNULLDEFAULTUSER

·nRecordVersion，纪录的版本标志；有助于正确申明纪录中呈现null数据大概丧失数据的原

因

—PeterRitchie



14.对地点和德律风接纳多个字段

形貌街道地点就短短一行纪录是不敷的。Address_Line1、Address_Line2和Address_Line3可

以供应更年夜的天真性。另有，德律风号码和邮件地点最好具有本人的数据表，其间具有本身的范例

和标志种别。

—dwnerd

太过尺度化可要当心，如许做大概会招致功能上呈现成绩。固然地点和德律风表分别一般能够到达

最好形态，可是假如必要常常会见这类信息，也许在其父表中寄存“首选”信息（好比

Customer等）更加妥善些。非尺度化和减速会见之间的让步是有必定意义的。

—dhattrem





15.利用多个称号字段
我以为很受惊，很多人在数据库里就给name留一个字段。我以为只要刚进门的开辟职员才会这
么做，但实践上彀上这类做法十分广泛。我倡议应当把姓氏和名字看成两个字段来处置，然后在

查询的时分再把他们组合起来。

—klempan

Klempan不是独一一个注重到利用单个name字段的人，要把这类情形变得对用户更加友爱有好

些办法。我最经常使用的是在统一表中创立一个盘算列，经由过程它能够主动地毗连尺度化后的字段，这

样数据变化的时分它也随着变。不外，如许做在接纳建模软件时得很机敏才行。总之，接纳毗连

字段的体例能够无效的断绝用户使用和开辟职员界面。

—damon


16.防备巨细写混用的工具名和特别字符

已往最令我末路火的事变之一就是数据库里有巨细写混用的工具名，好比CustomerData。这一问

题从Access到Oracle数据库都存在。我不喜好接纳这类巨细写混用的工具定名办法，了局还不

得不手工修正名字。想一想看，这类数据库/使用程序能混到接纳更壮大数据库的那一天吗？接纳全

部年夜写并且包括下划符的名字具有更好的可读性（CUSTOMER_DATA），相对不要在工具名的

字符之间留空格。

—bfren



17.当心保存词

要包管你的字段名没有和保存词、数据库体系大概经常使用会见办法抵触，好比，比来我编写的一个

ODBC毗连程序里有个表，个中就用了DESC作为申明字段名。成果不可思议！DESC是

DESCENDING缩写后的保存词。内外的一个SELECT*语句却是能用，但我失掉的倒是一年夜堆

毫无用途的信息。

—DanielJordan



18.坚持字段名和范例的分歧性

在定名字段并为其指定命据范例的时分必定要包管分歧性。假设字段在某个表中叫做

“agreement_number”，你就别在另外一个内外把名字改成“ref1”。假设数据范例在一个内外

是整数，那在另外一个内外可就别酿成字符型了。记着，你干完本人的活了，其别人还要用你的数

据库呢。

—setanta



19.细心选择数字范例

在SQL中利用smallint和tinyint范例要出格当心，好比，假设你想看看月发卖总额，你的总额字

段范例是smallint，那末，假如总额凌驾了$32,767你就不克不及举行盘算操纵了。

—egermain



20.删除标志

在表中包括一个“删除标志”字段，如许就能够把行标志为删除。在干系数据库里不要独自删除

某一行；最好接纳扫除数据程序并且要细心保护索引全体性。

—kol





21.制止利用触发器
触发器的功效一般能够用其他体例完成。在调试程序时触发器大概成为搅扰。假设你的确必要采
用触发器，你最好会合对它文档化。

—kol



22.包括版本机制

倡议你在数据库中引进版本把持机制来断定利用中的数据库的版本。不管怎样你都要完成这一要

求。工夫一长，用户的需求老是会改动的。终极大概会请求修正数据库布局。固然你能够经由过程检

查新字段大概索引来断定数据库布局的版本，但我发明把版本信息间接寄存到数据库中不更加方

便吗？。

—RichardFoster



23.给文本字段留足余量

ID范例的文本字段，好比客户ID或订单号等等都应当设置得比一样平常设想更年夜，由于工夫不长你

多数就会由于要增加分外的字符而为难不已。例如说，假定你的客户ID为10位数长。那你应当

把数据库表字段的长度设为12大概13个字符长。这算华侈空间吗？是有一点，但也没你设想的

那末多：一个字段加长3个字符在有1百万笔记录，再加上一点索引的情形下才不外让全部数据

库多占有3MB的空间。但这分外占有的空间却无需未来重构全部数据库就能够完成数据库范围

的增加了。

—tlundin



24.列定名技能

我们发明，假设你给每一个表的列名都接纳一致的前缀，那末在编写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*fromCustomer,Order

Wherecu_surname="MYNAME"

andcu_name_id=or_cust_name_id

andor_quantity=1;

在没有这些前缀的情形下则写成这个模样：

Select*fromCustomer,Order

WhereCustomer.surname="MYNAME"

andCustomer.name_id=Order.cust_name_id

andOrder.quantity=1

第1个SQL语句没少键进几字符。但假如查询触及到5个表以致更多的列你就晓得这个技能

多有效了。
—BryceStenberg

第3部分—选择键
怎样选择键呢？这里有10个技能专门触及体系天生的主键的准确用法，另有什么时候和怎样索引字段
以取得最好功能等。


1.数据采掘要事后企图

我地点的市场部门一度要处置8万多份接洽体例，同时填写每一个客户的需要数据（这相对不是小

活）。我从中还要断定出一组客户作为市场方针。当我从最入手下手计划表和字段的时分，我试图不

在主索引里增添太多的字段以便加速数据库的运转速率。然后我意想到特定的组查询和信息采掘

既禁绝确速率也不快。了局只幸亏主索引中重修并且兼并了数据字段。我发明有一个唆使企图相

当关头——当我想创立体系范例查找时为何要接纳号码作为主索引字段呢？我能够用传真号码

举行检索，可是它几近就象体系范例一样对我来讲其实不主要。接纳后者作为主字段，数据库更新

后从头索引和检索就快多了。

—hscovell

可操纵数据堆栈（ODS）和数据堆栈（DW）这两种情况下的数据索引是有不同的。在DW情况

下，你要思索发卖部门是怎样构造发卖举动的。他们并非数据库办理员，可是他们断定表内的

键信息。这里计划职员大概数据库事情职员应当剖析数据库布局从而断定出功能和准确输入之间

的最好前提。

—teburlew



2.利用体系天生的主键

这一天类同技能1，但我以为有需要在这里反复提示人人。假设你老是在计划数据库的时分接纳

体系天生的键作为主键，那末你实践把持了数据库的索引完全性。如许，数据库和非野生机制就

无效地把持了对存储数据中每行的会见。

接纳体系天生键作为主键另有一个长处：当你具有分歧的键布局时，找到逻辑缺点很简单。

—teburlew



3.分化字段用于索引

为了分别定名字段和包括字段以撑持用户界说的报表，请思索分化其他字段（乃至主键）为其组

成要素以便用户能够对其举行索引。索引将加速SQL和报表天生器剧本的实行速率。例如说，

我一般在必需利用SQLLIKE表达式的情形下创立报表，由于casenumber字段没法分化为

year、serialnumber、casetype和defendantcode等要素。功能也会变坏。假设年度和范例字

段能够分化为索引字段那末这些报表运转起来就会快多了。

—rdelval



4.键计划4准绳

·为联系关系字段创立外键。

·一切的键都必需独一。

·制止利用复合键。

·外键老是联系关系独一的键字段。

—PeterRitchie





5.别忘了索引
索引是从数据库中猎取数据的最高效体例之一。95%的数据库功能成绩都能够接纳索引手艺失掉
办理。作为一条划定规矩，我一般对逻辑主键利用独一的成组索引，对体系键（作为存储历程）接纳

独一的非成组索引，对任何外键列接纳非成组索引。不外，索引就象是盐，太多了菜就篌了。你

得思索数据库的空间有多年夜，表怎样举行会见，另有这些会见是不是次要用作读写。

—tduvall

年夜多半数据库都索引主动创立的主键字段，可是可别忘了索引外键，它们也是常常利用的键，比

如运转查询显现主表和一切联系关系表的某笔记录就用得上。另有，不要索引memo/note字段，不

要索引年夜型字段（有良多字符），如许作会让索引占用太多的存储空间。

—gbrayton



6.不要索引经常使用的小型表

不要为小型数据表设置任何键，假设它们常常有拔出和删除操纵就更别如许作了。对这些拔出和

删除操纵的索引保护大概比扫描表空间损耗更多的工夫。

—kbpatel



7.不要把社会保证号码（SSN）选作键

永久都不要利用SSN作为数据库的键。除隐私缘故原由之外，须知当局愈来愈趋势于禁绝许把

SSN用作除支出相干之外的其他目标，SSN必要手工输出。永久不要利用手工输出的键作为主

键，由于一旦你输出毛病，你独一能做的就是删除全部纪录然后重新入手下手。

—teburlew

上个世纪70年月我还在读年夜学的时分，我记得当时SSN还曾被用做学号，固然只管这么做长短

法的。并且人们也都晓得这长短法的，但他们已习气了。厥后，跟着偷取身份犯法案件的增

加，我如今的年夜黉舍园正疾苦地从一年夜摊子数据中把SSN删除。

—generalist



8.不要用用户的键

在断定接纳甚么字段作为表的键的时分，可必定要当心用户将要编纂的字段。一般的情形下不要

选择用户可编纂的字段作为键。如许做会迫使你接纳以下两个措施：

·在创立纪录以后对用户编纂字段的举动施加限定。假设你这么做了，你大概会发明你的使用程

序在商务需求俄然产生变更，而用户必要编纂那些不成编纂的字段时缺少充足的天真性。当用

户在输出数据以后直到保留纪录才发明体系出了成绩他们该怎样想？删除重修？假设纪录不成

重修是不是让用户走开？

·提出一些检测和改正键抵触的办法。一般，费点精神也就弄定了，可是从功能下去看如许做的

价值就对照年夜了。另有，键的改正大概会迫使你冲破你的数据和贸易/用户界面层之间的隔

离。

以是仍是重提一句老话：你的计划要顺应用户而不是让用户来顺应你的计划。

—LamontAdams

不让主键具有可更新性的缘故原由是在干系形式下，主键完成了分歧表之间的联系关系。好比，

Customer表有一个主键CustomerID，而客户的订单则寄存在另外一个内外。Order表的主键大概



是OrderNo大概OrderNo、CustomerID和日期的组合。不论你选择哪一种键设置，你都必要在


Order表中寄存CustomerID来包管你能够给下订单的用户找到其订单纪录。

假设你在Customer内外修正了CustomerID，那末你必需找出Order表中的一切相干纪录对其进

行修正。不然，有些订单就会不属于任何客户——数据库的完全性就算垮台了。

假如索引完全性划定规矩施加到表一级，那末在不编写大批代码和附加删除纪录的情形下几近不成能

改动某一笔记录的键和数据库内一切联系关系的纪录。而这一历程常常毛病丛生以是应当只管制止。

—ljboast



9.可选键偶然可做主键

记着，查询数据的不是呆板而是人。

假设你有可选键，你大概进一步把它用做主键。那样的话，你就具有了创建壮大索引的才能。这

样能够制止利用数据库的人不能不毗连数据库从而得当的过滤数据。在严厉把持域表的数据库

上，这类负载是对照夺目的。假如可选键真正有效，那就是到达了主键的水准。

我的意见是，假设你有可选键，好比国度表内的state_code，你不要在现有不克不及变化的独一键上

创立后续的键。你要做的不过是创立毫无代价的数据。好比以下的例子：

Selectcount(*)

fromaddress,state_ref

where

address.state_id=state_ref.state_id

andstate_ref.state_code=TN

我的做法是如许的：

Selectcount(*)

fromaddress

where

andstate_code=TN

如你由于过分利用表的后续键创建这类表的联系关系，操纵负载真得必要思索一下了。

—Stocker



10.别忘了外键

年夜多半数据库索引主动创立的主键字段。但别忘了索引外键字段，它们在你想查询主表中的纪录

及其联系关系纪录时每次城市用到。另有，不要索引memo/notes字段并且不要索引年夜型文本字段

（很多字符），如许做会让你的索引占有大批的数据库空间。。
—gbrayton

第4部分—包管数据完全性
会商怎样坚持数据库的明晰和强健，怎样把无害数据下降到最小水平。


1.用束缚而非商务划定规矩强迫数据完全性

假如你依照商务划定规矩来处置需求，那末你应该反省商务条理/用户界面：假如商务划定规矩今后产生变

化，那末只必要举行更新便可。

假设需求源于保护数据完全性的必要，那末在数据库层面上必要施加限定前提。

假如你在数据层的确接纳了束缚，你要包管有举措把更新不克不及经由过程束缚反省的缘故原由接纳用户了解

的言语关照用户界面。除非你的字段定名很冗杂，不然字段名自己还不敷。—LamontAdams

只需有大概，请接纳数据库体系完成数据的完全性。这不仅包含经由过程尺度化完成的完全性并且还

包含数据的功效性。在写数据的时分还能够增添触发器来包管数据的准确性。不要依附于商务层

包管数据完全性；它不克不及包管表之间（外键）的完全性以是不克不及强加于其他完全性划定规矩之上。

—PeterRitchie



2.散布式数据体系

对散布式体系而言，在你决意是不是在各个站点复制一切数据仍是把数据保留在一个中央之前应当

估量一下将来5年大概10年的数据量。当你把数据传送到其他站点的时分，最幸亏数据库字段

中设置一些标志。在目标站点收到你的数据以后更新你的标志。为了举行这类数据传输，请写下

你本人的批处置大概调剂程序以特准时间距离运转而不要让用户在天天的事情后传输数据。当地

拷贝你的保护数据，好比盘算常数和利钱率等，设置版本号包管数据在每一个站点都完整分歧。

—SuhairTechRepublic



3.强迫唆使完全性

没有好举措能在无害数据进进数据库以后打消它，以是你应当在它进进数据库之前将其剔除。激

活数据库体系的唆使完全性特征。如许能够坚持数据的干净而能迫使开辟职员投进更多的工夫处

理毛病前提。

—kol



4.干系

假如两个实体之间存在多对一干系，并且另有大概转化为多对多干系，那末你最好一入手下手就设置

成多对多干系。从现有的多对一干系变化为多对多干系比一入手下手就是多对多干系要可贵多。

—CSDataArchitect



5.接纳视图

为了在你的数据库和你的使用程序代码之间供应另外一层笼统，你能够为你的使用程序创建专门的

视图而不用非要使用程序间接会见数据表。如许做还即是在处置数据库变动时给你供应了更多的

自在。

—GayHowe





6.给数据保有和恢复制订企图
思索数据保有战略并包括在计划过程当中，事后计划你的数据恢复历程。接纳能够公布给用户/开辟
职员的数据字典完成便利的数据辨认同时包管对数据源文档化。编写在线更新来“更新查询”供

今后万一数据丧失能够从头处置更新。

—kol



7.用存储历程让体系做重活

办理了很多贫苦来发生一个具有高度完全性的数据库办理计划以后，我地点的团队决意封装一些

联系关系表的功效组，供应一整套惯例的存储历程来会见各组以便加速速率和简化客户程序代码的开

发。在此时代，我们发明3GL编码器设置了一切大概的毛病前提，好比以下所示：

SELECTCnt=COUNT(*)

FROM[<Table>]

WHERE[<primarykeycolumn>]=<newvalue>

IFCnt=0

BEGIN

INSERTINTO[<Table>]

([<primarykeycolumn>])

VALUES(<Newvalue>)

END

ELSE

BEGIN

<indicateduplicationerror>

END

而一个非3GL编码器是如许做的：

INSERTINTO[<Table>]

([<primarykeycolumn>])

VALUES

(<Newvalue>)

IF@@ERROR=2627--LiteralerrorcodeforPrimaryKeyConstraint

BEGIN

<indicateduplicationerror>

END

第2个程序复杂多了，并且现实上，使用了我们给数据库的功效。固然我团体不喜好利用嵌进文

字（2627）。可是那样能够很便利地用一点事后处置来取代。数据库不但是一个寄存数据的地

方，它也是简化编码之地。

—a-smith



8.利用查找

把持数据完全性的最好体例就是限定用户的选择。只需有大概都应当供应给用户一个明晰的代价

列表供其选择。如许将削减键进代码的毛病和曲解同时供应数据的分歧性。某些大众数据出格适

合查找：国度代码、形态代码等。
—CSDataArchitect

第5部分—各类小技能
不包含在以上4个部分中的其他技能，八门五花，有了它们但愿你的数据库开辟事情会更轻松一些。


1.文档、文档、文档

对一切的快速体例、定名标准、限定和函数都要体例文档。

—nickypendragon

接纳给表、列、触发器等加正文的数据库工具。是的，这有点省事，但从久远来看，如许做对开

发、撑持和跟踪修正十分有效。

—chardove

取决于你利用的数据库体系，大概有一些软件会给你一些供你很快上手的文档。你大概但愿先开

始在说，然后取得愈来愈多的细节。大概你大概但愿周期性的预排，在输出新数据同时跟着你的

停顿对每部分细节化。不论你选择哪一种体例，总要对你的数据库文档化，大概在数据库本身的

外部大概独自创建文档。如许，当你过了一年多工夫后再回过火来做第2个版本，你出错的时机

将年夜年夜削减。

—mrs_helm



2.利用经常使用英语（大概其他任何言语）而不要利用编码

为何我们常常接纳编码（好比9935A多是墨水笔的供给代码，4XF788-Q多是帐目编

码）？来由良多。可是用户一般都用英语举行思索而不是编码。事情5年的管帐也许晓得

4XF788-Q是甚么器材，但新来的可就纷歧定了。在创立下拉菜单、列表、报表时最好依照英语

名排序。假设你必要编码，那你能够在编码旁附上用户晓得的英语。

—amasa



3.保留经常使用信息

让一个表专门寄存一样平常数据库信息十分有效。我常在这个内外寄存数据库以后版本、比来反省/修

复（对Access）、联系关系计划文档的称号、客户等信息。如许能够完成一种复杂机制跟踪数据

库，当客户埋怨他们的数据库没有到达但愿的请求而与你接洽时，如许做对非客户机/服务器情况

出格有效。

—RichardFoster



4.测试、测试、重复测试

创建大概订正数据库以后，必需用用户新输出的数据测试数据字段。最主要的是，让用户举行测

试而且同用户一道包管你选择的数据范例满意贸易请求。测试必要在把新数据库投进实践服务之

前完成。
—juneebug



5.反省计划

在开辟时代反省数据库计划的经常使用手艺是经由过程其所撑持的使用程序原型反省数据库。换句话说，

针对每种终极表达数据的原型使用，包管你反省了数据模子而且检察怎样掏出数据。
—jgootee





6.Access计划技能
对庞大的MicrosoftAccess数据库使用程序而言，能够把一切的主表放在一个数据库文件里，然
后增添其他数据库文件和装载同原无数据库有关的特别函数。依据必要用这些函数毗连到主文件

中的主表。好比数据输出、数据QC、统计剖析、向办理层大概当局部门供应报表和各种只读

查询等。这一措施简化了用户和组权限的分派，并且有益于使用程序函数的分组和分别，从而在

程序必需修正的时分易于办理。
—DennisWalden

©CNETNetworksInc.2002

“MySQL实际上是一个数据库家族，你可以从选择一个并将其配置成可以满足你的大多数情况，”开源顾问公司Ethiqa的总裁如此表示，“因此，你可以在开始的时候选择一个小巧的版本产品，以后再根据需要来对其进行性能或大小上的扩展。”

微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数据库的一些概念可以实现了。

习惯敲命令行的朋友可能会爽一些。但是功能有限。适合机器跑不动SQLServerManagementStudio的朋友使用。

财务软件要用SQL也只是后台的数据库而已,软件都是成品的,当然多学东西肯定是有好处的..

是要和操作系统进行Socket通讯的场景。否则建议慎重！

SQL语言是学习所有数据库产品的基础，无论你是做数据库管理还是做数据库开发都是这样。不过具体学习的侧重点要看你将来做哪一块，如果是做数据库管理（DBA），侧重点应该放在SQLServer的系统管理上.

如果我们从集合论（关系代数）的角度来看，一张数据库的表就是一组数据元的关系，而每个SQL语句会改变一种或数种关系，从而产生出新的数据元的关系（即产生新的表）。

两个月啃那本sqlserver2005技术内部-存储引擎，花了几个月啃四本书

同样会为索引视图等应用带来麻烦。看看行级和事务级的快照数据放在tempdb中，就能感觉到目前架构的尴尬。