缓存使得你可以快速的获取内存中存储的数据。当再次访问数据的时候，应用从缓存中获取数据，而不是从数据的原始源获取。这么做可以提高性能和扩展性。另外，当数据源临时不可用的时候，缓存使得数据还是可用的。 你可以用.NET提供的缓存功能提高应用的性能和扩展性，缓存功能可以在windows客户端应用中使用，也可以在ASP.NET这种服务端应用中使用。
Rails开发细节《九》Rails的测试
看过本文之后，你应该熟悉下面的内容： 所有显著的对策。 rails中session的概念，其中存放的内容，常见的攻击手段。 rails中大量的分配问题。 在提供管理接口的时候，你不得不关注的一些事情。 如何管理用户：登陆，退出，在各个层面的攻击方法。 流行的注入攻击方法。
Rails开发细节《七》ActiveRecord Associations关联
Rails开发细节《六》ActiveRecord Validationa and Callbacks验证和回调
Rails开发细节《五》Migrations 数据迁移
Rails开发细节《四》Transactions事务
Rails开发细节《三》Participating in the Monitoring Process参与监控过程
Rails开发细节《二》CRUD
本文是SQL Server索引进阶系列（Stairway to SQL Server Indexes）的一部分。 在第十级到十二级中，我们看了索引的内部结构，以及改变结构造成的影响。在本文中，继续查看Insert，update，delete和merge造成的影响。首先，我们单独看一下这四个命令。
本文是SQL Server索引进阶系列（Stairway to SQL Server Indexes）的一部分。 在本文中我们将推荐14条贯穿本系列的规则，这些规则帮助你为数据库创建最好的索引结构。 格式来自于《Framework Design Guidelines》。每条推荐用四个词来总结：Do做，Consider考虑，Void避免，Do Not不要做。 做。总是要遵守的规则。 考虑。通常来说应该遵守，但是如果你完全理解了规则背后的原因，并且有你不遵守的原因。 避免。和考虑相反，通常建议不这么做，但是如果你完全理解了为什么不应该这么做，你有这么做的原因，你可以这么做。 不要做。比避免语气要强，表面有些事永远不要做。
本文是SQL Server索引进阶系列（Stairway to SQL Server Indexes）的一部分。 在第十级中我们看到了索引的内部结构，在第十一级中我们看到了平衡树结构潜在的负面影响：索引碎片。有了索引内部结构的知识，我们可以检查在执行数据定义语句和数据操作语句的时候，都发生了什么。在本级中我们介绍数据定义语言的三个动词：create，alter和drop。在下一级中，我们介绍数据操作语言的三个动词：insert，update，delete。
本文是SQL Server索引进阶系列（Stairway to SQL Server Indexes）的一部分。 在之前的级别中，我们从逻辑的角度介绍索引，集中于它们能为我们做什么。现在，是时候从物理的角度，并且检查一下索引的内部结构，从理解索引的内部结构，引导我们理解索引在上层做的工作。通过索引的结构，它是如何维护的，你可以理解在进行插入，更新，删除的时候，最小化索引的创建，修改，移动。 因此，从现在开始，我们除了要关心索引带来的好处，还要关心索引的消耗。毕竟，最小化消耗可以带来最大化的好处，带来最大化的好处是本系列的宗旨。
本文是SQL Server索引进阶系列（Stairway to SQL Server Indexes）的一部分。 在这个系列中，我们经常会以特定的方式执行特定的查询。我们引用生成的执行计划来支持我们的论调。SQL Server管理器显示的预估的和实际的查询计划，可以帮助我们确定索引的好处，以及其中的缺陷。因此，本文的主要目的是给你一些关于执行计划的充分的理解： 验证你在系列中阅读到的我们的断言。 确定你的索引是否对查询有好处。
本文是SQL Server索引进阶系列（Stairway to SQL Server Indexes）的一部分。 本级别我们将测试唯一索引。唯一索引比较特别，不仅提高查询的性能，同时也带来数据完整性的好处。在SQL Server中，唯一索引是强制主键和候选键约束的唯一合理的方法。
本文是SQL Server索引进阶系列（Stairway to SQL Server Indexes）的一部分。 在之前的级别中，我们已经说过，表中的每一行在索引中会生成一个入口，这条规则有一个例外。一些索引的入口会比对应的表的行数要少。这些索引被称作“过滤的索引”，是SQL Server 2008中的一个特性。
本文是SQL Server索引进阶系列（Stairway to SQL Server Indexes）的一部分。 在前面的章节中我们看到了，索引就是一些有序入口的集合，每行一个入口。我们更多的强调索引的逻辑方面，而不是物理方面。当目前为止，我们讲述了非聚集索引入口的两个组件：查询键和包含列。在本章中，我们介绍第三个，也是最后一个组件：标签。
本文是SQL Server索引进阶系列（Stairway to SQL Server Indexes）的一部分。 之前的文章介绍了聚集索引和非聚集索引，包含下面几条很重要的内容: 表中的每一行在索引中总是有一个入口（这条规则有一个意外，在后面的级别中我们会讲到）。这些入口总是用索引键排序。 在聚集索引中，索引的入口就是表的实际行。 在非聚集索引中，入口和数据行是分开的，索引由索引键列和标签组成，标签是索引键列到表数据行的映射。 第三句的后半部分是正确的，但是不完整。今天我们将测试在非聚集索引中包括额外列的情况，这些额外列叫做“包含列”。在第六级中，将会测试标签的操作，我们将会看到SQL Server可能会单方面的给你的索引添加一些列。
本文是SQL Server索引进阶系列（Stairway to SQL Server Indexes）的一部分。 在之前的级别中，我们分别在有索引和没有索引的表中执行查询，比较了他们需要做的工作。我们的主要度量标准是“login read逻辑读”。我们总是比较在有索引和没有索引的表执行查询的逻辑读。现在，是时候解释为什么“逻辑读”是一个优秀的度量标准，同时也解释了实际上读取了什么。
本文是SQL Server索引进阶系列（Stairway to SQL Server Indexes）的一部分。 在这个进阶系列的前一级中介绍了索引的大概信息，以及详细介绍了nonclustered indexes非聚集索引。SQL Server的索引包含一些关键的概念。 当一个请求到达数据库的时候，有可能是select，或者insert，或者update，或者delete，SQL Server只有三种访问数据的方式： 访问非聚集索引，避免访问表。这只发生在索引包含了请求中的所有数据。 通过索引键访问非聚集索引，然后使用标签访问表中的行数据。 忽略非聚集索引，扫描表找到请求的行数据。 本篇文章将从上面列表中的第三条开始介绍：扫描表。我们来讨论一下clustered indexes聚集索引，一个在第二级中提到但是没有展开的概念。
本文是SQL Server索引进阶系列（Stairway to SQL Server Indexes）的一部分。 在第一级中介绍了SQL Server中的非聚集索引。而且在第一个学习的例子中，我们证明了在从表中获取一行数据的情况下，索引带来的潜在的好处。在这一级中，我们继续介绍非聚集索引，看看他们在提升查询性能中做出的贡献。
本文是SQL Server索引进阶系列（Stairway to SQL Server Indexes）的一部分。 索引是数据库设计的基础，向开发者显示了使用数据库大量数据库设计者的意图。不幸的是，索引大部分时候是在出现性能问题的时候，才被事后添加上的。
web缓存位于一个或者多个服务器和一个或者多个客户端之间，监视其中的请求，节约响应的数量。例如：页面，图片和文件。如果对相同的url地址的另外一个请求，可以使用已有的响应，而不是向原始服务器重新请求。 使用web缓存有两个主要原因： 1、减小延迟。因为请求从缓存，这个离客户端更近的地方，得到响应，而不是从原始服务器。花费更少的时间获取内容并且呈现出来，使得web看起来响应更快。 2、减少网络传输。因为响应被重用，减少了客户端的带宽使用。如果带宽需要付费的话，还可以节省开支，保持对带宽的较小需求。
本系列文章翻译自《50 Tips and Tricks for MongoDB Developers》，暂时没有找到中文版，反正自己最近也在深入学习mongodb，所以正好拿来翻译一下。一方面加强自己学习的效果，另一方面让大家也一起来体验一下需要我们这些mongodb使用者需要注意的地方。 首先声明自己的英文水平不是太高，加之有些英文翻译成中文也找不到合适的词来表达，所以在文章中可能会出现英文原词，或者说有些地方的翻译会有些生 硬，也就是说会出现直译的地方。翻译该书的主要目的是为大家学习探讨用的，如果有翻译不精准的地方，或者说有更加精准的翻译，还请大家指出，我会及时的更正的，在此先谢过各位了。 Tip#25.Use compound indexes to make multiple queries fast 使用复合索引加速查询
本系列文章翻译自《50 Tips and Tricks for MongoDB Developers》，暂时没有找到中文版，反正自己最近也在深入学习mongodb，所以正好拿来翻译一下。一方面加强自己学习的效果，另一方面让大 家也一起来体验一下需要我们这些mongodb使用者需要注意的地方。 首先声明自己的英文水平不是太高，加之有些英文翻译成中文也找不到合适的词来表达，所以在文章中可能会出现英文原词，或者说有些地方的翻译会有些生 硬，也就是说会出现直译的地方。翻译该书的主要目的是为大家学习探讨用的，如果有翻译不精准的地方，或者说有更加精准的翻译，还请大家指出，我会及时的更 正的，在此先谢过各位了。 Tip#24.Create indexes that cover your queries 创建的索引最好能覆盖你的查询
本系列文章翻译自《50 Tips and Tricks for MongoDB Developers》，暂时没有找到中文版，反正自己最近也在深入学习mongodb，所以正好拿来翻译一下。一方面加强自己学习的效果，另一方面让大 家也一起来体验一下需要我们这些mongodb使用者需要注意的地方。 首先声明自己的英文水平不是太高，加之有些英文翻译成中文也找不到合适的词来表达，所以在文章中可能会出现英文原词，或者说有些地方的翻译会有些生 硬，也就是说会出现直译的地方。翻译该书的主要目的是为大家学习探讨用的，如果有翻译不精准的地方，或者说有更加精准的翻译，还请大家指出，我会及时的更 正的，在此先谢过各位了。 Tip#23.Don't always use an index 不要总是使用索引
本系列文章翻译自《50 Tips and Tricks for MongoDB Developers》，暂时没有找到中文版，反正自己最近也在深入学习mongodb，所以正好拿来翻译一下。一方面加强自己学习的效果，另一方面让大 家也一起来体验一下需要我们这些mongodb使用者需要注意的地方。 首先声明自己的英文水平不是太高，加之有些英文翻译成中文也找不到合适的词来表达，所以在文章中可能会出现英文原词，或者说有些地方的翻译会有些生 硬，也就是说会出现直译的地方。翻译该书的主要目的是为大家学习探讨用的，如果有翻译不精准的地方，或者说有更加精准的翻译，还请大家指出，我会及时的更 正的，在此先谢过各位了。 Tip#22.Use indexes to do more with less memory 通过索引实现用较少的内存做更多的事情
本系列文章翻译自《50 Tips and Tricks for MongoDB Developers》，暂时没有找到中文版，反正自己最近也在深入学习mongodb，所以正好拿来翻译一下。一方面加强自己学习的效果，另一方面让大 家也一起来体验一下需要我们这些mongodb使用者需要注意的地方。 首先声明自己的英文水平不是太高，加之有些英文翻译成中文也找不到合适的词来表达，所以在文章中可能会出现英文原词，或者说有些地方的翻译会有些生 硬，也就是说会出现直译的地方。翻译该书的主要目的是为大家学习探讨用的，如果有翻译不精准的地方，或者说有更加精准的翻译，还请大家指出，我会及时的更 正的，在此先谢过各位了。 Tip#21.Minimize disk access 将访问磁盘的次数降到最低
本系列文章翻译自《50 Tips and Tricks for MongoDB Developers》，暂时没有找到中文版，反正自己最近也在深入学习mongodb，所以正好拿来翻译一下。一方面加强自己学习的效果，另一方面让大 家也一起来体验一下需要我们这些mongodb使用者需要注意的地方。 首先声明自己的英文水平不是太高，加之有些英文翻译成中文也找不到合适的词来表达，所以在文章中可能会出现英文原词，或者说有些地方的翻译会有些生 硬，也就是说会出现直译的地方。翻译该书的主要目的是为大家学习探讨用的，如果有翻译不精准的地方，或者说有更加精准的翻译，还请大家指出，我会及时的更 正的，在此先谢过各位了。 Tip#20.Handle replica set failure and failover 处理复制集的故障和故障恢复
本系列文章翻译自《50 Tips and Tricks for MongoDB Developers》，暂时没有找到中文版，反正自己最近也在深入学习mongodb，所以正好拿来翻译一下。一方面加强自己学习的效果，另一方面让大 家也一起来体验一下需要我们这些mongodb使用者需要注意的地方。 首先声明自己的英文水平不是太高，加之有些英文翻译成中文也找不到合适的词来表达，所以在文章中可能会出现英文原词，或者说有些地方的翻译会有些生 硬，也就是说会出现直译的地方。翻译该书的主要目的是为大家学习探讨用的，如果有翻译不精准的地方，或者说有更加精准的翻译，还请大家指出，我会及时的更 正的，在此先谢过各位了。 Tip#19.Handle "seamless" failover 处理无缝的故障恢复（直译，没找到好的翻译）
Copyright © 2005-2023 51CTO.COM 版权所有 京ICP证060544号
