20个设计数据库的最佳实践指南

数据库设计看上去很简单,但是如果不经意随意设计,可能会为日后维护拓展或性能方面埋下祸根。以下是20个设计数据库的最佳实践指南:

1. 使用完整的一致的数据表名称和字段名,如:School, StudentCourse, CourseID

2.数据表名称使用单数,比如使用StudentCourse 而不是StudentCourses,数据表代表实体的一个集合,因此没有必要使用复数名称。

3. 数据表名称不要使用空格,比如StudentCourse 比Student Course更好。

4.数据表名称不要使用不必要的前缀和后缀。比如TblSchool, SchoolTable 都不如School 好。

5.密码必须加密保存,只有需要时在应用程序中解密。

6.为所有数据表都使用整数id作为字段,如果现在不需要id,也许将来会需要,比如关联表或索引等。

7.选择整数类型的字段作为索引,varchar字段索引会引起性能问题。

8.使用bit字段作为布尔值,使用整数Interger或varchar作为布尔值字段会增加不必要的存储消耗,这些布尔字段名称以"Is"开始。

9.提供数据库的授权访问方式,不要将管理员角色给每个人。

10.避免“select *”,如果必须使用,需要确认必要性,使用 “select 字段名"有更好的性能。

11.只有应用系统有一定规模才使用ORM(对象和关系数据库映射)框架如Hibernate iBatis等,这些ORM框架性能需要很详细的配置参数来调校。

12. 将大的很少用使用的表切分成多个表,存储到不同物理存储上,这样能获得好的性能。

13.对于大的 重要的数据库系统,使用失败恢复集群 自动备份 复制等方式。

14.使用约束(外键 或not null)维持数据完整一致性,不要将所有控制器给应用代码。

15.缺乏数据库文档是邪恶的。

16.对于频繁查询使用索引,分析工具可以帮助你决定哪些需要索引。

17.数据库服务器和Web服务器器放在不同的机器上。这样有更好性能。

18.不要在一个频繁查询的表里定义图片和blob数据类型。这些特殊数据需要放在单独不同的表中。

19.规范化(Normalisation)有助于性能提升,非规范化会引起数据冗余,过于规范化会引入太多的表,两者都会导致性能问题。

20.如果需要花费时间进行数据库建模设计,节省设计时间将导致维护时间过长或重新设计时间。

时间: 2024-12-21 02:51:59

20个设计数据库的最佳实践指南的相关文章

领域驱动设计之单元测试最佳实践(二)

领域驱动设计之单元测试最佳实践(一) 介绍完了DDD案例,我们终于可以进入主题了,本方案的测试代码基于Xunit编写,断言组件采用了FluentAssertions,类似的组件还有Shouldly.另外本案例使用了Code Contracts for .NET,如果不安装此插件,可能有个别测试不能正确Pass. 为了实现目标中的第二点:"尽量不Mock,包括数据库读取部分”,我尝试过3种方案: 1.测试代码连接真实数据库,只需要将测试数据库配置到测试项目中的web.config中,即可达到这一目

领域驱动设计之单元测试最佳实践(一)

领域驱动设计之单元测试最佳实践(二) 一直以来,我试图找到一种有效的单元测试模式,使得“单元测试”真正能够在团队中流行起来,让单元测试不再是走过场,而是让单元测试切切实实成为提高代码质量的途径. 本文将描述一种以EF Code First模式实现的领域驱动项目实施单元测试的方案. 在描述这一方案之前,让我们看看这一最佳实践源于何种考虑和最终实现的目标: 1.以MVC项目为例,如果将单元测试的重心放在如何测试一个Controller或Action将收效甚微,原因有二: 从原则上讲Controlle

[转]ASP.NET Core Web API 最佳实践指南

原文地址: ASP.NET-Core-Web-API-Best-Practices-Guide 转自 介绍# 当我们编写一个项目的时候,我们的主要目标是使它能如期运行,并尽可能地满足所有用户需求. 但是,你难道不认为创建一个能正常工作的项目还不够吗?同时这个项目不应该也是可维护和可读的吗? 事实证明,我们需要把更多的关注点放到我们项目的可读性和可维护性上.这背后的主要原因是我们或许不是这个项目的唯一编写者.一旦我们完成后,其他人也极有可能会加入到这里面来. 因此,我们应该把关注点放到哪里呢? 在

软件需求分、架构设计与建模最佳实践

软件需求分.架构设计与建模最佳实践 cxx 2019-04-13 一.为什么要详细设计,价值? 在多人团队环境中,详细设计驱动开发可实现明确交付的目标和标准 可复用的设计成果 提高代码的可维护性 可对交付进行工作量和质量的评估 实现知识传承,提高软件生命周期 二.控制软件复杂性的基本方法 分解法 抽象法 三.UML有哪些元素 结构 行为 四.基于用户目标的需求组织形式 交互式需求 清晰的责任 场景化 文档的五大功效 有助于编写使用手册 测试用例转化:帮助开发人员设计测试用例 需求用例 利于详细设

PYTHON 最佳实践指南(转)

add by zhj: 本文参考了The Hitchhiker's Guide to Python,当然也加入了作者的一些东西.The Hitchhiker's Guide to Python 的github地址是https://github.com/kennethreitz/python-guide,貌似还能用pip安装该包.先占个坑,后面有时间再把文章转过来 原文:PYTHON 最佳实践指南

SQL Server系统数据库备份最佳实践

原文:SQL Server系统数据库备份最佳实践 首先了解主要的系统数据库: 系统数据库 master 包含登录信息和其他数据库的核心信息 msdb 存储作业.操作员.警报.备份还原历史.数据库邮件信息等等. model 所有新数据库的模型,如果希望新数据库都有某些对象,可以在这里创建. tempdb sql server重启时重建,所以不需要备份 除了以上四种,其实还有一个数据库:Resource 从2005就引入的,一个只读.隐藏的数据库,包含所有在sql server中的系统对象.由于SQ

[Java Performance] 数据库性能最佳实践 - JPA和读写优化

数据库性能最佳实践 当应用需要连接数据库时,那么应用的性能就可能收到数据库性能的影响.比如当数据库的I/O能力存在限制,或者因缺失了索引而导致执行的SQL语句需要对整张表进行遍历.对于这些问题,仅仅对应用代码进行优化可能是不够,还需要了解数据库的知识和特点. 示例数据库 该数据库表示了128只股票在1年内(261个工作日)的股价信息. 其中有两张表:STOCKPRICE和STOCKOPTIONPRICE. STOCKPRICE中使用股票代码作为主键,另外还有日期字段.它有33408条记录(128

App 后台架构设计方案 设计思想与最佳实践

转载请注明出处:http://blog.csdn.net/smartbetter/article/details/53933096 做App做的久了,就想研究一下与之相关的App后台,发现也是蛮有趣的.App后台的两个重要作用就是 远程存储数据 和 消息中转.这里面的知识体系也是相当复杂,做好一个App后台也是需要长期锤炼的.本篇文章从 App 后台架构 的角度介绍.好了,下面进入正题: 说起架构,我们先看一下何为架构,百度百科是这样说的:架构,又名软件架构,是有关软件整体结构与组件的抽象描述,

Python 最佳实践指南

粗粗粗略地过了一遍,大体捞了一些东西出来,大段大段英文太费眼了,回头细读在更新进来 浓缩版,20分钟可大体过完,然后根据自己需要去看详细的吧 整体内容还是很不错的,建议细读英文 PS:文档含有巨量的TODO(没写空白着待补充的),不过但从目录上来看还是很强大滴,相信完善后,会成为一份很牛逼的指南(难度比官方指南高一点点) 第零部分 Getting Started 链接 不解释,不翻译,自个看….真的没啥(每本入门书籍第一章…) 第一部分 Writing Great Code Structurin