2023年7月27日发(作者：)

设计数据库时需要考虑的问题1、考察现有系统环境 ⼤多数数据库项⽬都不是从头开始建⽴的，通常机构内总会存在⽤来满⾜特定需求的现有系统。显然，现有系统并不完美，否则你就不必再建⽴新系统了。但是对旧系统的研究可以让你发现⼀些可能会忽略的细微问题。⼀般来说，考察现有系统对你绝对有好处。2、充分预计需求的升级趋势 询问⽤户如何看待未来需求变化⾮常有⽤，这样做可以达到两个⽬的：⾸先，可以清楚地了解应⽤设计在哪个地⽅应该更具灵活性以及如何避免性能瓶颈；其次，知道发⽣事先没有确定的需求变更时⽤户将和你⼀样感到吃惊。3、充分理解客户的需求 看起来这应该是显⽽易见的事，但需求就是来⾃客户（这⾥要从内部和外部客户的⾓度考虑）。不要依赖⽤户写下来的需求，真正的需求在客户的脑袋⾥。你要让客户解释其需求，⽽且随着开发的继续，还要经常询问客户保证其需求仍然在开发的⽬的之中。 ⼀旦你认为你已经明确了业务内容，你最好同客户进⾏⼀次系统的交流。采⽤客户的术语并且向他们解释你所想到的和你所听到的。同时还应该⽤可能、将会和必须等词汇表达出系统的关系基数。这样你就可以让你的客户纠正你⾃⼰的理解。 了解业务可以在以后的开发阶段节约⼤量的时间，⽽其你会发现，⼀旦你明确了业务需求，你就可以⾃⼰做出许多决策了。4、确定数据对象的命名规范 ⼀定要定义数据库对象的命名规范，可以考虑⽤约定好的前缀或后缀：对于视图来说，可以采⽤vw_前缀；对表来说，表名可以加上前缀tbl_；对表内的列[字段]来说，数字类型可以⽤_N作为后缀，字符类型可以采⽤_C后缀等，Money类型可以采⽤_M后缀，⽇期类型可以采⽤_D作为后缀等等；对于存储过程来说，可以采⽤sp_前缀；对于⾃定义函数，可以考虑采⽤udf_前缀；此外，采⽤全⼤写字母，且以下划线分割单词，如：TBL_CUSTOMER_INFO5、创建数据字典 ⼀定要花点时间创建数据字典，其中⾄少应该包含每个字段的数据类型和在每个表内的主外键。创建数据字典确实有点费时但对其他开发⼈员要了解整个设计却是完全必要的。越早创建越能有助于避免今后⾯临的可能混乱，从⽽可以让任何了解数据库的⼈都明确如何从数据库中获得数据。

6、从输⼊输出下⼿ 在定义数据库表和字段需求（输⼊）时，⾸先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了⽀持这些输出哪些是必要的表和字段。举个简单的例⼦：假如客户需要⼀个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段⽽不要把邮政编码糅进地址字段⾥。7、报表技巧 要了解⽤户通常是如何报告数据的：批处理还是在线提交报表？时间间隔是每天、每周、每⽉、每个季度还是每年？如果需要的话还可以考虑创建总结表。系统⽣成的主键在报表中很难管理。⽤户在具有系统⽣成主键的表内⽤副键进⾏检索往往会返回许多重复数据。这样的检索性能⽐较低⽽且容易引起混乱。8、考虑国际化问题 在设计⽤到⽹络或者具有其他国际特性的数据库时，⼀定要记住⼤多数国家都有不同的字段格式，⽐如邮政编码等，有些国家，⽐如新西兰就没有邮政编码⼀说。9、记录的版本 借鉴的设计模式，每个表都设置以下6个字段： Create_Date Last_Modify_Date Creator Modifier Modify_Number Is_Deleted在表中包含⼀个“删除标记”字段，这样就可以把⾏标记为删除。在关系数据库⾥不要单独删除某⼀⾏；最好采⽤清除数据程序⽽且要仔细维护索引整体性。

10、仔细选择数据类型 在SQL中使⽤smallint和 tinyint类型要特别⼩⼼，⽐如，假如你想看看⽉销售总额，你的总额字段类型是 smallint，那么，如果总额超过了$32,767你就不能进⾏计算操作了。 在命名字段并为其指定数据类型的时候⼀定要保证⼀致性。假如字段在某个表中叫做“agreement_number”，你就别在另⼀个表⾥把名字改成“ref1”。假如数据类型在⼀个表⾥是整数，那在另⼀个表⾥可就别变成字符型了。记住，你⼲完⾃⼰的活了，其他⼈还要⽤你的数据库呢。

11、尽量避免使⽤触发器 触发器的功能通常可以⽤其他⽅式实现。在调试程序时触发器可能成为⼲扰。假如你确实需要采⽤触发器，你最好集中对它⽂档化。12、给⽂本字段留⾜余量 ID类型的⽂本字段，⽐如客户ID或定单号等等都应该设置得⽐⼀般想象更⼤，因为时间不长你多半就会因为要添加额外的字符⽽难堪不已。⽐⽅说，假设你的客户 ID为10位数长。那你应该把数据库表字段的长度设为12或者13个字符长。这算浪费空间吗？是有⼀点，但也没你想象的那么多：⼀个字段加长3个字符在有1百万条记录，再加上⼀点索引的情况下才不过让整个数据库多占据3MB的空间。但这额外占据的空间却⽆需将来重构整个数据库就可以实现数据库规模的增长了。⾝份证的号码从15位变成18位就是最好和最惨痛的例⼦。13、⽤约束⽽⾮商务规则强制数据完整性 如果你按照商务规则来处理需求，那么你应当检查商务层次/⽤户界⾯：如果商务规则以后发⽣变化，那么只需要进⾏更新即可。假如需求源于维护数据完整性的需要，那么在数据库层⾯上需要施加限制条件。如果你在数据层确实采⽤了约束，你要保证有办法把更新不能通过约束检查的原因采⽤⽤户理解的语⾔通知⽤户界⾯。除⾮你的字段命名很冗长，否则字段名本⾝还不够。 只要有可能，请采⽤数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性⽽且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。14、分布式数据系统 对分布式系统⽽⾔，在你决定是否在各个站点复制所有数据还是把数据保存在⼀个地⽅之前应该估计⼀下未来 5年或者 10年的数据量。当你把数据传送到其他站点的时候，最好在数据库字段中设置⼀些标记。在⽬的站点收到你的数据之后更新你的标记。为了进⾏这种数据传输，请写下你⾃⼰的批处理或者调度程序以特定时间间隔运⾏⽽不要让⽤户在每天的⼯作后传输数据。本地拷贝你的维护数据，⽐如计算常数和利息率等，设置版本号保证数据在每个站点都完全⼀致。15、强制指⽰完整性(参照完整性?) 没有好办法能在有害数据进⼊数据库之后消除它，所以你应该在它进⼊数据库之前将其剔除。激活数据库系统的指⽰完整性特性。这样可以保持数据的清洁⽽能迫使开发⼈员投⼊更多的时间处理错误条件。16、关系 如果两个实体之间存在多对⼀关系，⽽且还有可能转化为多对多关系，那么你最好⼀开始就设置成多对多关系。从现有的多对⼀关系转变为多对多关系⽐⼀开始就是多对多关系要难得多。17、采⽤视图 为了在你的数据库和你的应⽤程序代码之间提供另⼀层抽象，你可以为你的应⽤程序建⽴专门的视图⽽不必⾮要应⽤程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的⾃由。18、别忘了索引 索引是从数据库中获取数据的最⾼效⽅式之⼀。95%的数据库性能问题都可以采⽤索引技术得到解决。作为⼀条规则，我通常对逻辑主键使⽤唯⼀的成组索引，对系统键（作为存储过程）采⽤唯⼀的⾮成组索引，对任何外键列[字段]采⽤⾮成组索引。不过，索引就象是盐，太多了菜就咸了。你得考虑数据库的空间有多⼤，表如何进⾏访问，还有这些访问是否主要⽤作读写。 ⼤多数数据库都索引⾃动创建的主键字段，但是可别忘了索引外键，它们也是经常使⽤的键，⽐如运⾏查询显⽰主表和所有关联表的某条记录就⽤得上。还有，不要索引 memo/note字段，不要索引⼤型字段（有很多字符），这样作会让索引占⽤太多的存储空间。19、⽤存储过程让系统做重活 解决了许多⿇烦来产⽣⼀个具有⾼度完整性的数据库解决⽅案之后，我决定封装⼀些关联表的功能组，提供⼀整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。数据库不只是⼀个存放数据的地⽅，它也是简化编码之地。

20、使⽤系统⽣成的主键 假如你总是在设计数据库的时候采⽤系统⽣成的键作为主键，那么你实际控制了数据库的索引完整性。这样，数据库和⾮⼈⼯机制就有效地控制了对存储数据中每⼀⾏的访问。采⽤系统⽣成键作为主键还有⼀个优点：当你拥有⼀致的键结构时，找到逻辑缺陷很容易。