建立数据库的原则（怎样建立一个好的数据库）

数据库设计原则2007-05-26 01:08一个好的数据库产品不等于就有一个好的应用系统，如果不能设计一个合理的数据库模型，不仅会增加客户端和服务器段程序的编程和维护的难度，而且将会影响系统实际运行的性能。一般来讲，在一个MIS系统分析、设计、测试和试运行阶段，因为数据量较小，设计人员和测试人员往往只注意到功能的实现，而很难注意到性能的薄弱之处，等到系统投入实际运行一段时间后，才发现系统的性能在降低……

数据库设计是建立数据库及其应用系统的核心和基础，它要求对于指定的应用环境，构造出较优的数据库模式，建立起数据库应用系统，并使系统能有效地存储数据，满足用户的各种应用需求。一般按照规范化的设计方法，常将数据库设计分为若干阶段：

系统规划阶段

主要是确定系统的名称、范围；确定系统开发的目标功能和性能；确定系统所需的资源；估计系统开发的成本；确定系统实施计划及进度；分析估算系统可能达到的效益；确定系统设计的原则和技术路线等。对分布式数据库系统，还应分析用户环境及网络条件，以选择和建立系统的网络结构。

需求分析阶段

要在用户调查的基础上，通过分析，逐步明确用户对系统的需求，包括数据需求和围绕这些数据的业务处理需求。通过对组织、部门、企业等进行详细调查，在了解现行系统的概况、确定新系统功能的过程中，收集支持系统目标的基础数据及其处理方法。

概念设计阶段

要产生反映企业各组织信息需求的数据库概念结构，即概念模型。概念模型必须具备丰富的语义表达能力、易于交流和理解、易于变动、易于向各种数据模型转换、易于从概念模型导出与DBMS有关的逻辑模型等特点。

逻辑设计阶段

除了要把E－R图的实体和联系类型，转换成选定的DBMS支持的数据类型，还要设计子模式并对模式进行评价，最后为了使模式适应信息的不同表示，需要优化模式。

物理设计阶段

主要任务是对数据库中数据在物理设备上的存放结构和存取方法进行设计。数据库物理结构依赖于给定的计算机系统，而且与具体选用的DBMS密切相关。物理设计常常包括某些 *** 作约束，如响应时间与存储要求等。

系统实施阶段

主要分为建立实际的数据库结构；装入试验数据对应用程序进行测试；装入实际数据建立实际数据库三个步骤。

另外，在数据库的设计过程中还包括一些其他设计，如数据库的安全性、完整性、一致性和可恢复性等方面的设计,不过，这些设计总是以牺牲效率为代价的,设计人员的任务就是要在效率和尽可能多的功能之间进行合理的权衡。

一个好的数据库产品不等于就有一个好的应用系统，如果不能设计一个合理的数据库模型，不仅会增加客户端和服务器段程序的编程和维护的难度，而且将会影响系统实际运行的性能。一般来讲，在一个MIS系统分析、设计、测试和试运行阶段，因为数据量较小，设计人员和测试人员往往只注意到功能的实现，而很难注意到性能的薄弱之处，等到系统投入实际运行一段时间后，才发现系统的性能在降低……

数据库设计是建立数据库及其应用系统的核心和基础，它要求对于指定的应用环境，构造出较优的数据库模式，建立起数据库应用系统，并使系统能有效地存储数据，满足用户的各种应用需求。一般按照规范化的设计方法，常将数据库设计分为若干阶段：

系统规划阶段

主要是确定系统的名称、范围；确定系统开发的目标功能和性能；确定系统所需的资源；估计系统开发的成本；确定系统实施计划及进度；分析估算系统可能达到的效益；确定系统设计的原则和技术路线等。对分布式数据库系统，还应分析用户环境及网络条件，以选择和建立系统的网络结构。

需求分析阶段

要在用户调查的基础上，通过分析，逐步明确用户对系统的需求，包括数据需求和围绕这些数据的业务处理需求。通过对组织、部门、企业等进行详细调查，在了解现行系统的概况、确定新系统功能的过程中，收集支持系统目标的基础数据及其处理方法。

概念设计阶段

要产生反映企业各组织信息需求的数据库概念结构，即概念模型。概念模型必须具备丰富的语义表达能力、易于交流和理解、易于变动、易于向各种数据模型转换、易于从概念模型导出与DBMS有关的逻辑模型等特点。

逻辑设计阶段

除了要把E－R图的实体和联系类型，转换成选定的DBMS支持的数据类型，还要设计子模式并对模式进行评价，最后为了使模式适应信息的不同表示，需要优化模式。

物理设计阶段

主要任务是对数据库中数据在物理设备上的存放结构和存取方法进行设计。数据库物理结构依赖于给定的计算机系统，而且与具体选用的DBMS密切相关。物理设计常常包括某些 *** 作约束，如响应时间与存储要求等。

系统实施阶段

主要分为建立实际的数据库结构；装入试验数据对应用程序进行测试；装入实际数据建立实际数据库三个步骤。

另外，在数据库的设计过程中还包括一些其他设计，如数据库的安全性、完整性、一致性和可恢复性等方面的设计,不过，这些设计总是以牺牲效率为代价的,设计人员的任务就是要在效率和尽可能多的功能之间进行合理的权衡。

>

■关系数据库factsandinformation

关系数据库是建立在集合代数基础上，应用数学方法来处理数据库中的数据。现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示。

关系模型由关系数据结构、关系 *** 作集合、关系完整性约束三部分组成。

全关系系统十二准则

全关系系统应该完全支持关系模型的所有特征。关系模型的奠基人EFCodd具体地给出了全关系系统应遵循的基本准则。

;''准则0'':一个关系形的关系数据库系统必须能完全通过它的关系能力来管理数据库。

;''准则1''信息准则:关系数据库系统的所有信息都应该在逻辑一级上用表中的值这一种方法显式的表示。

;''准则2''保证访问准则:依靠表名、主码和列名的组合，保证能以逻辑方式访问关系数据库中的每个数据项。

;''准则3''空值的系统化处理:全关系的关系数据库系统支持空值的概念，并用系统化的方法处理空值。

;''准则4''基于关系模型的动态的联机数据字典:数据库的描述在逻辑级上和普通数据采用同样的表述方式。

;''准则5''统一的数据子语言:

一个关系数据库系统可以具有几种语言和多种终端访问方式，但必须有一种语言，它的语句可以表示为严格语法规定的字符串，并能全面的支持各种规则。

;''准则6''视图更新准则:所有理论上可更新的视图也应该允许由系统更新。

;''准则7''高级的插入、修改和删除 *** 作:系统应该对各种 *** 作进行查询优化。

;''准则8''数据的物理独立性:无论数据库的数据在存储表示或存取方法上作任何变化，应用程序和终端活动都保持逻辑上的不变性。

;''准则9''数据逻辑独立性:当对基本关系进行理论上信息不受损害的任何改变时，应用程序和终端活动都保持逻辑上的不变性。

;''准则10''数据完整的独立性:关系数据库的完整性约束条件必须是用数据库语言定义并存储在数据字典中的。

;''准则11''分布独立性:关系数据库系统在引入分布数据或数据重新分布时保持逻辑不变。

;''准则12''无破坏准则:如果一个关系数据库系统具有一个低级语言，那么这个低级语言不能违背或绕过完整性准则。

■实时数据库是数据库系统发展的一个分支，它适用于处理不断更新的快速变化的数据及具有时间限制的事务处理。实时数据库技术是实时系统和数据库技术相结合的产物，研究人员希望利用数据库技术来解决实时系统中的数据管理问题，同时利用实时技术为实时数据库提供时间驱动调度和资源分配算法。然而，实时数据库并非是两者在概念、结构和方法上的简单集成。需要针对不同的应用需求和应用特点，对实时数据模型、实时事务调度与资源分配策略、实时数据查询语言、实时数据通信等大量问题作深入的理论研究。实时数据库系统的主要研究内容包括：

实时数据库模型

实时事务调度：包括并发控制、冲突解决、死锁等内容

容错性与错误恢复

访问准入控制

内存组织与管理

I/O与磁盘调度

主内存数据库系统

不精确计算问题

放松的可串行化问题

实时SQL

实时事务的可预测性

研究现状与发展实时数据库系统最早出现在1988年3月的ACMSIGMODRecord的一期专刊中。随后，一个成熟的研究群体逐渐出现，这标志着实时领域与数据库领域的融合，标志着实时数据库这个新兴研究领域的确立。此后，出现了大批有关实时数据库方面的论文和原型系统。人机交互技术与智能信息处理实验室实时数据库小组一直致力于实时系统、实时智能、实时数据库系统及相关技术的研究与开发，并取得了一定的成绩。

在Oracle数据库中 创建索引虽然比较简单 但是要合理的创建索引则比较困难了 笔者认为 在创建索引时要做到三个适当 即在适当的表上 适当的列上创建适当数量的索引 虽然这可以通过一句话来概括优化的索引的基本准则 但是要做到这一点的话 需要数据库管理员做出很大的努力 具体的来说 要做到这个三个适当有如下几个要求

一 根据表的大小来创建索引

虽然给表创建索引 可以提高查询的效率 但是数据库管理员需要注意的是 索引也需要一定的开销的 为此并不是说给所有的表都创建索引 那么就可以提高数据库的性能 这个认识是错误的 恰恰相反 如果不管三七二十一 给所有的表都创建了索引 那么其反而会给数据库的性能造成负面的影响 因为此时滥用索引的开销可能已经远远大于由此带来的性能方面的收益 所以笔者认为 数据库管理员首先需要做到 为合适的表来建立索引 而不是为所有的表建立索引

一般来说 不需要为比较小的表创建索引 如在一个ERP系统的数据库中 department表用来存储企业部门的信息 一般企业的部分也就十几个 最多不会超过一百个 这 条记录对于人来说 可能算是比较多了 但是对于计算机来说 这给他塞塞牙缝都还不够 所以 对类似的小表没有必要建立索引 因为即使建立了索引 其性能也不会得到很大的改善 相反索引建立的开销 如维护成本等等 要比这个要大 也就是说 付出的要比得到的多 显然违反常理

另外 就是对于超大的表 也不一定要建立索引 有些表虽然比较大 记录数量非常的多 但是此时为这个表建立索引并一定的合适 如系统中有一张表 其主要用来保存数据库中的一些变更信息 往往这些信息只给数据库管理员使用 此时为这张表建立索引的话 反而不合适 因为这张表很少用到 只有在出问题的时候才需要查看 其次其即使查看 需要查询的纪录也不会很多 可能就是最近一周的更新记录等等 对于对于一些超大的表 建立索引有时候往往不能够达到预计的效果 而且在打表上建立索引 其索引的开销要比普通的表大的多 那么到底是否给大表建立索引呢笔者认为 主要是看两个方面的内容 首先是需要关注一下 在这张大表中经常需要查询的记录数量 一般来说 如果经常需要查询的数据不超过 %到 %的话 那就没有必要为其建立索引的必要 因为此时建立索引的开销可能要比性能的改善大的多 这个比例只是一个经验的数据 如果数据库管理员需要得出一个比较精确的结论 那么就需要进行测试分析 即数据库管理员需要测试一下全表扫描的时间 看看其是否比建立索引后的查询时间要长或者短 如果是长的话 则说明有建立索引的必要 但是如果没有的话 则说明还是全表扫描速度来的快 此时也就没有必要建立索引了

总之 在考虑是否该为表建立索引时 一般来说小表没有建立索引的必要 而对于打表的话 则需要进行实际情况实际分析 简单一点的 可以根据大致的比率来确定 如果要精确一点的 则可以进行全表扫描性能分析 以判断建立索引后是否真的如预期那样改善了数据库性能

二 根据列的特征来创建索引

列的特点不同 索引创建的效果也不同 数据库管理员需要了解为哪些列创建索引可以起到事倍功半的效果 同时也需要了解为哪些列创建索引反而起到的是事倍功半的效果 这有利于他们了解到底给为怎么样的字段建立索引

根据笔者的经验 往往为如下特征的列创建索引能够起到比较明显的效果 如对于一些重复内容比较少的列 特别是对于那些定义了唯一约束的列 在这些列上建立索引 往往可以起到非常不错的效果 如对于一些null值的列与非Null值的列混合情况下 如果用户需要经常查询所有的非Null值记录的列 则最好为其设置索引 如果经常需要多表连接查询 在用与连接的列上设置索引可以达到事半功倍的效果

可见 索引设置的是否恰当 不仅跟数据库设计架构有关 而且还跟企业的经济业务相关 为此 对于一些套装软件 虽然一开始数据库管理员已经做了索引的优化工作 但是随着后来经济数据的增加 这个索引的效果会越来越打折扣 这主要是因为记录的表化影响到了索引优化的效果 所以笔者建议各位数据库管理员 即使采用的是大牌软件公司的套装软件 也需要隔一段时间 如一年 对数据库的索引进行优化 该去掉的去掉 该调整的调整 以提高数据库的性能

如在数据库中有一张表是用来保存用户信息的 其中有个字段身份z号码 这是一个唯一的字段 在数据库设计时 给这个字段创建了索引 但是当这个数据库投入使用之后 用户不怎么输入用户的身份z号码 而且平时也基本不按这个号码来进行查询 当记录月来月多时 这个身份z号码上的索引字段不但不能够改善数据库的查询性能 反而成了鸡肋 对于这些有很多NULL值的列 而且不会经常查询所有的非NULL值记录的列 数据库管理员要下决心 即使清除这些列上的索引

所以说索引的优化与调整是一个动态的过程 并不是说数据库设计好之后就不需要经过调整 数据库管理员往往需要根据记录的变化情况 来进行适当的变更 以提高索引的效果

三 在一个表上创建多少索引合适

虽然说 在表上创建索引的数量没有限制 但是决不是越多越好 也就是说 在创建索引这项事情上 + 〉 往往不成立 有时候 创建索引越多 其可能会得到适得其反的效果 那么在一个表上 到底给创建多少索引合适呢这个没有一个明确的标准 而是需要数据库管理员根据实际的用途以及数据库中记录的情况 来进行判断

通常来说 表的索引越多 其查询的速度也就越快 但是 表的更新速度则会降低 这主要是因为表的更新(如往表中插入一条记录)速度 反而随着索引的增加而增加 这主要是因为 在更新记录的同时需要更新相关的索引信息 为此 到底在表中创建多少索引合适 就需要在这个更新速度与查询速度之间取得一个均衡点 如对于一些数据仓库或者决策型数据库系统 其主要用来进行查询 相关的记录往往是在数据库初始化的时候倒入 此时 设置的索引多一点 可以提高数据库的查询性能 同时因为记录不怎么更新 所以索引比较多的情况下 也不会影响到更新的速度 即使在起初的时候需要导入大量的数据 此时也可以先将索引禁用掉 等到数据导入完毕后 再启用索引 可以通过这种方式来减少索引对数据更新的影响 相反 如果那些表中经常需要更新记录 如一些事务型的应用系统 数据更新 *** 作是家常便饭的事情 此时如果在一张表中建立过多的索引 则会影响到更新的速度 由于更新 *** 作比较频繁 所以对其的负面影响 要比查询效率提升要大的多 此时就需要限制索引的数量 只在一些必要的字段上建立索引

笔者在平时数据库优化时 往往会根据这些表的用途来为列设置索引 可以查询相关的动态视图 看看对于这张表的 *** 作 是更新 *** 作(包括更新 删除 插入等等)占的比例大 还是查询 *** 作占的比例大 当过多的索引已经影响到更新 *** 作的速度时 则数据库管理员就需要先禁用某些索引 以提高数据库的性能

lishixinzhi/Article/program/Oracle/201311/18407

诊断思路

mpstat -P ALL 1，查看cpu使用情况，主要消耗在sys即os系统调用上

perf top，cpu主要消耗在_spin_lock

生成perf report查看详细情况

CPU主要消耗在mutex争用上，说明有锁热点。

采用pt-pmp跟踪mysqld执行情况，热点主要集中在mem_heap_alloc和mem_heap_free上。

Pstack提供更详细的API调用栈

Innodb在读取数据记录时的API路径为

row_search_for_mysql --》row_vers_build_for_consistent_read --》mem_heap_create_block_func --》mem_area_alloc --》malloc --》  _L_unlock_10151 --》__lll_unlock_wait_private

row_vers_build_for_consistent_read会陷入一个死循环，跳出条件是该条记录不需要快照读或者已经从undo中找出对应的快照版本，每次循环都会调用mem_heap_alloc/free。

而该表的记录更改很频繁，导致其undo history list比较长，搜索快照版本的代价更大，就会频繁的申请和释放堆内存。

Linux原生的内存库函数为ptmalloc，malloc/free调用过多时很容易产生锁热点。

当多条 SQL 并发执行时，会最终触发os层面的spinlock，导致上述情形。

解决方案

将mysqld的内存库函数替换成tcmalloc，相比ptmalloc，tcmalloc可以更好的支持高并发调用。

修改mycnf，添加如下参数并重启

[mysqld_safe]malloc-lib=tcmalloc

上周五早上7点执行的 *** 作，到现在超过72小时，期间该实例没有再出现cpu长期飙高的情形。

以下是修改前后cpu使用率对比

关于传统企业物流仓储系统优化的十个最基本的原则

对于大多数的企业来说，物流系统优化是其降低供应链运营总成本的最显著的商机所在。但是，物流系统优化过程不仅要投入大量的资源，而且是一项需要付出巨大努力，克服困难和精心管理的过程。下面，我为大家分享传统企业物流仓储系统优化的十个最基本的原则，希望对大家有所帮助!

数据(Data)——数据必须准确、及时和全面

数据驱动了物流系统的优化过程。如果数据不准确，或有关数据不能够及时地输入系统优化模型，则由此产生的物流方案就是值得怀疑的。对必须产生可 *** 作的物流方案的物流优化过程来说，数据也必须全面和充分。例如，如果卡车的体积限制了载荷的话，使用每次发货的重量数据就是不充分的。

集成(Integration)——系统集成必须全面支持数据的自动传递

因为对物流系统优化来说，要同时考虑大量的数据，所以，系统的集成是非常重要的。比如，要优化每天从仓库向门店送货的过程就需要考虑订货、客户、卡车、驾驶员和道路条件等数据。人工输入数据的方法，哪怕是只输入很少量的数据，也会由于太花时间和太容易出错而不能对系统优化形成支持。

表述(Delivery)——系统优化方案必须以一种便于执行、管理和控制的形式来表述

由物流优化技术给出的解决方案，除非现场 *** 作人员能够执行，管理人员能够确认预期的投资回报已经实现，否则就是不成功的。现场 *** 作要求指令简单明了，要容易理解和执行。管理人员则要求有关优化方案及其实施效果在时间和资产利用等方面的关键标杆信息更综合、更集中。

目标(Objectives)——设定的目标必须是定量的和可测评的

制定目标是确定我们预期愿望的一种方法。要优化某个事情或过程，就必须确定怎样才能知道目标对象已经被优化了。使用定量的目标，计算机就可以判断一个物流计划是否比另一个更好。企业管理层就可以知道优化的过程是否能够提供一个可接受的投资回报率(Return On Investment)。比如，一项送货作业可能被确定的目标是“日常分摊的资产使用成本，燃料和维修成本，以及劳动力成本之和最小”。这些成本目标既定量，也容易测定。

模型(Models)——模型必须忠实地反映实际的物流过程

建立模型是把物流运营要求和限制条件翻译成计算机能够理解和处理的某种东西的方法。例如，我们需要一个模型来反映货物是如何通过组合装上卡车的'。一个非常简单的模型，诸如发货的总重量或总体积就能够忠实地反映某些货物的装载要求，如大宗液体货物。然而，如果总重量或总体积模型被用于往拖车上装载新汽车，则该模型就会失效，因为它不能充分地反映实际的物流情况。比如，用“可运载45000磅汽车”来描述拖车的载货能力就是不适用的。

因为，拖车所能够装运汽车的数量取决于汽车的外形，拖车的结构，和其他一些因素。在这种情况下，如果使用简单的重量或体积模型，许多计算机认为合适的载荷将无法实际装车，而实际上更好的装载方案会由于计算机认为不合适而被放弃。所以，如果模型不能忠实地反映装载的过程，则由优化系统给出的装车解决方案要么无法实际执行，要么在经济上不合算。

回报(ROI)——投资回报必须是可以证实的，必须考虑技术、人员和 *** 作的总成本

物流系统优化从来就不是免费的午餐。它要求大量的技术和人力资源投入。要证实物流系统优化的投资回报率，必须把握两件事情： 一是诚实地估计全部的优化成本;二是将优化技术给出的解决方案逐条与标杆替代方案进行比较。

在计算成本的时候，企业对使用物流优化技术的运营成本存在着强烈的低估现象，尤其是在企业购买的是“供业余爱好者自己开发使用”的基于PC的软件包的情况下。这时要求企业拥有一支训练有素的使用者团队和开发支持人员在实际运行的过程中调试技术系统。在这种情况下，有效使用物流优化技术的实际年度运营成本极少有低于技术采购初始成本的(如软件使用许可费、工具费等)。如果物流优化解决方案的总成本在第二年是下降的，则很可能该解决方案的质量也会成比例的下降。

在计算回报的时候，要确定物流优化技术系统的使用效果，必须做三件事：一是在实施优化方案之前根据关键绩效指标(Key Performance Indicators)测定基准状态。二是将实施物流优化技术解决方案以后的结果与基准状态进行比较。三是对物流优化技术系统的绩效进行定期的评审。

要准确地计算投资回报率必须采用良好的方法来确定基准状态，必须对所投入的技术和人力成本有透彻的了解，必须测评实际改进的程度，还必须持续地监测系统的行为绩效。但是，因为绩效数据很少直接可得，而且监测过程需要不间断的实施，所以，几乎没有哪个公司能够真正了解其物流优化解决方案的实际效果。

算法(Algorithms)——算法必须灵活地利用独特的问题结构

不同物流优化技术之间最大的差别就在于算法的不同(借助于计算机的过程处理方法通常能够找到最佳物流方案)。关于物流问题的一个无可辩驳的事实是每一种物流优化技术都具有某种特点。为了在合理的时间段内给出物流优化解决方案就必须借助于优化的算法来进一步开发优化技术。因此，关键的问题是：

(1)这些不同物流优化技术的特定的问题结构必须被每一个设计物流优化系统的分析人员认可和理解。

(2)所使用的优化算法应该具有某种d性，使得它们能够被“调整”到可以利用这些特定问题结构的状态。物流优化问题存在着大量的可能解决方案(如，对于40票零担货运的发货来说，存在着1万亿种可能的装载组合)。如果不能充分利用特定的问题结构来计算，则意味着要么算法将根据某些不可靠的近似计算给出一个方案，要么就是计算的时间极长(也许是无限长)。

计算(Computing)——计算平台必须具有足够的容量在可接受的时间段内给出优化方案

因为任何一个现实的物流问题都存在着大量可能的解决方案，所以，任何一个具有一定规模的问题都需要相当的计算能力支持。这样的计算能力应该使得优化技术既能够找到最佳物流方案，也能够在合理的时间内给出最佳方案。显然，对在日常执行环境中运行的优化技术来说，它必须在几分钟或几小时内给出物流优化方案(而不是花几天的计算时间)。采取动用众多计算机同时计算的强大的集群服务和并行结构的优化算法，可以比使用单体PC机或基于工作站技术的算法更快地给出更好的物流优化解决方案。

人员(People)——负责物流系统优化的人员必须具备支持建模、数据收集和优化方案所需的领导和技术专长

优化技术是“火箭科学”，希望火箭发射后能够良好地运行而没有“火箭科学家”来保持它的状态是没有可能的。这些专家必须确保数据和模型的正确，必须确保技术系统在按照设计的状态工作。现实的情况是，如果缺乏具有适当技术专长和领导经验的人的组织管理，复杂的数据模型和软件系统要正常运行并获得必要的支持是不可能的。没有他们的大量的工作，物流优化系统就难以达到预期的目标。

过程(Process)——商务过程必须支持优化并具有持续的改进能力

物流优化需要应对大量的在运营过程中出现的问题。物流目标、规则和过程的改变是系统的常态。所以，不仅要求系统化的数据监测方法、模型结构和算法等能够适应变化，而且要求他们能够捕捉机遇并促使系统变革。如果不能在实际的商务运行过程中对物流优化技术实施监测、支持和持续的改进，就必然导致优化技术的潜力不能获得充分的发挥，或者只能使其成为“摆设”。

;

软件结构设计的优化准则：（1）模块独立性准则，即尽量高内聚，低耦合，保持模块相对的独立性，并以此原则优化软件结构；（2）控制范围与作用范围之间的准则，一个模块的作用范围应在其控制范围之内，且条件判断所在的模块应与受其影响的模块在层次上尽量靠近；（3）软件结构的形态特征准则，软件结构的深度、宽度。扇入、扇出应适当；（4）模块的大小准则，模块的大小最好控制在50~150条语句左右，以便于阅读研究；（5）模块的接口准则，模块的接口要简单。清晰及含义明确，以便于理解、实现、测试和维护。

麻烦采纳，谢谢!

以上就是关于建立数据库的原则（怎样建立一个好的数据库）全部的内容，包括:建立数据库的原则（怎样建立一个好的数据库）、详解mysql的limit经典用法及优化实例、数据库有哪些类等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！