数据库的逻辑设计（包括各种表和表间关系）是优化关系数据库的核心。设计好逻辑数据库，可以为优化数据库和应用程序性能打下基础。逻辑数据库设计不好，会影响整个系统的性能。

规范化逻辑数据库设计包括使用正规的方法来将数据分为多个相关的表。有几个具有较少列的窄表是规范化数据库的特征。有少量具有较多列的宽表是非规范化数据库的特征。

通常，合理的规范化会提高性能。如果包含有用的索引，SQL Server 查询优化器可有效地在表间选择快速、有效的联接。

下面给出了规范化的一些好处：

• 使排序和创建索引更加迅速。
  
• 聚集索引的数目更大。有关详细信息，请参阅聚集索引设计指南。
  
• 索引更窄、更紧凑。
  
• 每个表的索引更少。这可提高 INSERT、UPDATE 和 DELETE 语句的性能。
  
• 空值更少，出现不一致的机会更少。这可增加数据库的紧凑性。
  

随着规范化的不断提高，检索数据所需的联接数和复杂性也将不断增加。太多表间的关系联接太多、太复杂可能会影响性能。合理的规范化通常很少包括经常性执行且所用联接涉及 4 个以上表的查询。

有 时，逻辑数据库设计已经固定，全部进行重新设计是不现实的。但是，尽管如此，将大表有选择性地进行规范化处理，分为几个更小的表是可能的。如果是通过存储 过程对数据库进行访问，则在不影响应用程序的情况下架构可能发生更改。如果不是这种情况，那么可以创建一个视图，以便从应用程序隐藏架构的更改。

在关系数据库设计理论中，规范化规则指出了在设计良好的数据库中必须出现或不出现的某些属性。关于规范化规则的完整讨论不属于本主题的范畴。不过，有几个可帮助获得合理的数据库设计的规则：

• 表应该有一个标识符。
  数据库设计理论的基本原理是：每个表都应有一个唯一的行标识符，可以使用列或列集将任何单个记录同表中的所有其他记录区别开来。每个表都应有一个 ID 列，任何两个记录都不能共享同一 ID 值。作为表的唯一行标识符的列是表的主键。在 AdventureWorks 数据库中，每个表有一个标识列作为主键列。例如，VendorID 是 Purchasing.Vendor 表的主键。
  
• 表应只存储单一类型实体的数据。
  试图在表中存储过多的信息会影响对表中的数据进行有效、可靠的管理。在 AdventureWorks 示例数据库中，销售订单和客户信息存储在不同的表中。虽然可在单独的表中创建包含有关销售订单和客户信息的列，但是此设计会导致出现几个问题。必须在每个 销售订单中另外添加和存储客户信息、客户姓名和地址。这将使用数据库中的其他存储空间。如果客户地址发生变化，必须更改每个销售订单。另外，如果从 Sales.SalesOrderHeader 表中删除了客户最近的销售订单，该客户的信息将会丢失。
  
• 表应避免可为空的列。
  表中的列可定义为允许空值。空值表示没有值。虽然在个别情况下，允许空值可能是有用的，但是应尽量少用。这是因为需要对它们进行特殊处理，从而会增加数据 操作的复杂性。如果某一表中有几个可为空值的列，并且列中有几行包含空值，则应考虑将这些列置于链接到主表的另一表中。通过将数据存储在两个不同的表中， 主表的设计会非常简单，而且仍能够满足存储此信息的临时需要。
  
• 表不应有重复的值或列。
  数据库中某一项目的表不应包含有关特定信息的一些值。例如，AdventureWorks 数据库中的某产品可能是从多个供应商处购买的。如果 Production.Product 表有一列为供应商的名称，这就会产生问题。一个解决方案是将所有供应商的名称存储在该列中。但是，这使得列出各个供应商变得非常困难。另一个解决方案是更 改表的结构来为另一个供应商的名称再添加一列。但是，这只允许有两个供应商。此外，如果一本书有三个供应商，则必须再添加一列。
  如果您发现需要在单个列中存储多个值，或者一类数据（例如 TelephoneNumber1 和 TelephoneNumber2）对应于多列，则应考虑将重复的数据置于链接回主表的另一个表中。AdventureWorks 数据库有一个用于存储产品信息的 Production.Product 表和一个用于存储供应商信息的 Purchasing.Vendor 表，还有第三个表 Purchasing.ProductVendor。第三个表只存储产品的 ID 值和产品供应商的 ID 值。这种设计允许产品有任意多个供应商，而无需修改表的定义，也无需为单个供应商的产品分配未使用的存储空间。

摘自 规范化 http://technet.microsoft.com/zh-cn/library/ms191178.aspx

文件下载：DoubleColorBall.zip(4KB) 
控制台输出双色球号码，程序参考：
http://www.cnblogs.com/zitsing/archive/2008/04/10/1138533.html
http://msdn2.microsoft.com/zh-cn/library/9aackb16.aspx

程序原理：随机数+排序+事件与委托
其中随机数部分借鉴了zitsing's blog 的程序，在此表示感谢！

  .NET Framework 具有两个主要组件：公共语言运行库和 .NET Framework 类库。公共语言运行库是 .NET Framework 的基础。您可以将运行库看作一个在执行时管理代码的代理，它提供内存管理、线程管理和远程处理等核心服务，并且还强制实施严格的类型安全以及可提高安全性和可靠性的其他形式的代码准确性。事实上，代码管理的概念是运行库的基本原则。以运行库为目标的代码称为托管代码，而不以运行库为目标的代码称为非托管代码。.NET Framework 的另一个主要组件是类库，它是一个综合性的面向对象的可重用类型集合，您可以使用它开发多种应用程序，这些应用程序包括传统的命令行或图形用户界面 (GUI) 应用程序，也包括基于 ASP.NET 所提供的最新创新的应用程序（如 Web 窗体和 XML Web Services）。

   抽象类型和接口是用于指定编程抽象的两种机制。抽象指定继承者或实施者必须遵循的一个协定。抽象类型可以选择提供实现的详细信息；而接口不能提供实现的任何详细信息。

• 类可能只是从一个基类继承，所以如果要使用抽象类为一组类提供多态性，这些类必须都是从那个类继承的。
• 抽象类还可能提供已实现的成员。因此，可以用抽象类确保特定数量的相同功能，但不能用接口这样做。

这里是一些建议，帮助您决定使用接口还是抽象类为组件提供多态性。

• 如果预计要创建组件的多个版本，则创建抽象类。抽象类提供简单易行的方法来控制组件版本。通过更新基类，所有继承类都随更改自动更新。另一方面，接口一旦创建就不能更改。如果需要接口的新版本，必须创建一个全新的接口。
• 如果创建的功能将在大范围的全异对象间使用，则使用接口。抽象类应主要用于关系密切的对象，而接口最适合为不相关的类提供通用功能。
• 如果要设计小而简练的功能块，则使用接口。如果要设计大的功能单元，则使用抽象类。
• 如果要在组件的所有实现间提供通用的已实现功能，则使用抽象类。抽象类允许部分实现类，而接口不包含任何成员的实现。

参考：http://msdn.microsoft.com/library/chs/default.asp?url=/library/CHS/vbcon/html/vbconabstractclassesversusinterfaces.asp

NHibernateIt is a NHibernate Session Management Helper and provides basic CRUD actions trough the Repository class.
下载地址 NHibernateIt.Deployment.msi