摘要：多媒体文件已经广泛应用在很多程序当中。比如用户的头像，汽车的产品图片等等。 从我个人以往的经验来看，将文件的路径存储入数据库，然后文件本身存储于硬盘当中已是万年不变的解决方案。 其实，存储图片路径与存储图片文件本身，两种方案都有很好的立足点，但是大部分程序员都是将文件存储于数据库之外。虽然，这种方法没有什么大问题，但的确是存在一定的风险的。一、问题描述 下面就来论述一下关于将文件存储于数据库外部的缺点。 1、垃圾回收问题。 当你想删除一张图片时，你只能够删除掉数据库中的记录，图片文件是没有办法由SQL语句删除的，你必须在你的高级程序中维护着这些图片。保证在删除数据行的同时删除... 阅读全文

摘要：一、说明问题 其实这篇非常简单，因为大家都是用这个方法解决的，我决定用自己的语言来描述清楚这一个问题。 假设，我们有一个列，这个列只能够取某些有效值。比如一个用户表，我们有一个姓氏列，我们需要限定里面的值为中国的姓氏，比如：赵钱孙李周吴郑王冯陈褚卫蒋沈韩杨。二、反模式 对于这个问题，其实只有初学者可能会用这个方法，就是使用CHECK约束或者触发器来限定列的值，比如： CHECK (lastname IN ('赵','钱','孙','李')); 这样做的缺点如下： 1、获取所有可选值有困难，假设我要做个下拉列表，让用户选择可供输入的 阅读全文

摘要：多态关联 先说明什么是多态关联。 假设我们有一张地址表，其中的地址可能是对于User中的，也可能是对于Orders中的。 以上，只是举个例子，实际的例子还有很多，比如我们要设计一个内容管理系统(CMS)，我们的CMS有一个文章表，一个软件表。还要求支持评论，那么我们的评论表的Id是引用文章表还是引用软件表呢？ 对于以上例子的缺点，貌似书本上有故意为此多态关联的模式走软的嫌疑。缺点不说了，主要是查询麻烦，其次不能够支持外键约束。解决方案 交叉表 对于这种需要外键引用为多个表的情况，可以建立一张交叉表。让Address不再依赖Orders或Users。 优点： 引用完整性支... 阅读全文

摘要：可变属性的需求：我们需要在数据库里面存储很多电器，比如电视，冰箱等等。通常，在程序中，我们的类图为：EVA设计 对于这种继承下来的可变属性时，有一种办法是创建另外一张表，将属性当成行来存储。 其中存储的数据类似下面这样： 这样的设计称为：实体-属-值，简称：EVA，或者又叫开放架构、无模式。 这种设计有如下3种好处： 1、这两张表的列都很少。 2、新增的属性不会对现有的表结构造成影响，不需要新增列。 3、避免由于空值而造成的表内容混乱。 但是这样也有如下缺点: 1、查询属性 本来，我们想要按出厂日期查询，只需要： SELECT ElectricId,DateO... 阅读全文

摘要：我之前曾参与维护过一个舆情监控系统，该系统每天源源不断地监控着互联网上的新闻，不断从网上下载新闻保存进入数据库。提出问题 为了表述简单，我特意模拟了一张类似的表： CREATE TABLE NEWS( Id int PK, Title nvarchar(500) --新闻标题 Content text --新闻内容 CreateTime DateTime) 随着时间的推移，数据库里的新闻变得越来越多，系统开始跑得越来越慢。随后，技术经理考虑到，舆情监控需要的仅仅是近期的数据，过时的数据，不太重要。于是，新建了... 阅读全文

摘要：假设有一个要开发一个试题系统，全是不定项选择题。一道题可能有2,3,4...个答案，数据应如何设计呢？本处旨在说明问题所在，例如同类问题还有存储电话，一个人可能有多个号码等等。一、存储多值属性 反模式：创建多个列。 我们知道每列最好只存储一个值，因此先看如下设计： CREATE TABLE Question( QuestionId　int PK, QuestionBody nvarchar(500), Answer1 nvarchar(500), Answer2 nvarchar(500), Answer3 nvarchar... 阅读全文

摘要：相信有过开发经验的朋友都曾碰到过这样一个需求。假设你正在为一个新闻网站开发一个评论功能，读者可以评论原文甚至相互回复。 这个需求并不简单，相互回复会导致无限多的分支，无限多的祖先-后代关系。这是一种典型的递归关系数据。 对于这个问题，以下给出几个解决方案，各位客观可斟酌后选择。一、邻接表:依... 阅读全文

摘要：有一些开发人员不推荐使用完整性约束，你可能听过以下这么几点不使用外键的原因。 1、数据更新有可能和约束冲突。 2、当前的数据库设计如此灵活，以致于不支持引用完整性约束。 3、数据库为外键建立的索引会影响性能。 4、当前使用的数据库不支持外键。 5、定义外键的语法并不简单，还需要查阅。一、反模式：无视约束 即使第一感觉告诉你，省略外键约束能使得数据库设计更加简单、灵活，或者执行更加高效，你还是不得不在其他方面付出相应的代价 -- 必须增加额外的代码来手动维护引用完整性。 1、完整性问题 很多人对引用完整性的解决方案是通过编写特定的程序代码来确保数据间的关系的。每次插入新记录时... 阅读全文

摘要：本文的目标就是要确认那些使用了主键，却混淆了主键的本质而造成的一种反模式。一、确立主键规范 每个了解数据库设计的人都知道，主键对于一张表来说是一个很重要，甚至必需的部分。这确实是事实，主键是好的数据库设计的一部分。主键是数据库确保数据行在整张表唯一性的保障。它是定位到一条记录并且确保不会重复存储的逻辑机制。主键也同时可以被外键引用来建立表与表之间的关系。 难点是选择那一列作为主键。大多数表中的每个属性值都有可能被很多行使用。例如姓名，电子邮件地址等等都不能保证不会重复。 在这样的表中，需要引入一个对于表的域模型无意义的新列来存储一个伪值。这一列被用作这张表的主键，从而通过它来确定表中... 阅读全文

摘要：一、乱穿马路模式介绍 程序员通常使用逗号分隔的列表来避免在多对多关系中创建交叉表，这种设计方式定义为一种反模式，称为乱穿马路。 例如：在一个产品管理系统中，一个人可以有多个产品，一个产品必须对应一个人，因此有如下数据库： 但是，随着时间的推移，出现了一个产品可能会有多个联系人。于是为了最小限度地修改数据库，可能不少人会将Account_Id的类型修改成varchar，这样就可以列出该列中的多个账号Id，每个Id之间用逗号分隔。这样的设计貌似可行，因为并没有创建额外的表或者列。仅仅改变了一个字段的数据类型就成功达到目的。以下我们来列举一下这样做的缺点。改变之后的数据库外键去掉，同时Pr... 阅读全文

摘要：一、浮点类型简介 整型是一个很有用的数据类型，但只能存储整数，比如1、199、-19。但不能表述像2.5这样的浮点数。如果数据对精度要求很高，你需要使用另一种数据类型来取代整型。比如算钱的时候通常需要精确到小数点后两位，像$19.95。 在这里首先来介绍下SQLServer中的浮点数：浮点类型是否精确说明decimal精确数值型-1038次方+1~1038-1的固定精度和范围的数值型数据numeric精确数值型同decimalfloat近似数值型-1.79E+308~1.79E+308之间的浮点数real近似数值型-3.40E+38~3.40E+38之间的浮点数money货币型-263~2.. 阅读全文