ulark的专栏

 Student(S#,Sname,Sage,Ssex) 学生表 Course(C#,Cname,T#) 课程表 SC(S#,C#,score) 成绩表 Teacher(T#,Tname) 教师表 问题： 1、查询“”课程比“”课程成绩高的所有学生的学号；   SELECT a.S# FROM (SELECT s#,score FROM SC WHERE C#=0

我们来简单地看看SQL SERVER索引是如何工作的，关于索引的一些概念就不说了。聚簇索引：(图A)我们来看图A,聚簇索引的结构图。数据页就是数据库里实际存储数据的地方，可以看到是按页1页1页存的。假设那个列是”LastName”。因为是聚集索引,所以它是按照顺序排下来的。可以看到，索引是一棵树，首先先看一下这棵树是怎么形成的。先看Page100和Page110的最上面，由它们形成了Page141,Page141的第一条数据是Page100的第一条数据，Page141的最后一条数据是Page110的第一条数

建SQL SERVER索引的时候有一个选项，即Fillfactor(填充因子)。这个可能很少人会去注意它，但它也是比较重要的。大家可能也都知道有这个东西，但是如何去使用它，可能会比较迷糊。另外，即使你理解了它的原理，也不一定能使用好它，这个还要具体分析索引字段的更新频率等等。记得看书知道有这么个东西，但是都是看的迷迷糊糊的，不知道干吗的，好象设置不设置都一样的。其实，像索引这些东西，当数据达到几十万上百万的时候，它的效果就表现的很明显。填充因子定义：索引中叶级页的数据充满度。它的作用：当系统新建或重建索引时

<br />数据库的优化措施 索引优化<br />索引的作用就类似于书的目录，书的目录会按照章节的顺序排列，会指想某一张的位置。这样如果在一本数百页的书里面查找某个章节位置的时候，我们就可以只扫描书的目录，扫描的范围缩小了n倍，查询的效率自然就提高了。另外在sql server内存够用的情况下索引会被放到内存中，在内存中查找自然又会提高效率；所以我们必须得合理利用索引。<br />1）对什么列建索引<br />数据库默认情况下会对主键建聚集索引，除了这个索引之外还需要在哪些列上建索引呢？这个问题只能具体情况

<br />写在前面：本来“程序员应知”系列中应该写的都是与程序员密切相关的内容，而数据库设计似乎应该是数据库管理员的工作。然而，在实际的工作环境中，我所经历几乎所有的项目中，数据库设计工作都是由程序员来完成的；就算我们是不需要做数据库设计的程序员，也至少需要对数据库的结构有充分的理解，那样也便于我们编写和维护系统。思量再三，我还是将这篇与数据库设计相关的文章放在了这个系列当中。<br />在几乎所有的企业级应用程序中，包括各种MIS、ERP、CRM等等，都会使用数据库，这样的好处是显而易见的，很容易地实现

数据库设计规范数据库表命名规范 此规范包括表名命名规范，索引命名规范，外键命名规范和字段名命名规范。 表名命名规则 数据库表的命名以是名词的复数形式且都为小写，如cities, categories, friends等等 如果表名由几个单词组成，则单词间用下划线("_")分割，如subscribed_pois,poi_categories等 表名尽量用全名 表名限制在30个字符内。当表的全名超过3

 一：原始单据与实体之间的关系　　可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。　　二： 主键与外键　　一般而言，一个实体不能既无主键又无外键。在

MongoDB与Tokyo Tyrant性能比较（1）：基础CRU操作http://www.cnblogs.com/JeffreyZhao/archive/2010/02/24/mongodb-tokyo-tyrant-benchmark-1-basic-cru-operations.html  一种以ID特征为依据的数据分片（Sharding）策略http://www.cnb

1、文件和文件组的含义与关系 每个数据库有一个主数据文件.和若干个从文件。文件是数据库的物理体现。 文件组可以包括分布在多个逻辑分区的文件，实现负载平衡。文件组允许对文件进行分组，以便于管理和数据的分配／放置。例如，可以分别在三个硬盘驱动器上创建三个文件（Data1.ndf、Data2.ndf 和 Data3.ndf），并将这三个文件指派到文件组 fgroup1 中。然后，可以明确地在文件组

我们在数据库中使用表的时候,经常会遇到两种使用表的方法,分别就是使用临时表及表变量。在实际使用的时候，我们如何灵活的在存储过程中运用它们，虽然它们实现的功能基本上是一样的，可如何在一个存储过程中有时候去使用临时表而不使用表变量，有时候去使用表变量而不使用临时表呢? 　　临时表　　临时表与永久表相似，只是它的创建是在Tempdb中，它只有在一个数据库连接结束后或者由SQL命令DROP掉，才会

在做过的很多项目中，发现大家不管对什么表，逢select必定加上nolock（或者with（nolock）），好像已经是制度化的一种东西。有领导高人解释说加上nolock可以提高查询速度，不影响对数据表的其他并发操作。  　　但是真有必要每个查询都加nolock吗？个人认为加不加nolock还是值得我们根据实际情况斟酌一番的（至少需要知其然然后知其所以然吧）。下面就来简单分析一下加不加nolock

 年前参加过一次培训，讲数据库架构优化。讲师中英文混杂讲的，个人英文很烂，大概记了三点。 通过负载均衡策略，有效的降低了单台机器的访问负载，降低了宕机的可能性；通过集群方案，解决了数据库宕机带来的单点数据库不能访问的问题；通过读写分离策略更是最大限度了提高了应用中读取（Read）数据的速度和并发量。       最近翻书又看到关于数据库架构优化。书中讲了三点:1.主从复制，读写分离

设计数据库之前1. 考察现有环境在设计一个新数据库时，你不但应该仔细研究业务需求而且还要考察现有的系统。大多数数据库项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求的现有系统（可能没有实现自动计算）。显然，现有系统并不完美，否则你就不必再建立新系统了。但是对旧系统的研究可以让你发现一些可能会忽略的细微问题。一般来说，考察现有系统对你绝对有好处。— Lamont Adams

1. 原始单据与实体之间的关系可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社

 SQL Server数据库设计表和字段2009/02/18 12:291. 原始单据与实体之间的关系　　可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。 　　

在前面说过了索引能极大的提高数据的检索速度，那为什么不在每一个列上建索引呢？初学者可能会困惑这个问题，而且通常不知道哪些列该建索引，哪些不该建， 甚至于会把like模糊查询的列也作为索引列，其实like是不使用索引的，只有等于,大于,IN等操作符会使用索引。SQLSERVER对于数据的插入，更新和删除，都要更新相应的索引。这无疑会大大增加更新时间。另外，如果某个数据页已满，这时如果要在该页插入数据时，就会造成页分裂产生碎片(后面还会说到)，而影响性能。所以仅当查询的性能比更新的性能更重要时才建索引。 考虑建