精华内容
下载资源
问答
  • 数据库设计重要性和设计原则

    千次阅读 2017-02-22 11:47:42
    数据库设计重要性和设计原则

    说起数据库设计,相信大家都明白怎么回事,但说起数据库设计的重要性,我想大家也只是停留在概念上而已,到底如何重要?怎么重要呢?今天就将我至今为止的理解向大家阐述下。

    一个不良的数据库设计,必然会造成很多问题,轻则增减字段,重则系统无法运行。我先来说说数据库设计不合理的表现吧:

    1. 与需求不符

    因为这个原因造成的改动量往往是最大。如果进入编码阶段的话,很可能会直接让你崩溃掉。

    2. 性能低下

    含有大数据量的表之间的关联过多;没有合理的字段设计来用于查询而造成的SQL查询语句很复杂;对于大数据量的表没有采用有效的手段去处理;滥用视图等。

    3. 数据完整性丧失

    含有主外键关系的表之间关联字段的设计方式不合理,造成更新与删除操作后程序容易出错或不完善;使用了已经删除或丢失掉的数据。

    4. 可扩展性性太差

    表设计的与业务绑定的太紧密、单一,造成表的可拓展性、可修改性太差,无法新需求的要求。

    5. 非必要数据冗余量太大

    没用的垃圾数据存储过多,不仅占用资源,还影响查询效率。

    6. 不利于计算或统计

    缺少必要的联系性或统计性字段或用于计算统计的字段分散于多个表中,造成计算统计的步骤繁琐,甚至无法计算统计。

    7. 没有详尽的数据记录信息

    缺少必要的字段,造成无法跟踪数据变化、用户操作,也无法进行数据分析。

    8. 表之间的耦合性太大

    多张表之间关联的过于紧密,造成一张表发生变化而影响到其他表。

    9. 字段设计考虑不周

    字段长度过短或字段类型过于明确,造成可发挥、可拓展的空间太小。

    大多数的程序员对于软件开发的出发点认识不是很明确,总是认为实现功能才是重要的,在简单了解完基本需求后就急忙进入编码阶段,对于数据库设计思考的比较少、比较简单,大多设计都只停留在表面上,这往往是要命的,会为系统留下很多隐患。要么是写代码开发过程中才发现问题,要么就是系统上线运转后没多久就出现问题,还有可能给后期维护增加了很多工作量。如果到了那个时候再想修改数据库设计或进行优化等同于推翻重来。

    数据库是整个软件应用的根基,是软件设计的起点,它起着决定性的质变作用,因此我们必须对数据库设计高度重视起来,培养设计良好数据库的习惯,是一个优秀的软件设计师所必须具备的基本素质条件!

    那么我们要做到什么程度才是对的呢?下面就说说数据库设计的原则

    1.  数据库设计最起码要占用整个项目开发的40%以上的时间

    数据库是需求的直观反应和表现,因此设计时必须要切实符合用户的需求,要多次与用户沟通交流来细化需求,将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确,就要分析不确定的因素,设计表时就要事先预留出可变通的字段,正所谓“有备无患”。

    2.  数据库设计不仅仅停留于页面demo的表面

    页面内容所需要的字段,在数据库设计中只是一部分,还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段,因此数据库设计绝对不是简单的基本数据存储,还有逻辑数据存储。

    3.  数据库设计完成后,项目80%的设计开发在你脑海中就已经完成了

    每个字段的设计都是有他必要的意义的,你在设计每一个字段的同时,就应该已经想清楚程序中如何去运用这些字段,多张表的联系在程序中是如何体现的。换句话说,你完成数据库设计后,程序中所有的实现思路和实现方式在你的脑海中就已经考虑过了。如果达不到这种程度,那当进入编码阶段后,才发现要运用的技术或实现的方式数据库无法支持,这时再改动数据库就会很麻烦,会造成一系列不可预测的问题。

    4.  数据库设计时就要考虑到效率和优化问题

    一开始就要分析哪些表会存储较多的数据量,对于数据量较大的表的设计往往是粗粒度的,也会冗余一些必要的字段,已达到尽量用最少的表、最弱的表关系去存储海量的数据。并且在设计表时,一般都会对主键建立聚集索引,含有大数据量的表更是要建立索引以提供查询性能。对于含有计算、数据交互、统计这类需求时,还要考虑是否有必要采用存储过程。

    5.  添加必要的(冗余)字段

    像“创建时间”、“修改时间”、“备注”、“操作用户IP”和一些用于其他需求(如统计)的字段等,在每张表中必须都要有,不是说只有系统中用到的数据才会存到数据库中,一些冗余字段是为了便于日后维护、分析、拓展而添加的,这点是非常重要的,比如黑客攻击,篡改了数据,我们便就可以根据修改时间和操作用户IP来查找定位。

    6.  设计合理的表关联

    若多张表之间的关系复杂,建议采用第三张映射表来关联维护两张表之间的关系,以降低表之间的直接耦合度。若多张表涉及到大数据量的问题,表结构尽量简单,关联也要尽可能避免。

    7.  设计表时不加主外键等约束性关联,系统编码阶段完成后再添加约束性关联

    这样做的目的是有利于团队并行开发,减少编码时所遇到的问题,表之间的关系靠程序来控制。编码完成后再加关联并进行测试。不过也有一些公司的做法是干脆就不加表关联。

    8.  选择合适的主键生成策略

    主键生成策略大致可分:int自增长类型(identity、sequence)、手动增长类型(建立单独一张表来维护)、手动维护类型(如userId)、字符串类型(uuid、guid)。int型的优点是使用简单、效率高,但多表之间数据合并时就很容易出现问题,手动增长类型和字符串类型能很好解决多表数据合并的问题,但同样也都有缺点:前者的缺点是增加了一次数据库访问来获取主键,并且又多维护一张主键表,增加了复杂度;而后者是非常占用存储空间,且表关联查询的效率低下,索引的效率也不高,跟int类型正好相反。

    终上所述,我们可见数据库设计在整个软件开发的起到的举足轻重的作用,尤其是我说的设计原则的第一点,数据库与需求是相辅相成的,我经常把软件开发比作汽车制造。汽车制造会经过图纸设计,模型制作,样车制造,小批量试生产,最后是批量生产等步骤。整个过程环环相扣,后一过程是建立在前一过程正确的前提基础之上的。如果在图纸设计阶段发现了一个纰漏,我们可以重新进行图纸设计,如果到了样车制造阶段发现这个错误,那么我们就要把从图纸设计到样车制造的阶段重来,越到后面发现设计上的问题,所付出的代价越大,修改的难度也越大。

    数据库设计难度其实要比单纯的技术实现的难很多,他充分体现了一个人的全局设计能力和掌控能力,所以在今后的项目中大家一定要着重培养这方面的能力,这里我将我的经验分享给了大家,希望能对大家有所帮助。

    展开全文
  • 关于数据库设计重要性

    千次阅读 2018-01-22 15:29:00
    关于数据库设计重要性 web开发是面向数据集的开发,我们开发人员对现实世界的抽象的一步就是建立表(或者你可以理解成类),而且在关系型数据的设计中,我是非常看重三范式!!!非常!!!,因为table是一切的...

    关于数据库设计的重要性

      web开发是面向数据集的开发,我们开发人员对现实世界的抽象的一步就是建立表(或者你可以理解成类),而且在关系型数据的设计中,我是非常看重三范式!!!非常!!!,因为table是一切的源头,如果你的表设计不合理;那么你上层的代码也跟着错;而且后面的设计,将会错的各种离谱,我已经不想吐槽!!

    这里,我会屡屡序序的完整这篇文章,讲讲个人对三范式的理解和它重要性;我们先提概念,再结合实际来一步一步的分析;

    我先从简单的,一步一步的深入; 

     

    总的来说分成两部分!

    1.实体的设计

    2.实体关系的设计

     

    实体设计原则一:原子性,不可分割性

            比如product 中有一字段是价格,而我们的价格可以继续再分(进价 卖价);如果设计为一个字段,将带来一定的模糊性

    实体设计原则二:完全依赖主键,不存在部分依赖(可以理解成一个表只存一个实体相关的信息)

          sId,name,classNo,className

     这样的设计,明显不合理,应该拆分成两个表

     

    实体设计原则三:不存在非主键属性之间的依赖(就是字段与字段之间不存在依赖性)

         这一点是对第二原则的进一步补充;如:jobName 和 jobDescript 两个字段就有一定的依赖性;如果存在这样的依赖,就会导致jobDescript的重复出现;

    其实,跟人觉得这个问题都不大~

     

    2.实体关系的设计

    1.一对一

    2.一对多

    3. 多对多

     关系的设计体现在我们的设计的合理性和约束的合理性;

     

    问题一,关系混乱,将jion后的数据数据,记录在一张表中!

    如: 

    张三 语文 60

    张三 数学 70

    张三 外语 80

     

    这个数据应该是,姓名表,课程表,成绩表,三张表jion之后的数据!!而不是所谓的“”成绩表“”,如果就这样设计,我们看看带来的问题;

    1.Create

    一数据重复:

      1.姓名重复:明显看出如果,张三选了十门课程,那么张三会重复十次!

      2.课程重复:明显看出如果,语文背全班60个同学选择,那么结果就是语文会重复60次!

    2.修改
      

    还有一种关系如:产品类别和产品之间的关系建立(应该是一对多,应该没问题吧);

    假设,我们这里用codefirst 方式来模拟建表的过程;

    比如,一个类别有多个产品;表设计如下!!!

        /// <summary>
        /// 类别信息;
        /// </summary>
        public class Category
        {
            public string Id { get; set; }
    
            public string CategoryName { get; set; }
    
            public string Remark { get; set; }
    
            public string ProuductIds { get; set; }
    
        }

    产品表

        /// <summary>
        /// 产品表
        /// </summary>
        public class Product
        {
            public string Id { get; set; }
    
            public string Name { get; set; }
    
        }

    类别和产品的关系我们通过ProuductIds 关联起来,中间用逗号分开!!也就想像这样(1,2,3,4,5)

    然后,我们来看存在的问题;

    1.Create

           Insert into Category(CategoryName,Remark,ProductIds) values ('nicke鞋','鞋','1,2,3,4,5,6')  --假设有五种产品;

    问题,如果6 这个产品不存在,导致的结果就是:添加不存在的产品!!!

     

    2.Update

     

     更新到简单,我们可以直接覆盖原来的数据;把ProductIds=(‘1,2,3,4,5,6’)  跟新为 ProductIds=(‘1,2,3,7’) 

    问题:由于缺乏数据一致性的约束,我们同样可能将不存在的数据(产品)添加进去

     

    3.Delete

         如果是全部删除,那还没什么问题,直接清空,ProductIds=(‘1,2,3,4,5,6’)  跟新为 ProductIds=(‘’) 

     如果只是更新部(删除)部分呢,同样,由于缺乏数据一致性的约束,导致,我们更新一些,不存在的产品;

     

    正确的设计应该是,在Product中建立外键关联;如下

        /// <summary>
        /// 产品类别信息;
        /// </summary>
        public class Category
        {
            public string Id { get; set; }
    
            public string CategoryName { get; set; }
    
            public string Remark { get; set; }
    
        }
    
        /// <summary>
        /// 产品表
        /// </summary>
        public class Product
        {
            public string Id { get; set; }
    
            public string Name { get; set; }
    
            public string CategoryId { get; set; }
        }

     

    上面的设计,其实体现的是主外键的约束的重要性;如果少了约束可能导致的问题

    1.Create

    添加一个不存在的数据!(如在添加产品是,你将该产品附属到一个不存在的类别上!)

    2.Detele

    删除一个有依赖项目数据!如(某个角色下还有用户,你就将用户个删除了!)

    3.Update

      更新得不到通知!

     

    数据冗余问题一!

    在实际的开发中,我们可能常常会获取产品名称的同时获取他的额产品类别名称;有些同学为了获取方便(避免join获取数据)设计成这样!

        /// <summary>
        /// 产品表
        /// </summary>
        public class Product
        {
            public string Id { get; set; }
    
            public string Name { get; set; }
    
            public string CategoryId { get; set; }
    
            /// <summary>
            /// 产品名称
            /// </summary>
            public string CategoryName { get; set; }
        }

    在添加的是偶,添加产品信息的同时 保存 CategoryId的同时,保存CategoryName;!!!

    这样在查询的时候,确实方便了不少,因为不用join去获取类别名称,但是问题来了;!!

    如果Category 表中CategoryName改变了,你是不是要改变Product表中的CategoryName呢?

    所以建议不要去冗余那个CategoryName!因为category中的数据更新,product 中的数据得不到”更新通知”

    这样就无法维持数据的一直性!!!!!

     

    数据冗余问题二!

    还有一些关于数据不合理,然后导致数据冗余,居然有些开发者,说为了提高查询效率,避免jion;真的醉了;

    我们来看实际的场景;在关系型数据库中,主外键的约束带来了数据一致性的维护!同时也带了一个查询的问题;

    那就是我们的join的代价,(这个也是我们nosql出现的重要原因);这里要强调的是“千万别装逼!”,不要很小的数据,也在哪里提什么join的代价!shit!

     

    noslq的应用场景;

    1.对数据的一致性要求不高;

    2.外键相关联的表的数据表的变动非常小,

    3.数据量特别,根本不敢去join!

    如:

     

        博客,和评论;和评论的信息,如果每次去取数据都通过join的话,那么开销是非常大的;而且评论一旦定了之后,变的几率比较小;

       我们就可以利用MongoDB,json方式,存储这种结构化的数据!

    {
      "type": "post",
      "name": "Raven's Map/Reduce functionality",
      "blog_id": 1342,
      "post_id": 29293921,
      "tags": ["raven", "nosql"],
      "post_content": "<p>...</p>",
      "comments": [
        { 
          "source_ip": '124.2.21.2',
          "author": "martin",
          "text": "..."
      }]
    }

     

    数据库的设计了体现了我们队现实世界的抽象过程!那么往一一层走就是我们oop设计的能力了,也就是我们c#的写的能力了!

     

    转载于:https://www.cnblogs.com/mc67/p/8329224.html

    展开全文
  • 由浅入深,给一个网站设计数据库是一种技能。为了达到这个技能的熟练程度,我觉得有必要梳理一下。

    由浅入深,给一个网站设计好数据库是一种技能。为了达到这个技能的熟练程度,我觉得有必要梳理一下。

    以下书单由浅入深,是按照时间顺序需要学习的。


    1.初级阶段

    《Head First SQL》这本书讲透了数据库的设计思想,菜鸟必备,也是不知道数据库设计思想的人需要学习的。缺点:冗长。建议:看英文版。一举两得。

    这个阶段还需要学会使用Visio画E-R图,对于数据库对象的关系具有莫大裨益,也有利于表的设计以及数据库的展示与后期的维护。


    2.中级阶段

    实践


    3.高级阶段

    《SQL技术手册》——供查阅之用



    数据库设计出来以后,如何被.NET网站使用呢?

    通过上课听老师的话,对使用方法有个印象,看看《Programming ASP.NET 3.5》一书的第7章,了解数据库和数据源控件的关系并简单使用数据库,看《Programming ASP.NET 3.5》的第8、9两章达到天人合一的数据库使用境界。


    本文略显肤浅,数据库应用新手,恳请大家批评指正,则其乐无穷是也 。

    展开全文
  • 数据库设计重要性与几个原则

    万次阅读 2016-09-15 21:20:04
    数据库设计 分离主体与附属 冗余 应对新需求 冷热分离

    随着工作经验的积累,我日益感觉到,对一名程序员来说,拥有良好的数据库设计能力是很重要的,甚至是最重要的。

    程序员界有一句著名的话

    Talk is cheap, show me the code
    

    把这句话演变一下,就成了

    Code is boring, show me the data structure
    

    面对同样的数据结构,一百个程序员会写出一百种风格的代码。看别人写的代码,往往是很boring的。

    数据结构为何如此重要

    代码是围绕数据结构运行的。
    

    客户端展现的动态数据,都是存储在数据库中,这对程序员来说一定是常识了。

    为了便于阐述,我们拿简书的文章页面作为样板。

    文章的作者、标题、正文、评论、喜欢等等,只要你打开任意两篇文章,两个页面不一样的地方,几乎都是因为在数据库中存储的内容不同。

    良好的数据结构可以提升性能,使代码变得简单、清晰。数据结构清晰了,围绕着数据运行的代码自然就清晰了。

    数据库设计需考虑的因素

    提到数据库设计原则,首先会想到第一、第二、第三范式,这些理论能了解最好,本文不再赘述了。

    从实践的角度面对一个具体的应用场景,设计数据库时应遵循哪些原则?

    满足当前需求

    数据结构的设计要能达到应用场景的要求,这是最基本的。举个例子,文章的正文存储在了数据表中的某个字段,该字段的长度被设定为10000字,在文章字数没有被限制在10000字以内的前提下,这显然不能满足应用场景的当前需求。需要考虑,什么样的字段类型才能存储大规模的文本数据?

    分离主体与附属

    文章页面中的元素,哪些是主体部分,哪些是附属部分?

    一篇文章可以没有评论,评论的有无、多少不影响文章本身的完整性,评论可以被添加、删除。由此可见,文章的评论属于附属部分。阅读次数、喜欢该文章的用户与数量同样如此。

    主体

    • 作者
    • 标题
    • 正文(字数)
    • 发布时间
    • 更新时间

    附属

    • 阅读次数
    • 评论
    • 喜欢该文章的用户与数量

    拆分的好处在于,首先数据结构更清晰了,其次可以提高读写性能。当文章有了新评论,只需更新存放评论的表。如果不拆分,需要更新的记录占用的磁盘空间很大,这对磁盘IO速度是个考验。

    适当的冗余

    或许你已经注意到了,文章的标题下面有这篇文章的字数。计算文章的字数,有两个时机:

    • 保存文章时
    • 读取文章时

    后者的优势在于数据表中少了一个字段,而且这个字段不是必需的。哪个时机更好?个人觉得前者更好,理由如下

    • 计算长篇文章的字数是比较耗时的,应尽量减少计算次数
    • 总体来看,文章的保存次数远小于读取次数

    如果能够提高应用的性能,适当的冗余是必要的。

    页面的头部有文章作者的昵称,这适合作为冗余字段存储在文章主体数据中吗?用户可以随时更改自己的昵称,如果将昵称作为冗余字段,需要额外的工作以保持数据一致性,从这一点看,用户昵称不适合作为冗余字段。

    选择作为冗余的字段应不需要额外的工作来保持数据一致性。
    

    应对可能出现的新需求

    如何存储喜欢文章的用户信息才能做智能推荐?一个好的数据结构应该能应对可能出现的新需求。

    为了达到应用的要求,最简单的方式是将这些用户放在一条记录里,存储的字段可以是数组类型。这样设计,喜欢文章的用户信息与用户数量都能轻易获取,读写性能也很好。但对于“喜欢该文章的人还喜欢了”此类的智能推荐,这样的设计明显是难以应对的。将用户放在数组里支持“查询喜欢某文章的用户”,对“查询某用户喜欢的文章”的支持就很差或者根本做不到了,这是一种单向查询的数据结构。

    应对大数据量

    随着用户量不断增加,网站业务数据越来越多,文章数量也达到了百万级。这时如果只把文章存在一张数据表里,读写性能必然是会急剧下降的,这可能会导致用户体验变差,用户流失。老板不能容忍,DBA也不能容忍。

    合理的解决方案之一是分为两张数据表,一张存储热门文章,另一张存储非热门文章。热门文章的占比很少,相应的加载速度就会好于非热门文章。

    结尾

    本文总结了设计数据库时需遵守的几个原则

    • 满足当前需求
    • 分离主体与附属
    • 适当的冗余
    • 应对可能出现的新需求
    • 应对大数据量

    认识到数据结构的重要性,才能设计出好的数据结构。

    展开全文
  • 数据库设计重要性

    千次阅读 2019-10-04 00:45:00
    一、设计数据库的必要...良好的数据库设计: 节省数据的存储空间 能够保证数据的完整 方便进行数据库应用系统的开 糟糕的数据库设计: 数据冗余、存储空间浪费 数据更新和插入的异常 ...
  • 数据库设计

    万次阅读 2019-09-03 10:48:05
    数据库设计 关系型数据库建议在E-R模型的基础上,我们需要根据产品经理的设计策划,抽取出来模型与关系,制定出表结构,这是项目开始的第一步 在开发中有很多设计数据库的软件,常用的如power designer,db ...
  • 数据库设计概述

    千次阅读 2020-11-09 09:23:52
    数据库设计重要性 数据库设计主要设计数据库结构(数据模型)。合理的、较优的数据模型可以使用应用系统达到最佳状态,并能避免类似于文件系统那样的数据冗余、数据异常、数据不一致现象。 数据库设计步骤 数据库...
  • 规范数据库设计

    千次阅读 2021-03-29 11:11:19
    规范数据库设计 设计数据库 当数据库比较复杂的时候,我们就需要设计了 糟糕的数据库设计: 数据冗余 浪费空间 数据库插入和删除都会麻烦,异常 程序的性能差 良好的数据库设计: 节省内存空间 保证数据库的完整...
  • 数据库设计总结

    万次阅读 多人点赞 2018-04-08 23:43:12
    对于一个系统,数据库的设计是非常重要的,数据库设计决定了以后数据好不好维护。...说了这么多数据库设计重要性那么数据库设计应该考虑哪些问题呢? 一、范式与反范式的设计 范式设计的目的是为了减少数...
  • 数据库设计的基本步骤

    万次阅读 多人点赞 2017-08-13 20:52:16
    数据库设计的基本步骤 按照规范设计的方法,考虑数据库及其应用系统开发全过程,将数据库设计分为以下6个阶段 1.需求分析 2.概念结构设计 3.逻辑结构设计 4.物理结构设计 5.数据库实施 6.数据库的运行和维护   在...
  • 数据库设计(一)——数据库设计

    万次阅读 多人点赞 2018-08-30 17:30:34
    一、数据库设计简介 按照规范设计,将数据库的设计过程分为六个阶段:  A、系统需求分析阶段 B、概念结构设计阶段 C、逻辑结构设计阶段 D、物理结构设计阶段 E、数据库实施阶段 F、数据库运行与维护阶段 需求分析...
  • 数据库系统设计数据库安全

    千次阅读 2020-04-04 22:46:24
    数据库安全4.1 数据库安全概述4.1.1 数据库的不安全因素4.2 数据库安全控制4.2.1 用户身份鉴别4.2.2 存取控制4.2.3 自主存取控制方法4.2.4 授权:授予与回收4.2.5 数据库角色4.2.6 强制存取控制方法4.3 视图...
  • 学生成绩管理系统数据库设计--MySQL

    万次阅读 多人点赞 2020-06-18 13:02:04
    MySQL/SQL Server 数据库设计(学生成绩管理系统) 设计大纲 1. 项目背景及需求分析 1.1 项目背景 1.2 需求分析 1.2.1 信息需求 1.2.2 功能需求 1.2.3 安全与完整需求 2. 概念结构设计 2.1 抽象出系统实体 2.2 ...
  • 设计数据库表对系统的重要性

    千次阅读 2017-06-06 16:09:40
    之前自己做的一个成绩管理系统,一开始把数据库的表设计的太简单了,结果完成了三分之一后,着手下一个功能时才发现问题很严重。 当时我导入好几次的成绩表,同一个学生的不同考试被搞成了不同的几条数据来对待。而...
  • 数据库设计的三大范式:为了建立冗余较小、结构合理的数据库,设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库,必须...
  • 数据库设计原则

    千次阅读 2019-06-09 09:52:33
    一,数据库设计原则 1. 原始单据与实体之间的关系  可以是一对一、一对多、多对多的关系。在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体。 在特殊情况下,它们可能是一对多或多对一的...
  • MYSQL数据库设计数据库设计实例(二)
  • 数据库设计重点总结

    千次阅读 2018-09-26 00:28:56
    糟糕的数据库设计: 数据冗余、存储空间浪费 数据更新和插入的异常 程序性能差   良好的数据库设计: 节省数据的存储空间 能够保证数据的完整 方便进行数据库应用系统的开发   软件项目开发周期中数据库...
  • 浅谈数据库设计

    千次阅读 2017-06-21 17:50:21
    )[+]第一章 需求分析设计简介设计步骤需求分析重要性实例小型电子商务网站第二章 逻辑设计E-R图设计范式概要第一范式1NF第二范式2NF第三范式3NF BC范式第三章 物理设计物理设计要做什么选择哪种数据库mysql常用的...
  • 关系数据库设计理论

    千次阅读 2018-07-11 18:32:27
    关系数据库设计理论 设计一个好的关系数据库系统,关键是要设计一个好的数据库模式(数据库逻辑设计问题) 数据库逻辑设计主要解决的问题 关系数据库应该组织成几个关系模式 关系模式中包括哪些属性 ...
  • 数据库设计经验之谈

    千次阅读 2014-07-22 12:19:46
    一个成功的管理系统,是由:[50% 的业务 + 50% 的软件] 所组成,而 50% 的成功软件又有 [25% 的数据库 + 25% 的程序] 所组成,数据库设计的好坏是一个关键。如果把企业的数据比做生命所必需的血液,那么数据库的设计...
  • 试题库管理系统--数据库设计

    万次阅读 多人点赞 2017-12-28 09:14:02
    目前,许多高校绝大多数课程还采用考教统一的模式来完成教学过程,这种传统的考试模式在教学到实施考试的过程带有很大的主观随意和不规范。另外随着各高校近年来学生规模的扩大,教学任务日益繁重,教师的工作量...
  • 第7章 数据库设计 7.1 数据库设计概述 1、数据库应用系统,通常是指使用数据库的各类信息系统,比如以数据库为基础的各种管理信息系统、办公自动化系统、地理信息系统(GIS)、电子政务系统、电子商务系统等。 2、...
  • 数据库——规范数据库设计及三大范式

    千次阅读 热门讨论 2020-10-12 17:32:57
    数据库——规范数据库设计 为什么需要设计数据库 当数据库比较复杂的时候,就需要设计 糟糕的数据库设计 数据冗余,浪费空间 数据库插入和删除都会麻烦、异常(屏蔽使用物理外键) 程序性能差 良好的数据库设计 ...
  • 数据库结构设计

    千次阅读 2019-06-12 23:40:02
    数据库结构设计介绍 良好的数据库逻辑设计和物理设计数据库获得高性能的基础。这就要求我们在设计数据库时候,不能只考虑业务需要还要考虑将来要怎样使用这个数据库来编写什么样的查询语句才能得到我们想要的数据...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 492,339
精华内容 196,935
关键字:

数据库设计的重要性