在ASP.NET中，和关键字通常用于处理复选框的状态，这两个关键字可以帮助开发者轻松地在服务器端代码中访问和修改复选框的选中状态，以下是对这两个关键字的详细解析。
关系数据库有哪几种完整性
3.1 sql 中的完整性约束SQL把各种完整性约束作为数据库模式定义的一部分。 既有效防止了对数据库的意外破坏，提高了完整性检测的效率，又可以减轻编程人员的负担。 SQL对三种不同完整性约束的设置及检测，采取了不同的方式加以实现。 下面分别介绍。 3.1.1 实体完整性和主码实体完整性规定，主码的任何属性都不能为空，因为，概念模型中实体和联系都是可区分的，而且它们以码为唯一性标识。 如果，主码的属性值可以为空，则意味着在概念模型中存在着不以码为唯一性标识的实体。 这显然是前后矛盾的。 那么怎样保证实体完整性呢？SQL中实体完整性是通过主码来实现的。 一旦某个属性或属性组被定义为主码，该主码的每个属性就不能为空值，并且在关系中不能出现主码值完全相同的两个元组。 主码的定义是在Create Table 语句中使用 Primary Key关键字来实现的。 方法有两种：a) 在属性定义后加上关键字 Primary Key；b) 在属性表定义后加上额外的定义主码的子句：Primary Key（<主码属性名表>）说明：² 如果主码仅由一个属性组成，上述两种方法都可定义，若由两个或以上的属性组成，则只能用上述第二种方法定义了。 ² 对于候选码的说明方法，可以用Unique说明该属性的值不能重复出现。 Unique的使用与Primary Key相似。 ² 一个表中只能有一个主码定义，但可以有多个Unique说明。 ² SQL中，并没有强制为每个关系指定主码，但为每个关系指定主码通常会更好一些。 （因为主码的指定可以确保关系的实体完整性）3.1.2 参照完整性约束与外部码参照完整性是对关系间引用数据的一种限制。 即：若属性组A是基本关系R1的外码，它与基本关系R2的主码K相对应，则R1中每个元组在A上的值必须：要么取空值，要么等于R2中某元组的主码值。 一、外部码约束的说明：SQL中就是利用外部码的说明来实现参照完整性约束，限制表中某些属性的取值的。 外部码的说明也有两种方法：1、在该属性的说明后直接加上关键字”REFERENCES <表名>（<属性名>）”，其中表名称为参照关系名，属性名称为参照关系的主码。 2、在Create Table 语句的属性清单后，加上外部码说明子句，格式为：ForEIGN KEY <属性名表1> REFERENCES <表名>(<属性名表2>)上式中的属性名表1和属性名表2中属性可以多于一个，但必须前后对应。 二、参照完整性约束的实现策略前面讲了，外部码的取值只有两种情况：要么取空，要么取参照关系中的主码值。 可是当用户操作违反了这个规则时，如何保持此约束呢？SQL提供了三种可选方案：1、RESTRICT(限制策略)：当用户对表进行违反了上述完整性约束、条件的插入、删除或修改操作时，将会被系统拒绝。 2、CASCADE（级联策略）：当对参照关系进行删除和修改时，SQL所提供的一种方案。 在这种策略下，当删除或修改参照关系中某元组的主码值时，被参照关系中，那些外部码具有该值的元组也将被删除或修改，以保证参照完整性。 3、SET NULL（置空策略）：置空策略也是针对参照关系的删除或修改操作的。 在这种策略下，当删除参照关系中的某一元组或修改某一元组的主码值时，被参照关系中外码值等于该主码值的元组在该外码上的值将被置空说明：当用户不指定参照完整性的实现策略时，一般被默认为RESTRICT(限制策略)。 实现策略的说明通常被加在外部码的说明后面，格式为：ON DELETE SET NULL ON UPDATE CASCADE。 3.1.3 用户自定义完整性约束对于用户自定义完整性约束，SQL提供了非空约束、对属性的CHECK约束、对元组的CHECK约束、触发器等来实现用户的各种完整性要求。 1、非空约束：在CRETE TABLE 中的属性定义后面加上NOT NULL关键字即定义了该属性不能取空值。 2、基于属性的CHECK约束使用CHECK（检查）子句可保证属性值满足某些前提条件。 其一般格式为：CHECK（<条件>）它既可跟在属性定义的后面，也可在定义语句中另增一子句加以说明。 如：CHECK（age>=18 AND age<=65）; CHECK（sex IN (“男”,”女”)）; CHECK（dno IN(select dno from department)）;从上例中可以看出，CHECK子句的条件中还可以带子查询。 3、基于元组的CHECK约束基于元组的CHECK约束往往要涉及到表中的多个域。 所以它是元组约束。 在对整个元组完成插入或对某一元组的修改完成之后，系统将自动检查是否符合CHECK条件表达式。 若不符合条件，系统将拒绝该插入或修改操作。 基于元组CHECK约束的说明方法是在CREATE TABLE语句中的属性表、主码、外部码的说明之后加上CHECK子句。 3.1.4 约束的更新约束与数据库中的表和视图一样，可以进行增、删、改的更新操作。 为了改和删约束，需要在定义约束时对其进行命名，在各种约束的说明前加上关键字CONSTRAINT 和该约束的名称即可。 例如：在employee表的create table语句中：eno char(4) CONSTRAINT PK_employee PRIMARY KEY,dno char(4)CONSTRAINT FK_employee FOREIGN KEY REFERENCES department(dno);当对各种约束进行命名后，就可以用ALTER TABLE语句来更新与属性或表有关的各种约束。 如：ALTER TABLE employee DROP CONSTRAINT FK_employee;ALER TABLE Salary ADD CONSTRAINT RightSalary CHECK(Insure+Fund
重装电脑后，F、G盘消失了，该怎么重新划分出来？？
1.首先 计算 你现有的几个盘都多大空间，计算方式为 1M＝1024bt 1G＝1024M 你换算一下，若是和你电脑上硬盘容量相符，那就是你送出去安装电脑给你重新做了分区，所以你看不到 E F区了，
2.看你说的情况 若你有光驱的话 现在是分了2个区，若你想要多个区 ，可以使用 分区魔术师 PQ软件 进行无损分区，而得到你想要的多个盘，具体操作你可在网上找教程 切勿不懂乱操作。
3.极少的情况下 也有系统启动时 磁盘驱动器驱动安装不正常 导致 看不到盘的情况，这种情况你可以在桌面，我的电脑 右键 管理 打开计算机管理， 在磁盘管理里可以看见电脑上的硬盘以及分区情况， 使用更改启动器名 你可以给你没有加载的硬盘分区赋予 E F 盘符 然后在我的电脑里就可以看见了
回答不尽详实 供大家探讨
如何在Java中使用双重检查锁实现单例
单例类在Java开发者中非常常用，但是它给初级开发者们造成了很多挑战。 他们所面对的其中一个关键挑战是，怎样确保单例类的行为是单例？也就是说，无论任何原因，如何防止单例类有多个实例。 在整个应用生命周期中，要保证只有一个单例类的实例被创建，双重检查锁（Double checked locking of Singleton）是一种实现方法。 顾名思义，在双重检查锁中，代码会检查两次单例类是否有已存在的实例，一次加锁一次不加锁，一次确保不会有多个实例被创建。 顺便提一下，在JDK1.5中，Java修复了其内存模型的问题。 在JDK1.5之前，这种方法会有问题。 本文中，我们将会看到怎样用Java实现双重检查锁的单例类，为什么Java 5之前的版本双重检查锁会有问题，以及怎么解决这个问题。 顺便说一下，这也是重要的面试要点，我曾经在金融业和服务业的公司面试被要求手写双重检查锁实现单例模式、相信我，这很棘手，除非你清楚理解了你在做什么。 你也可以阅读我的完整列表“单例模式设计问题”来更好的准备面试。 为什么你需要双重检查锁来实现单例类？一个常见情景，单例类在多线程环境中违反契约。 如果你要一个新手写出单例模式，可能会得到下面的代码： private static Singleton _instance;public static Singleton getInstance() {if (_instance == null) {_instance = new Singleton();}return _instance;}然后，当你指出这段代码在超过一个线程并行被调用的时候会创建多个实例的问题时，他很可能会把整个getInstance()方法设为同步（synchronized），就像我们展示的第二段示例代码getInstanceTS()方法一样。 尽管这样做到了线程安全，并且解决了多实例问题，但并不高效。 在任何调用这个方法的时候，你都需要承受同步带来的性能开销，然而同步只在第一次调用的时候才被需要，也就是单例类实例创建的时候。 这将促使我们使用双重检查锁模式（double checked locking pattern），一种只在临界区代码加锁的方法。 程序员称其为双重检查锁，因为会有两次检查 _instance == null，一次不加锁，另一次在同步块上加锁。 这就是使用Java双重检查锁的示例： public static Singleton getInstanceDC() {if (_instance == null) {// Single Checkedsynchronized () {if (_instance == null) {// Double checked_instance = new Singleton();}}}return _instance;}这个方法表面上看起来很完美，你只需要付出一次同步块的开销，但它依然有问题。 除非你声明_instance变量时使用了volatile关键字。 没有volatile修饰符，可能出现Java中的另一个线程看到个初始化了一半的_instance的情况，但使用了volatile变量后，就能保证先行发生关系（happens-before relationship）。 对于volatile变量_instance，所有的写（write）都将先行发生于读（read），在Java 5之前不是这样，所以在这之前使用双重检查锁有问题。 现在，有了先行发生的保障（happens-before guarantee），你可以安全地假设其会工作良好。 另外，这不是创建线程安全的单例模式的最好方法，你可以使用枚举实现单例模式，这种方法在实例创建时提供了内置的线程安全。 另一种方法是使用静态持有者模式（static holder pattern）。 /* * A journey to write double checked locking of Singleton class in Java. */class Singleton {private volatile static Singleton _instance;private Singleton() {// preventing Singleton object instantiation from outside}/* * 1st version: creates multiple instance if two thread access * This method simultaneously */public static Singleton getInstance() {if (_instance == null) {_instance = new Singleton();}return _instance;} /** 2nd version : this definitely thread-safe and only* creates one instance of Singleton on concurrent environment* but unnecessarily expensive due to cost of synchronization* at every call.*/ public static synchronized Singleton getInstanceTS() { if (_instance == null) { _instance = new Singleton(); } return _instance; } /** 3rd version : An implementation of double checked locking of Singleton.* Intention is to minimize cost of synchronization andimprove performance,* by only locking critical section of code, the code which creates instance of Singleton class.* By the way this is still broken, if we dont make _instance volatile, as another thread can* see a half initialized instance of Singleton.*/public static Singleton getInstanceDC() {if (_instance == null) {synchronized () {if (_instance == null) {_instance = new Singleton();}}}return _instance;}}这就是本文的所有内容了。 这是个用Java创建线程安全单例模式的有争议的方法，使用枚举实现单例类更简单有效。 我并不建议你像这样实现单例模式，因为用Java有许多更好的方式。 但是，这个问题有历史意义，也教授了并发是如何引入一些微妙错误的。 正如之前所说，这是面试中非常重要的一点。 在去参加任何Java面试之前，要练习手写双重检查锁实现单例类。 这将增强你发现Java程序员们所犯编码错误的洞察力。 另外，在现在的测试驱动开发中，单例模式由于难以被模拟其行为而被视为反模式（anti pattern），所以如果你是测试驱动开发的开发者，最好避免使用单例模式。
发表评论