数据库设计的最佳实践
jopen
10年前
1、使用定义明确的表或列名，并保持一致（例如，School、StudentCourse、CourseID）。
2、使用单数形式的表名（即，用StudentCourse而非StudentCourses）。表代表了实体的合集，不需要复数形式。
3、不要在表名中使用空格。否则你将在定义表时不得不使用“{”、“[”等字符（即为了访问表Student Course，你须得书写“Student Course”。使用StudentCourse足够了）。
4、不要在表名中加入不必要的前缀或后缀（即，命名School即可，不必为TblSchool、SchoolTable等）。
5、加密密码，保证安全性。需要时可在应用中解密它们。
6、在所有的表中使用整型ID字段。即便眼下ID还用不着，将来也会有用到的时候（例如在关联表中、索引等）。
7、使用整数（或相关）类型的数据列来创建索引。Varchar列索引会导致性能问题。
8、对布尔值使用bit字段。使用Integer或Varchar类型存储毫无必要。同时，在这些列名中加入Is描述。
9、对数据库访问进行验证。任何用户都不应给予admin角色。
10、若非必要的话，避免使用“select *”查询语句。为了更好的性能，请使用“select [required_columns_list]”。
11、若程序代码很大，可使用ORM（对象关系映射）框架（如Hibernate、iBatis）工具。关于其性能问题可通过详细配置参数来应付。
12、将那些不使用或不常用而又较大的表（table parts）区隔到不同的物理存储空间，以便提供更好地查询性能。
13、对重要的数据库系统，使用灾难恢复方案和安全服务，比如故障切换集群（failover clustering）、自动备份、复制等。
14、为了保证数据完整性，请使用约束（如外键、Check、Not null约束等）。不要给予对应用代码的完整控制权。
15、缺乏数据库文档的习惯非常不好（evil）。用ER图对数据库设计模型进行描述。同时记得编写触发器、存储过程等脚本的代码。
16、对频繁进行的查询使用索引。Analyser工具可用于决定index在何处定义。对于查询获取大量列，聚簇索引（clustered index）通常更好。而对于点查询，可使用非聚簇索引。
17、将数据库服务器与Web服务器放置在不同的计算机中。这可以提供更好的安全性能（攻击者不能直接访问数据），而且由于可以限制访问请求数及进程量，服务器也能获得更的CPU及内存性能。
18、图像和Blob列一定不要定义在查询频繁的表中，这也是出于性能考虑。可将这些数据放在单独的表中，并在查询表中建立指向它们的指针。
19、规范化（Normalization）是必须的，以进一步优化应用性能。否则可能面临过多的数据副本，当然过渡规范化（over-normalization）则会导致大量跨太多表的连接。这两者都会影响到性能。
20、同样也要在数据库建模及设计上花些功夫。若为此省下时间，则很可能面临10倍乃至100/1000倍的维护/重新设计成本。
2、使用单数形式的表名（即，用StudentCourse而非StudentCourses）。表代表了实体的合集，不需要复数形式。
3、不要在表名中使用空格。否则你将在定义表时不得不使用“{”、“[”等字符（即为了访问表Student Course，你须得书写“Student Course”。使用StudentCourse足够了）。
4、不要在表名中加入不必要的前缀或后缀（即，命名School即可，不必为TblSchool、SchoolTable等）。
5、加密密码，保证安全性。需要时可在应用中解密它们。
6、在所有的表中使用整型ID字段。即便眼下ID还用不着，将来也会有用到的时候（例如在关联表中、索引等）。
7、使用整数（或相关）类型的数据列来创建索引。Varchar列索引会导致性能问题。
8、对布尔值使用bit字段。使用Integer或Varchar类型存储毫无必要。同时，在这些列名中加入Is描述。
9、对数据库访问进行验证。任何用户都不应给予admin角色。
10、若非必要的话，避免使用“select *”查询语句。为了更好的性能，请使用“select [required_columns_list]”。
11、若程序代码很大，可使用ORM（对象关系映射）框架（如Hibernate、iBatis）工具。关于其性能问题可通过详细配置参数来应付。
12、将那些不使用或不常用而又较大的表（table parts）区隔到不同的物理存储空间，以便提供更好地查询性能。
13、对重要的数据库系统，使用灾难恢复方案和安全服务，比如故障切换集群（failover clustering）、自动备份、复制等。
14、为了保证数据完整性，请使用约束（如外键、Check、Not null约束等）。不要给予对应用代码的完整控制权。
15、缺乏数据库文档的习惯非常不好（evil）。用ER图对数据库设计模型进行描述。同时记得编写触发器、存储过程等脚本的代码。
16、对频繁进行的查询使用索引。Analyser工具可用于决定index在何处定义。对于查询获取大量列，聚簇索引（clustered index）通常更好。而对于点查询，可使用非聚簇索引。
17、将数据库服务器与Web服务器放置在不同的计算机中。这可以提供更好的安全性能（攻击者不能直接访问数据），而且由于可以限制访问请求数及进程量，服务器也能获得更的CPU及内存性能。
18、图像和Blob列一定不要定义在查询频繁的表中，这也是出于性能考虑。可将这些数据放在单独的表中，并在查询表中建立指向它们的指针。
19、规范化（Normalization）是必须的，以进一步优化应用性能。否则可能面临过多的数据副本，当然过渡规范化（over-normalization）则会导致大量跨太多表的连接。这两者都会影响到性能。
20、同样也要在数据库建模及设计上花些功夫。若为此省下时间，则很可能面临10倍乃至100/1000倍的维护/重新设计成本。