14年课题相关开题之后11

1、数据库表设计的原则攻略创建数据库里最基本的应该就是建表，建索引、得不谈到实体。过程等一系列操作了。谈到表就不一、数据实体实体，客观存在并且可以相互区别的事物称为实体。这里就简单的把它理解为一个表吧，描述实体的特性，就把他们称为了属性。也可以说当把一个数据库表当作一个实体，那么它里面的所有字段是不是就是一个属性了呢？结果是肯定的。二、实体间的联系说的是，很简单，数据库里表跟表间的关系莫过于三种：一对一；多对多；一对多。一对一其实就是说建的主表跟相关联的表之间是一一对应的，比如说，我建了一个学生基本信息表：t_student,然后我又建了一个成绩表，里面有个外键，studentID，学生基本信息表

2、里的字段 studentID 和成绩表里的 studentID 就是一对一。一对多，也是类似，我另外建一个班级表，而每个班级有多个学生，每个学生就对应一个班级，对班级来说当然就是一对多了。多对多，我还举这个例子，我建个选课表，可能有许多科目，每个科目有很多学生选，而每个学生又可以选择多个科目。这就是多对多了。三、基本表的完整性(1) 原子性。基本表中的字段是不可再分解的。(2) 原始性。基本表中的是原始数据（基础数据）的。(3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。(4) 稳定性。基本表的结构是相对稳定的，表中的是要长期保存的。这是基本表的完整性，也是它特有的。这里说的

3、是，在数据库里还有几种表也是常用的那就是中间表和临时表。1、中间表中间表是针对多对多关系的，就比如做查询系统。里面有两个表，分别是车站表、线路表。这里起个名字叫：t_bussion 、t_road，根据也知道，一个站有多个线路经过，而每个线路又有多个车站，怎么才能将两个表联系起来呢，如果是一对一，一对多，一个表，两个表就可以将他们实现了，但是多对多呢，这样就必须借助中间表用来连接两个表。一般中间表都是有一个本表的自增主键，还有另外两个表的主键。中间表是没有属性的因为它不是一个基本表。2、临时表在本次项目中，就要用到临时表，首先来看看临时表吧。这是我从网上查到的。因为用的是 MS SQL Ser

4、ver 2000 数据库，而在这个数据库里是支持临时表的。临时表：其实就是那些以#号开头为名字的数据表，它主要是用来存放临时数据的，当用户断开连接但没有出去临时表里的数据时，系统会自动把临时表里的数据清空。这里一点，临时表是放在系统数据库 tempdb 中的，而不是当前数据库。临时表总共是分两种：本地临时表和全局临时表。（1）这里需要了解的就是，在数据库中本地临时表是以一个#开头的，这种临时表只对当前的数据库用户可见，而其他的用户是不可见的。当数据库实例断开后当然也就丢失了数据了，不管是显式清空还是系统回收。（2）还有一个就是全局临时表。它是以“#”开头的，而且是对于所有的用户都是可见的，当你

5、断开数据库实例连接时，只要还有别的系统项目在它，连着数据库，那么数据就存在，只有当别的系统也断开连接时，系统才会清除全局临时表的数据。下面是建立临时表的语句:本地临时表：create table #student(studentID,studentName nvarchar (40),cla)全局临时表：create table #student(studentID,studentName nvarchar (40).cla)这里也可以用 SQL 语句完成：select * from employeeo #student现在就来看看三大范式。第一范式：如果每列(或者每个属性)都是不可再分的最小

6、数据单元(也称为最小的原子单元),则满足第一范式.比如一个工人的基本信息表，里面有工人的工号，性都是不可分割的，所以这个表就符合了第一范式。，这些属第二范式： 就是在第一范式的基础上延伸，使之表里的每个字段都与主键。假如一个关系满足第一范式,并且除了主键以外的其它字段,都依赖于该主键,则满足第二范式.例如:订单表(订单、产品、定购日期、价格、)，订单为主键，产品和主键列没有直接的关系，即产品删除。列不依赖于主键列，这个列就可以把它第三范式：在第二范式的基础上更进一步，也就是为了实现表里的列都与主键列直接相关，不是间接相关。这个可以用“Armstrong 公理”中的传递规则来推理。来看一下它的定

7、义：设U 是关系模式R 的属性集，F 是R 上成立的只涉及U 中属性的函数依赖集。若 XY和 YZ 在R 上成立，则 X Z 在R上成立。因此就来看在网上搜索到的例子：例如:订单表(订单，顾客，)，初看该表没有问题，满足第，定购日期，顾客二范式，每列都和主键列订单相关，再细看你会发现顾客和顾客相关，相关。为了顾客和订单又相关，最后经过传递依赖，顾客也和订单满足第三范式，应去掉顾客列，放入客户表中。这里其实就是为了说明数据库的表里步要出现冗余，在顾客表里已经有了顾客了，而在订单表里就别出现了，而直接根据顾客相关联就可以，否则造成资源浪费。以上就是三大范式。延伸：来看这三大范式：第一范式：1NF

8、是对属性的原子性约束，要求属性具有原子性，不可再分解；第二范式：2NF 是对的惟一性约束，要求有惟一标识，即实体的惟一性；第三范式：3NF 是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。其实在设计数据库的时候最多的要遵循的就是第三范式，但是并不是越满足第三范式数据库就设计的越完美，这种错误是错误的。有时候增加点冗余相反的会提高速率，因此在实际的设计过程中应降低对范式的要求。以前对数据冗余并不是很了解，在的数据称为数据冗余. 但是不是说知道里的定义是这样的：在一个数据集合中重复表的主键在其他表里重复出现就是冗余，这不是，而是为了连接两个表。只有非键字段就是既不是主键

9、外键等约束的键如果重复出现，就会形成数据冗余。数据冗余也包括重复性冗余和派生冗余。比如工人表里有基本工资，奖金两列，然后还有一个总工资的列，这个总工资就是派生冗余。低级的重复性冗余一定要避免，杜绝，但是像派生冗余还是提倡的因为它能提高的效率。11 个重要的数据库设计规则简介在您开始阅读这篇文章之前，我得明确地告诉您，我并不是一个数据库设计领域的大师。以下列出的 11 点是我对自己在平时项目实践和阅读中学习到的经验总结出来的个人见数据库设计提供了很大的帮助。实属一家之言，欢迎拍砖 : )解。我个人认为它们对我之所以写下这篇这么完整的文章是因为，很多开发者一参与到数据库设计，就会很自然地把 “三范

10、式” 当作银弹一样来使用。他们往往认为遵循这个规范就是数据库设计的唯一标准。由于这种心态，他们往往尽管一路碰壁也会坚持把项目做下去。如果你对 “三范式” 不清楚，这里（FQ）一步一步的了解“三范式”。大家都说是重要的指导方针并且也这么做着，但是把它当作石头上的一块标记来记着（死记硬背）还是会带来麻烦的。以下 11 点是我在数据库设计时最优先考虑的规则。规则 1：弄清楚将要开发的应用程序是什么性质的（OLTP 还是 OPAP）？当你要开始设计一个数据库的时候，你应该首先要分析出你为之设计的应用程序是什么类型的，它是 “事务处理型”（Tranional） 的还是 “分析型” （ytical）的？你

11、会发现许多开发采用标准化做法去设计数据库，而不考虑目标程序是什么类型的，这样做出来的程序很快就会陷入性能、客户定制化当中。正如前面所说的，这里有两种应用程序类型， “基于事务处理” 和 “基于分析”，下面让的是什么意思。来了解一下这两种类型究竟说事务处理型：这种类型的应用程序，你的最终用户更关注数据的增查改删（CRUD，Creating/Reading/Updating/Deleting）。这种类型更加的叫法是 “OLTP” 。分析型：这种类型的应用程序，你的最终用户更关注数据分析、报表、趋势等等功能。这一类的数据库的 “” 和 “更新” 操作相对来说是比较少的。它们主要的目的是更的叫法是 “

12、OLAP” 。加快速地查询、分析数据。这种类型更加那么换句话说，如果你认为、更新、删除数据这些操作在你的程序中更为突出的话，那就设计一个规范化的表否则的话就去创建一个扁平的、不规范化的数据库结构。以下这个简单的图表显示了像左边 Names 和 Address 这样的简单规范化的表，怎么通过应用不规范化结构来创建一个扁平的表结构。规则 2：将你的数据按照逻辑意义分成不同的块，让事情做起来更简单这个规则其实就是 “三范式” 中的第一范式。这条规则的一个标志就是，你的查询使用了很多字符串函数例如 substring、charindex 等等。如此，那就需要应用这条规则了。比如你看到的下面上有一个有学

13、生名字的表，如果你想要查询学生名字中包含“Koirala”，但不包含“Harisingh”的，你可以想象一下你将会得到什么样的结果。所以更好的做法是将这个字段拆分为更次的逻辑分块，以便的表数据写起来更干净，以及优化查询。规则 3：不要过度使用 “规则 2”开发者都是一群很可爱的生物。如果你们这是一条解决问题的正路，他们就会一直这么做下去，做到过了头导致了一些不必要的。这也可以应用于刚刚面提到的规则 2。当你考虑字段分解时，先暂停一下，并且问问你自己是否真的需要这么做。正如所说的，分解应该是要符合逻辑的。号码的 ISD 代码单独分开来操例如，你可以看到号码这个字段，你很少会把作（除非你的应用程序

14、要求这么做）。所以一个很明智的决定就是让它保持原样，否则这会带来。规则 4：把重复、不的数据当成你最大的敌人来对待集中那些重复的数据然后重构它们。我个人更加担心的是这些重复数据带来的而不是它们占用了多少磁盘空间。例如下面这个图表，你可以看到 “5th Standard” 和 “Fifth standard” 是一样的意思，它们是重复数据。现在你可能会说是由于那些录入者录入了这些重复的数据或者是差劲的验证程序没有拦住，让这些重复的数据进入到了你的系统。现在，如果你想导出一份将原本在用户眼里十分困惑的数据显示为不同实体数据的，该怎么做呢？解决方法之一是将这些数据完整地移到另外一个主表，然后通过外键

15、过来。在下面“Standards”（课程级别） 的主表，然后这个图表中你可以看到是如何创建一个名为同样地使用简单的外键连接过去。规则 5：当心被分隔符分割的数据，它们了“字段不可再分”前面的规则 2 即“第一范式”说的是避免 “重复组” 。下面这个图表作为其中的一个例子解释了 “重复组”是什么样子的。如果你仔细的观察 syllabus（课程） 这个字段，会发现在这一个字段里实在是填充了太多的数据了。像这些字段就被称为 “重复组” 了。如果我们又得必须使用这些数据，那么这些查询将会十分复杂并且我也怀疑这些查询会有性能问题。这些被塞满了分隔符的数据列需要特别注意，并且一个较好的办法是将这些字段移到

16、另外一个表中，使用外键连接过去，同样地以便于更好的管理。那么，让现在就应用规则 2（第一范式） “避免重复组”吧。你可以看到上面这个图表，我创建了一个单独的 syllabus（课程） 表，然后使用 “多对多” 关系将它与 subject（科目） 表关联起来。通过这个方法，主表（student 表）的 syllabus（课程） 字段就不再有重复数据和分隔符了。规则 6：当心那些仅仅部分依赖主键的列留心注意那些仅仅部分依赖主键的列。例如上面这个图表，可以看到这个表的主键是 Roll No.+Standard。现在请仔细观察 syllabus 字段，可以看到 syllabus（课程） 字段仅仅关联（

17、依赖） Standard（课程级别） 字段而不是直接地关联（依赖）某个学生（RollNo. 字段）。Syllabus（课程） 字段关联的是学生正在学习的哪个课程级别（Standard 字段）而不是直接关联到学生本身。那如果明天要更新教学大纲（课程）的话还要为每个同学也修改一下，这明显是不符合逻辑的（不正常的做法）。更有意义的做法是将这些字段从这个表移到另外一个表，然后将它们与 Standard（课程级别）表关联起来。是如何移动 syllabus（课程）字段并且同样地附上 Standard 表。你可以看到这条规则只不过是 “三范式” 里的 “第二范式”：“所有字段都必须完整地依赖主键而不是部分依

18、赖”。规则 7：仔细地选择派生列如果你正在开发一个 OLTP 型的应用程序，那强制不去使用派生字段会是一个很好的思路，除非有迫切的性能要求，比如经常需要求和、计算的 OLAP 程序，为了性能，这些派生字段就有必要存在了。通过上面的这个图表，你可以看到 Average 字段是如何依赖 Marks 和 Subjects字段的。这也是冗余的一种形式。因此对于这样的由其他字段得到的字段，需要思考一下它们是否真的有必要存在。这个规则也被称为 “三范式” 里的第三条：“不应该有依赖于非主键的列” 。个人看法是不要盲目地运用这条规则，应该要看实际情况，冗余数据并不总是坏的。如果冗余数据是计算出来的，看看实际

19、情况再来决定是否应用这第三范式。规则 8：如果性能是关键，不要固执地去避免冗余“避免冗余” 当作是一条规则去遵循。如果对性能有迫切的需求，考虑一下打破常规。常规情况下你需要做多个表的连接操作，而在非常规的情况下这样的多表连接是会大大地降低性能的。规则 9：数据是各种不同数据的聚合OLAP 项目主要是解决数据问题。比如你下面这个图表，你会想拿到每个国家、每个顾客、每段时期的销售额情况。简单的说你正在看的销售额数据包含了三个维度的交叉。为这种情况做一个实际的设计是一个更好的办法。简单的说，你可以创建一个简单的主要销售表，它包含了销售额字段，通过外键将其他所有不同维度的表连接起来。规则 10：将那些

20、具有“名值表”特点的表起来设计很多次我都遇到过这种 “名值表” 。 “名值表” 意味着它有一些键，这些键被其他数据有 Currency（货币型）和 Country（国家）关联着。比如下面这个图表，你可以看到这两。如果你仔细观察你会发现实际上这些表都只有键和值。对于这种表，创建一个主要的表，通过一个 Type（类型）字段来区分不同的数据将会更有意义。规则 11：无限分级结构的数据，自己的主键作为外键会经常碰到一些无限父子分级结构的数据（树形结构？）。例如考虑一个多级销售。注意到都是 “销售” 。也就是说方案的情况，一个销售之下可以有多个销售数据本身都是一种。但是层级不同。这时候可以自己的主键作为

21、外键来表达这种层级关系，从而达成目的。这篇文章的用意不是叫大家不要遵循范式，而是叫大家不要盲目地遵循范式。根据你的项目性质和需要处理的数据类型来的选择。在目前的企业信息系统中，数据库还是最佳的数据方式，虽然已经有很多的书籍在指导进行数据库设计，但应该那种方式是设计数据库的表结构的最好方法、设计时应遵从什么样的原则、四个范式如何能够用式达到顺畅的应用等是我一直在思考和总结的问题，下文是我针对这几个问题根据自己的设计经历准备总结的一篇文章的提纲，欢迎大家一块进行探讨，集思广益。其中提到了领域建模的概念，但未作详细解释，希望以后能够有时间针对这个命题进行深入探讨。1)不应该针对整个系统进行数据库设计

22、，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。对象要符合封装的特性，确保与职责相关的数据项被定义在一个对象之内，这些数据项能够完整描述该职责，不会出现职责描述缺失。并且一个对象有且只有一项职责，如果一个对象要负责两个或两个以上的职责，应进行分拆。3)根据建立的领域模型进行数据库

23、表的，此时应参考数据库设计第二范式：一个表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属性，也可以是多个属性的集合，不论那种方式，都应确保关键字能够保证唯一性。在确定关键字时，应保证关键字不会参与业务且不会出现更新异常，这时，最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字。4)由于第一点所述的领域模型驱动的方式设计数据库表结构，领域模型中的每一个对象只有一项职责，所以对象中的数据项不存在传递依赖，所以，这种思路的数据库表结构设计从一开始即满足第三范式：一个表应满足第二范式，且属性间不存在传递依赖。 )同样，由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之

24、间的关系，所以在领域模型中的对象存在主对象和从对象之分，从对象是从 1N 或 NN 的角度进一步主对象的业务逻辑，所以从对象及对象关系为的表及表关联关系不存在删除和异常。 )在后得出的数据库表结构中，应再根据第四范式进行进一步修改，确保不存在多值依赖。这时，应根据反向工程的思路反馈给领域模型。如果表结构中存在多值依赖，则证明领域模型中的对象具有至少两个以上的职责，应根据第一条进行设计修正。第四范式：一个表如果满足 %&NF，不应存在多值依赖。 )在经过分析后确认所有的表都满足二、三、四范式的情况下，表和表之间的关联尽量采用弱关联以便于对表字表结构的调整和重构。并且，我认为数据库中的表是用来持久

25、化一个对象实例在特定时间及特定条件下的状态的，只是一个介质，所以，表和表之间也不应用强关联来表述业务（数据间的一致性），这一职责应由系统的逻辑层来保证，这种方式也确保了系统对于不正确数据（脏数据）的兼容性。当然，从整个系统的角度来说还是要尽最大努力确保系统不会产生脏数据，单从另一个角度来说，脏数据的产生在一定程度上也是不可避免的，也要保证系统对这种情况的容错性。这是一个折中的方案。8)应针对所有表的主键和外键建立索引，有针对性的（针对一些大数据量和常用检索方式）建立组合属性的索引，提高检索效率。虽然建立索引会消耗部分系统资源，但比较起在检索时搜索整的数据尤其时表中的数据量较大时所带来的性能影响

26、，以及无索引时的排序操作所带来的性能影响，这种方式仍然是值得提倡的。9)尽量少采用过程，目前已经有很多技术可以替代过程的功能如“对象/关系”等，将数据一致性的保证放在数据库中，无论对于版本控制、开发和部署、以及数据库的迁移都会带来很大的影响。但不可否认，过程具有性能上的优势，所以，当系统可使用的硬件不会得到而性能又是非常重要的质量属性时，可经过平衡考虑选用过程。10)当处理表间的关联约束所付出的代价（常常是使用性上的代价）超过了保证不会出现修改、删除、更改异常所付出的代价，并且数据冗余也不是主要时，表设计可以不符合四个范式。四个范式确保了不会出现异常，但也可能由此导致过于纯洁的设计，使得表结构

27、难于使用，所以在设计时需要进行综合判断，但首先确保符合四个范式，然后再进行精化修正是刚刚进入数据库设计领域时可以采用的最好办法。11)设计出的表要具有较好的使用性，主要体现在查询时是否需要关联多杂的 SQL 技巧。还需使用复12)设计出的表要尽可能减少数据冗余，确保数据的准确性，有效的控制冗余有助于提高数据库的性能浅谈数据库及表设计的几个原则对于信息管理类的程序来说，一个系统就是一个信息库。在大量的信息中为了索引、区别，最好的办法就是用数据库。然而建立一个简洁、高效、全面的数据库却并不简单。一个优秀的数据库无疑能够帮助程序员减少业务逻辑操作，减少出错的可能性；而一个糟糕的数据库设计会在需要添加

28、功能的时候无从扩展，或是大量的冗余造能的瓶颈。因此，建立一个优秀的数据库，设计好每一格变成了尤为重要的事情。然而，很多的问题考虑起来就非常的复杂和繁琐，且需要对系统的深彻把握和对程序代码的经验积累。但是吵吵认为最好的方式还是“综合考虑，利弊权衡。”如何开始你的数据库设计？也许你是拿到任务就开始建立表了，user 表、product 表等等。一张一张的完成，倒是很有速度也很有成就感，但是这绝对是的做法。因为你面向的对象是一个系统，而对付这一个系统的时候，你就需要好好思考了。对于数据库而言，最简单的理解方式：数据库就是一个系统，表就是它的对象，而字段即是它的属性。一个确保数据库事务正确执行的四个基

29、本要素是：(1)(2)(3)(4)原子性。基本表中的字段是不可再分解的。原始性。基本表中的是原始数据（基础数据）的。演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。稳定性。基本表的结构是相对稳定的，表中的是要长期保存的。基本的原则架构了。是需要遵照执行的，然而作为一个系统来考虑的话不得不考虑其整体的就Evans Heart开发而言，这些年来比较热门的当数“领域驱动设计”了。2004 年著名建模Eriche了他最具的书籍:-Driven Design Tackling Complexityof Software(中文译名：领域驱动设计复杂性应对之道)，书中提出了领域驱动设计(简称 D

30、DD)的概念。DDD 基于面象分析与设计技术，对技术架构进行了分层规划，同时对每个类进行了策略和类型的划分。因此“领域驱动设计”能够指导面象开发、系统分析和设计人员合理地组织工作，各有侧重、彼此协作，有条不紊地进行复杂系统的开发，帮助他们建立丰富而实用的领域模型，并由此创建长期适用的优质。按吵吵的理解“领域驱动设计”即是为业务和编程建立了一座沟通的桥梁，一种有效的操作和方法，其还是领域建模。这种自然是有他的借鉴之处，按照“领域驱动设计”的相互影响的话，那么建立了一个个独立的事物类，不同类之间能够通过各种的数据库的设计最好的方式是基于这些功能类的设计方法和准则，而不是基于业务和系统了，这样做的最

31、大好处区分的独立子系统能够很好的考虑其效率、冗余等各方面了。范式设计？为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。在实际开发中最为常见的设计范式有三个：1第一范式(确保每列保持原子性)2第二范式(确保表中的每列都和主键相关)3第三范式(确保每列都和主键列直接相关,而不是间接相关)按照范式设计的数据库最大的好处就是确保了数据库不会冗余，结构简单、稳定。但是，同时带来就是性能的下降，比如有一了一条数据，其中有一个字段是用户的 ID，并且大部分时候这息都

32、不需要显示，那么在这的业务只需要显示用户的名称，至于用户的你会加入用户名称这个字段么？、邮箱等信这实际上是的最多的“关联”还是不关联了，很多人说：“当然关联，不关联叫什么关系型数据库？；但是吵吵也见过一些公司做的项目完全不关联的，所有的表都是独立的表的。关联的好处：1、整洁、简单，独立性强。从整个系统来看，虽然关联多出了不少表格，但是每都是独立的，很好的了整个系统的简洁性。2、将部分逻辑业务交给了 DBA，在数据库接口层注重的是 sql 查询语句的编写，上层业务开发可以省下不少力气。3、由于关联的字段都是用主键进行查询的，减少了出错的可能性。再者，不关联的表的记录的更改可能会涉及到多格的同步问

33、题，处理不好也容易出错。4、关联的表多用到 sql 语句来完成业务与逻辑，而不关联的表可能要上层程序本身负担一部分逻辑判断的任务，这样子的逻辑与烦杂的判断，则需要多次封装继承。因此关联还是降低了程序员出错的可能性。关联的坏处：1、反复的查询一张固定的表，造成资源的重复浪费，降低了性。2、查询一条需要查询两张或者以上的表，造成执行时间的延长，降低了服务器的性能，降低了用户的体验。3、关联造成的多个外键、连接一定程序上增加了系统的复杂性。那么到底该不该关联，是部分不关联还是完全不关联？究竟要不要完全的按照范式来设计我们的数据库？这原本就是一个见仁见智理该问题的平衡点才是最终的王道吧。从功能模块出发

34、，从全局出发，找到综合处NoSQL 还是关系型数据库？关系型的数据模型定义了高度结构化的数据结构，以及对这些结构之间关系的严格定义。通过这些年的发展，关系型数据库已经提供了相当强大的复杂操作功能，但是由此也些问题：了一1、负载不确定性。使用 SQL 的一个问题就是计算某个查询的代价或者产生的负载几乎是不可能的。使用简单的查询语言可能会导致应用层的逻辑更复杂，但是这样可以将工作简单化，让它只需要响应一些简单的请求。系统的2、模型严格性。对一个问题建模有很多种方式。其中关联型的数据模型是非常严格的一种：表结构的定义规定了表中每一行数据的内容。如果你的数据结构化并没有那么强，或者对每一行数据的要求比较灵活，那可能关联型的数据模型就太过严格了。类似的，应用层的开发可能对关联型的数据结构并不满意。比如很多应用程序是用面象的语言写的，数据在这些语言中通常是以列表、队列或集合的形式组织的，程序员们当然希望他们的数据层也能和应用层的数据模型一致。3、性能瓶颈。当数据量增长到一台机器已经