数据库设计经验谈

一个胜利的处置体例，是由：[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 公司的 powerdesign，她扶助 pb、vb、delphe 等谈话，经过 odbc 不妨贯穿市情上时髦的 30 多个数据库，囊括 dbase、foxpro、vfp、sql server 等，此后有时机我将提防引见 powerdesign 的运用。   获得数据形式资源画册  正在探求示例形式的人不妨观赏《数据形式资源画册》一书，该书由 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 表白式的文书档案化来说这是实足需要的。   创造形式  一张图表超过夸夸其谈：开拓职员不只要观赏和实行它，并且还要用它来扶助本人和用户对话。形式无助于于普及协调功效，如许在先期的数据库安排中简直不大概展示大的题目。形式不用弄的很搀杂；以至不妨大略得手写在一张纸上就不妨了。不过要保护其上的论理联系此后能产奏效益。 [page_break]从输出输入发端 在设置数据库表和字段需要（输出）时，开始应查看现有的大概仍旧安排出的报表、查问和视图（输入）以确定为了扶助那些输入哪些是需要的表和字段。举个大略的例子：假设存户须要一个报表依照邮编排序、分段和乞降，你要保护个中囊括了独立的邮编字段而不要把邮编糅进地方字段里。  报表本领 要领会用户常常是怎样汇报数据的：批处置仍旧在线提交报表？功夫间隙是每天、每周、每月、每个季度仍旧年年？即使须要的话还不妨商量创造归纳表。体例天生的主键在报表中很难处置。用户在具备体例天生主键的表内用副键举行检索常常会归来很多反复数据。如许的检痛快能比拟低并且简单惹起凌乱。  领会存户需要 看上去这该当是不言而喻的事，但需要即是来自存户（这边要从里面和外部存户的观点商量）。不要依附用户写下来的需要，真实的需要在存户的脑壳里。你要让存户证明其需要，并且跟着开拓的连接，还要常常咨询存户保护其需要仍旧在开拓的手段之中。一个静止的道理是：“惟有我瞥见了我才领会我想要的是什么”必定会引导洪量的窝工，由于数据库没有到达存户历来没有写下来的需要规范。而更糟的是你对她们需要的证明只属于你本人，并且大概是实足缺点的。  第 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 等。 沿用普遍笼统术语来标识“实物”的类型不妨让你在关系数据以满意交易诉求上面赢得宏大的精巧性，同声如许做还不妨明显贬低数据保存所需的冗余量。 [page_break]用户来自寰球各地 在安排用到搜集大概具备其余国际个性的数据库时，确定要记取大普遍国度都有各别的字段方法，比方邮编等，有些国度，比方新西兰就没有邮编一说。  数据反复须要沿用分立的数据表 即使你创造本人在反复输出数据，请创造新表和新的联系。  每个表中都该当增添的 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 customer.name_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 须要细工输出。长久不要运用细工输出的键动作主键，由于一旦你输出缺点，你独一能做的即是简略所有记载而后从新发端。[page_break]我在破译他人的步调功夫，我看到很多人把 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 数据库运用步调而言，不妨把一切的主表放在一个数据水库蓄水容积器文献里，而后减少其余数据库表文献和承载同原罕见据库相关的特出文献。按照须要用那些文献贯穿到主文献中的主表。比方数据输出、数据索引、统计领会、向处置层大概当局部分供给报表以及各类只读查问等。这一办法简化了用户和组权力的调配，并且利于于运用步调因变量（保存进程）的分批和分别，进而在步调必需窜改的功夫容易处置。