经典的71个做饭技巧
星期四 七月 03rd 2008, 8:40 上午
类归于：
未分类1、羊肉去膻味：将萝卜块和羊肉一起下锅，半小时后取出萝卜块；放几块桔子皮更佳；每公斤羊肉放绿豆5克，煮沸10分钟后，将水和绿豆一起倒出；放半包山楂片；将带壳的核桃两三个洗净打孔放入；１公斤羊肉加咖喱粉10克；１公斤羊肉加剖开的甘蔗200克；１公斤水烧开，加羊肉１公斤、醋50克，煮沸后捞出，再重新加水加调料。
2、煮牛肉：为了使牛肉炖得快，炖得烂，加一小撮茶叶(约为泡一壶茶的量，用纱布包好)同煮，肉很快就烂且味道鲜美。
3、煮骨头汤时加一小匙醋，可使骨头中的磷、钙溶解于汤中，并可保存汤中的维生素。
4、煮牛肉和其他韧、硬肉类以及野味禽类时，加点醋可使其软化。
5、煮肉汤或排骨汤时，放入几块新鲜桔皮，不仅味道鲜美，还可减少油腻感。
6、煮咸肉：用十几个钻有许多小孔的核桃同煮，可消除臭味
7、将绿豆在铁锅中炒10分钟再煮能很快煮烂，但注意不要炒焦
8、煮蛋时水里加点醋可防蛋壳裂开，事先加点盐也可
9、煮海带时加几滴醋易烂；放几棵波菜也行
10、煮火腿之前，将火腿皮上涂些白糖，容易煮烂，味道更鲜美
11、煮水饺时，在水里放一颗大葱或在水开后加点盐，再放饺子，饺子味道鲜美不粘连；在和面时，每500克面粉加拌一个鸡蛋，饺子皮挺刮不粘连
12、煮水饺时，在锅中加少许食盐，锅开时水也不外溢
13、面条时加一小汤匙食油，面条不会沾连，并可防止面汤起泡沫、溢出锅外
14、煮面条时，在锅中加少许食盐，煮出的面条不易烂糊
15、熬粥或煮豆时不要放碱，否则会破坏米、豆中的营养物质
16、用开水煮新笋容易熟，且松脆可口；要使笋煮后不缩小，可加几片薄荷叶或盐
17、猪肚煮熟后，切成长块，放在碗内加一些鲜汤再蒸一会儿，猪肚便会加厚一倍
18、煮猪肚时，千万不能先放盐，等煮熟后吃时再放盐，否则猪肚会缩得象牛筋一样硬
19、炖肉时，在锅里加上几块桔皮，可除异味和油腻并增加汤的鲜味
20、炖鸡：洗净切块，倒入热油锅内翻炒，待水分炒干时，倒入适量香醋，再迅速翻炒，至鸡块发出劈劈啪啪的爆响声时，立即加热水(没过鸡块)，再用旺火烧十分钟，即可放入调料，移小火上再炖20分钟，淋上香油即可出锅；应在汤炖好后，温度降至80～90摄氏度时或食用前加盐。因为鸡肉中含水分较高，炖鸡先加盐，鸡肉在盐水中浸泡，组织细胞内水分向外渗透，蛋白质产生凝固作用，使鸡肉明显收缩变紧，影响营养向汤内溶解，且煮熟后的鸡肉趋向硬、老，口感粗糙。
21、炖老鸡：在锅内加二三十颗黄豆同炖，熟得快且味道鲜；或在杀老鸡之前，先灌给鸡一汤匙食醋，然后再杀，用文火煮炖，就会煮得烂熟；或放３～４枚山楂，鸡肉易烂
22、老鸡鸭用猛火煮，肉硬不好吃；如果先用凉水和少许食醋泡上２小时，再用微火炖，肉就会变得香嫩可口
23、炖老鸭：在锅里放几个田螺容易烂熟
24、烧鸭子时，把鸭子尾端两侧的臊豆去掉，味道更美
25、烧豆腐时，加少许豆腐乳或汁，味道芳香
26、红烧牛肉时，加少许雪里红，肉味鲜美
27、做红烧肉前，先用少许硼砂把肉腌一下，烧出来的肉肥而不腻，甘香可口
28、油炸食物时，锅里放少许食盐，油不会外溅
29、在春卷的拌馅中适量加些面粉，能避免炸制过程中馅内菜汁流出糊锅底的现象
30、炸土豆之前，先把切好的土豆片放在水里煮一会儿，使土豆皮的表面形成一层薄薄的胶质层，然后再用油炸
31、炸猪排时，在有筋的地方割２～３个切口，炸出来的猪排就不会收缩
32、将鸡肉先腌一会儿，封上护膜放入冰箱，待炸时再取出，炸出的鸡肉酥脆可口
33、煎荷包蛋时，在蛋黄即将凝固之际浇一点冷开水，会使蛋又黄又嫩
34、煎鸡蛋时，在平底锅放足油，油微热时蛋下锅，鸡蛋慢慢变熟，外观美，不粘锅
35、煎鸡蛋时，在热油中撒点面粉，蛋会煎得黄亮好看，油也不易溅出锅外
36、用羊油炒鸡蛋，味香无异味
37、炒鸡蛋时加入少量的砂糖，会使蛋白质变性的凝固温度上升，从而延缓了加热时间，加上砂糖具有保水性，因而可使蛋制品变得膨松柔软
38、炒鸡蛋时加入几滴醋，炒出的蛋松软味香
39、炒茄子时，在锅里放点醋，炒出的茄子颜色不会变黑
40、炒土豆时加醋，可避免烧焦，又可分解土豆中的毒素，并使色、味相宜
41、炒豆芽时，先加点黄油，然后再放盐，能去掉豆腥味
42、炒波菜时不宜加盖
43、炒肉片：肉切成薄片加酱油、黄油、淀粉，打入一个鸡蛋，拌匀，炒散；等肉片变色后，再加佐料稍炒几下，肉片味美、鲜嫩
44、炒牛肉丝：切好，用盐、糖、酒、生粉(或鸡蛋)拌一下，加上生油泡腌，30分钟后再炒，鲜嫩可口
45、炒肉菜时放盐过早熟得慢，宜在将熟时加盐，在出锅前再加上几滴醋，鲜嫩可口
46、肉丝切好后放在小苏打溶液里浸一下再炒，特别疏松可口不论做什么糖醋菜肴，只要按２份糖１份醋的比例调配，便可做到甜酸适度
47、炒糖醋鱼、糖醋菜帮等，应先放糖，后放盐，否则食盐的“脱水”作用会促进菜肴中蛋白质凝固而“吃”不进糖分，造成外甜里淡
48、做肉饼和肉丸子时，一公斤肉馅放2小匙盐
49、做丸子按50克肉10克淀粉的比例调制，成菜软嫩
50、做滑炒肉片或辣子肉丁，按50克肉５克淀粉的比例上浆，成菜鲜嫩味美
51、做馒头时，如果在发面里揉进一小块猪油，蒸出来的馒头不仅洁白、松软，而且味香
52、蒸馒头时掺入少许桔皮丝，可使馒头增加清香
53、蒸馒头碱放多了起黄，如在原蒸锅水里加醋２～３汤匙，再蒸10～15分钟可变白
54、将少量明矾和食盐放入清水中，把切开的生红薯浸入十几分钟，洗净后蒸煮，可防止或减轻腹胀
55、牛奶煮糊了，放点盐，冷却后味道更好
56、放有辣椒的菜太辣时或炒辣椒时加点醋，辣味大减
57、烹调时，放酱油若错倒了食醋，可撒放少许小苏打，醋味即可消除
58、菜太酸，将一只松花蛋捣烂放入
59、菜太辣，放一只鸡蛋同炒
60、菜太辣，放些醋可减低辣味
61、菜太苦，滴入少许白醋
62、汤太咸又不宜兑水时，可放几块豆腐或土豆或几片蕃茄到汤中；也可将一把米或面粉用布包起来放入汤中
63、汤太腻，将少量紫菜在火上烤一下，然后撒入汤中
64、花生米用油炸熟，盛入盘中，趁热撒上少许白酒，稍凉后再撒上少许食盐，放置几天几夜都稣脆如初
65、菜籽油有一股异味，可把油烧热后投入适量生姜、蒜、葱、丁香、陈皮同炸片刻，油即可变香
66、用菜油炸一次花生米就没有怪味了，炒出的菜肴香味可口，并可做凉拌菜
67、炸完食物后的油留下一些残渣并变得混浊，可将白萝卜切成厚圆片，用筷子把萝卜戳几个洞，放入剩油中炸，残渣会附着在萝卜片上，取出清除残渣，再反复放入锅中炸，混浊的油可变清澈
68、炒菜时应先把锅烧热，再倒入食油，然后再放菜
69、当锅内温度达到最高时加入料酒，易使酒蒸发而去除食物中的腥味
70、熬猪油：在电饭褒内放一点水或植物油，然后放入猪板油或肥肉，接通电源后，能自动将油炼好，不溅油，不糊油渣，油质清纯
71、泡菜坛中放十几粒花椒或少许麦芽糖，可防止产生白花。
阅读(0 次)
日常致癌食物黑名单
星期五 六月 13th 2008, 12:11 下午
类归于：
未分类日常致癌食物黑名单 腌制食品：咸鱼产生的二甲基亚硝酸盐，在体内可以转化为致癌物质二甲基亚硝酸胺。咸蛋、咸菜等同样含有致癌物质，应尽量少吃。
烧烤食物：烤牛肉、烤鸭、烤羊肉、烤鹅、烤乳猪、烤羊肉串等，因含有强致癌物不宜多吃。
熏制食品：如熏肉、熏肝、熏鱼、熏蛋、熏豆腐干等含苯并芘致癌物，常食易患食道癌和胃癌。
油炸食品：煎炸过焦后，产生致癌物质多环芳烃。咖啡烧焦后，苯并芘会增加20倍。油煎饼、臭豆腐、煎炸芋角、油条等，因多数是使用重复多次的油，高温下会产生致癌物。
霉变物质：米、麦、豆、玉米、花生等食品易受潮霉变，被霉菌污染后会产生致癌毒草素——黄曲霉菌素。
隔夜熟白菜和酸菜：会产生亚硝酸盐，在体内会转化为亚硝酸胺致癌物质。
槟榔：嚼食槟榔是引起口腔癌的一个因素。
反复烧开的水：反复烧开的水含亚硝酸盐，进入人体后生成致癌的亚硝酸胺。
防癌食物可分为8大类
1.洋葱类：大蒜、洋葱、韭菜、芦笋、青葱等;
2.十字花科：花椰菜、甘蓝菜、芥菜、萝卜等;
3.坚果和种子：核桃、松子、开心果、芝麻、杏仁、胡桃、瓜子等;
4.谷类：玉米、燕麦、米、小麦等;
5.荚豆类：黄豆、青豆、豌豆等;
6.水果：柳橙、橘子、苹果、哈密瓜、奇异果、西瓜、柠檬、葡萄、葡萄柚、草莓、菠萝、柠檬等各种水果;
7.茄科：番茄、马铃薯、番茄薯、甜菜;
8.状花科：胡萝卜、芹菜、荷兰芹、胡荽、莳萝等。
阅读(0 次)
const和static readonly的区别
星期六 六月 07th 2008, 8:38 上午
类归于：
软件设计const
用于修改字段或局部变量的声明。它指定字段或局部变量的值是常数，不能被修改。常量的值必须在编译的时候确定，编译后，CLR将常量的值保存在Assembly的怨数据中。如果变量是const，那么他隐式的是static的。因此在声明常数的时候只需将该变量声明为const即可，而不允许在声明常数的时候使用static。
当代码引用常量时，CLR在元数据中查找该符号，将提取的常量值嵌入到IL中，所以常量没有地址以及相应的分配内存，而且不能通过引用传递变量
readonly
在字段上使用的修饰符，表示该字段是只读的。当一个字段在声明为readonly的时候，只有两种方式可以对其赋值，即作为声明的一部分出现，或者在同一类的构造函数中。
对于实例字段，在包含字段声明的类的实例构造函数中；或者，对于静态字段，在包含字段声明的类的静态构造函数中。也只有在这些上下文中，将 readonly 字段作为 out 或 ref 参数传递才有效。
static
声明属于类型本身而不是属于特定对象的静态成员，可用于类、字段、方法、属性、运算符、事件和构造函数，但不能用于索引器、析构函数或类以外的类型。
尽管类的实例包含该类所有实例字段的单独副本，但每个静态字段只有一个副本
不能通过类的实例引用静态成员，只可以通过类型名称引用它
如果对类应用 static 关键字，则该类的所有成员都必须是静态的
类（包括静态类）可以有静态构造函数。在程序开始和实例化类之间的某个时刻调用静态构造函数
const和readonly
const
1. 在编译期间解析的常量
2. 必须在声明就初始化
3. 既可用来修饰类中的成员，也可修饰函数体内的局部变量。
readonly
1. 在运行期间解析的常量，
2. 既可以在声明时初始化也可以在构造器中初始化，因此根据使用的构造函数，readonly的字段可能具有不同的值。
3. 只可以用于修饰类中的成员
const和static readonly
都表示静态的常量，赋值以后都不可以更改。
阅读(0 次)
数据库设计中的14个技巧
星期三 六月 04th 2008, 10:46 上午
类归于：
软件设计下述十四个技巧，是许多人在大量的数据库分析与设计实践中，逐步总结出来的。对于这些经验的运用，读者不能生帮硬套，死记硬背，而要消化理解，实事求是，灵活掌握。并逐步做到：在应用中发展，在发展中应用。
1. 原始单据与实体之间的关系
可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。
〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。
2. 主键与外键
一般而言，一个实体不能既无主键又无外键。在E?R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。
主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。
3. 基本表的性质
基本表与中间表、临时表不同，因为它具有如下四个特性：
(1) 原子性。基本表中的字段是不可再分解的。
(2) 原始性。基本表中的记录是原始数据（基础数据）的记录。
(3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。
(4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。
理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。
4. 范式标准
基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。
〖例2〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。
在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。
表1 商品表的表结构
商品名称 商品型号 单价 数量 金额
电视机 29? 2,500 40 100,000
5. 通俗地理解三个范式
通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：
第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；
第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；
第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余.
没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。
6. 要善于识别与正确处理多对多的关系
若两个实体之间存在多对多的关系，则应消除这种关系。消除的办法是，在两者之间增加第三个实体。这样，原来一个多对多的关系，现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个实体，实质上是一个较复杂的关系，它对应一张基本表。一般来讲，数据库设计工具不能识别多对多的关系，但能处理多对多的关系。
〖例3〗：在“图书馆信息系统”中，“图书”是一个实体，“读者”也是一个实体。这两个实体之间的关系，是一个典型的多对多关系：一本图书在不同时间可以被多个读者借阅，一个读者又可以借多本图书。为此，要在二者之间增加第三个实体，该实体取名为“借还书”，它的属性为：借还时间、借还标志(0表示借书，1表示还书)，另外，它还应该有两个外键(“图书”的主键，“读者”的主键)，使它能与“图书”和“读者”连接。
7. 主键PK的取值方法
PK是供程序员使用的表间连接工具，可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时，建议字段的个数不要太多，多了不但索引占用空间大，而且速度也慢。
8. 正确认识数据冗余
主键与外键在多表中的重复出现, 不属于数据冗余，这个概念必须清楚，事实上有许多人还不清楚。非键字段的重复出现, 才是数据冗余！而且是一种低级冗余，即重复性的冗余。高级冗余不是字段的重复出现，而是字段的派生出现。
〖例4〗：商品中的“单价、数量、金额”三个字段，“金额”就是由“单价”乘以“数量”派生出来的，它就是冗余，而且是一种高级冗余。冗余的目的是为了提高处理速度。只有低级冗余才会增加数据的不一致性，因为同一数据，可能从不同时间、地点、角色上多次录入。因此，我们提倡高级冗余(派生性冗余)，反对低级冗余(重复性冗余)。
9. E–R图没有标准答案
信息系统的E–R图没有标准答案，因为它的设计与画法不是惟一的，只要它覆盖了系统需求的业务范围和功能内容，就是可行的。反之要修改E–R图。尽管它没有惟一的标准答案，并不意味着可以随意设计。好的E?R图的标准是：结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余。
10. 视图技术在数据库设计中很有用
与基本表、代码表、中间表不同，视图是一种虚表，它依赖数据源的实表而存在。视图是供程序员使用数据库的一个窗口，是基表数据综合的一种形式, 是数据处理的一种方法，是用户数据保密的一种手段。为了进行复杂处理、提高运算速度和节省存储空间, 视图的定义深度一般不得超过三层。 若三层视图仍不够用, 则应在视图上定义临时表, 在临时表上再定义视图。这样反复交迭定义, 视图的深度就不受限制了。
对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统，视图的作用更加重要。这些系统的基本表完成物理设计之后，立即在基本表上建立第一层视图，这层视图的个数和结构，与基本表的个数和结构是完全相同。并且规定，所有的程序员，一律只准在视图上操作。只有数据库管理员，带着多个人员共同掌握的“安全钥匙”，才能直接在基本表上操作。请读者想想：这是为什么？
11. 中间表、报表和临时表
中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓库除外)。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员自己用程序自动维护。
12. 完整性约束表现在三个方面
域的完整性：用Check来实现约束，在数据库设计工具中，对字段的取值范围进行定义时，有一个Check按钮，通过它定义字段的值城。参照完整性：用PK、FK、表级触发器来实现。用户定义完整性：它是一些业务规则，用存储过程和触发器来实现。
13. 防止数据库设计打补丁的方法是“三少原则”
(1) 一个数据库中表的个数越少越好。只有表的个数少了，才能说明系统的E–R图少而精，去掉了重复的多余的实体，形成了对客观世界的高度抽象，进行了系统的数据集成，防止了打补丁式的设计；
(2) 一个表中组合主键的字段个数越少越好。因为主键的作用，一是建主键索引，二是做为子表的外键，所以组合主键的字段个数少了，不仅节省了运行时间，而且节省了索引存储空间；
(3) 一个表中的字段个数越少越好。只有字段的个数少了，才能说明在系统中不存在数据重复，且很少有数据冗余，更重要的是督促读者学会“列变行”，这样就防止了将子表中的字段拉入到主表中去，在主表中留下许多空余的字段。所谓“列变行”，就是将主表中的一部分内容拉出去，另外单独建一个子表。这个方法很简单，有的人就是不习惯、不采纳、不执行。
数据库设计的实用原则是：在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念，综合观点，不能孤立某一个原则。该原则是相对的，不是绝对的。“三多”原则肯定是错误的。试想：若覆盖系统同样的功能，一百个实体(共一千个属性) 的E–R图，肯定比二百个实体(共二千个属性) 的E–R图，要好得多。
提倡“三少”原则，是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成为应用数据库，将应用数据库集成为主题数据库，将主题数据库集成为全局综合数据库。集成的程度越高，数据共享性就越强，信息孤岛现象就越少，整个企业信息系统的全局E?R图中实体的个数、主键的个数、属性的个数就会越少。
提倡“三少”原则的目的，是防止读者利用打补丁技术，不断地对数据库进行增删改，使企业数据库变成了随意设计数据库表的“垃圾堆”，或数据库表的“大杂院”，最后造成数据库中的基本表、代码表、中间表、临时表杂乱无章，不计其数，导致企事业单位的信息系统无法维护而瘫痪。
“三多”原则任何人都可以做到，该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的原则，它要求有较高的数据库设计技巧与艺术，不是任何人都能做到的，因为该原则是杜绝用“打补丁方法”设计数据库的理论依据。
14. 提高数据库运行效率的办法
在给定的系统硬件和系统软件条件下，提高数据库系统的运行效率的办法是：
(1) 在数据库物理设计时，降低范式，增加冗余, 少用触发器, 多用存储过程。
(2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条)，复杂计算要先在数据库外面，以文件系统方式用C++语言计算处理完成之后，最后才入库追加到表中去。这是电信计费系统设计的经验。
(3) 发现某个表的记录太多，例如超过一千万条，则要对该表进行水平分割。水平分割的做法是，以该表主键PK的某个值为界线，将该表的记录水平分割为两个表。若发现某个表的字段太多，例如超过八十个，则垂直分割该表，将原来的一个表分解为两个表。
(4) 对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数。
(5) 在使用面向数据的SQL语言进行程序设计时，尽量采取优化算法。
总之，要提高数据库的运行效率，必须从数据库系统级优化、数据库设计级优化、程序实现级优化，这三个层次上同时下功夫。
阅读(0 次)
浅谈数据库设计技巧(下)
星期二 六月 03rd 2008, 10:10 上午
类归于：
软件设计三、多用户及其权限管理的设计
开发数据库管理类的软件，不可能不考虑多用户和用户权限设置的问题。尽管目前市面上的大、中型的后台数据库系统软件都提供了多用户，以及细至某个数据库内某张表的权限设置的功能，我个人建议：一套成熟的数据库管理软件，还是应该自行设计用户管理这块功能，原因有二：
1.那些大、中型后台数据库系统软件所提供的多用户及其权限设置都是针对数据库的共有属性，并不一定能完全满足某些特例的需求；
2.不要过多的依赖后台数据库系统软件的某些特殊功能，多种大、中型后台数据库系统软件之间并不完全兼容。否则一旦日后需要转换数据库平台或后台数据库系统软件版本升级，之前的架构设计很可能无法重用。 下面看看如何自行设计一套比较灵活的多用户管理模块，即该数据库管理软件的系统管理员可以自行添加新用户，修改已有用户的权限，删除已有用户。首先，分析用户需求，列出该数据库管理软件所有需要实现的功能；然后，根据一定的联系对这些功能进行分类，即把某类用户需使用的功能归为一类；最后开始建表：
功能表(Function_table)
名称 类型 约束条件 说明
f_id int 无重复 功能标识，主键
f_name char(20) 不允许为空 功能名称，不允许重复
f_desc char(50) 允许为空 功能描述
用户组表(User_group)
名称 类型 约束条件 说明
group_id int 无重复 用户组标识，主键
group_name char(20) 不允许为空 用户组名称
group_power char(100) 不允许为空 用户组权限表，内容为功能表f_id的集合
用户表(User_table)
名称 类型 约束条件 说明
user_id int 无重复 用户标识，主键
user_name char(20) 无重复 用户名
user_pwd char(20) 不允许为空 用户密码
user_type int 不允许为空 所属用户组标识，和User_group.group_id关联
采用这种用户组的架构设计，当需要添加新用户时，只需指定新用户所属的用户组；当以后系统需要添加新功能或对旧有功能权限进行修改时，只用操作功能表和用户组表的记录，原有用户的功能即可相应随之变化。当然，这种架构设计把数据库管理软件的功能判定移到了前台，使得前台开发相对复杂一些。但是，当用户数较大(10人以上)，或日后软件升级的概率较大时，这个代价是值得的。
四、简洁的批量m:n设计
碰到m:n的关系，一般都是建立3个表，m一个，n一个，m:n一个。但是，m:n有时会遇到批量处理的情况，例如到图书馆借书，一般都是允许用户同时借阅n本书，如果要求按批查询借阅记录，即列出某个用户某次借阅的所有书籍，该如何设计呢？让我们建好必须的3个表先：
书籍表(Book_table)
名称 类型 约束条件 说明
book_id int 无重复 书籍标识，主键
book_no char(20) 无重复 书籍编号
book_name char(100) 不允许为空 书籍名称
……
借阅用户表(Renter_table)
名称 类型 约束条件 说明
renter_id int 无重复 用户标识，主键
renter_name char(20) 不允许为空 用户姓名
……
借阅记录表(Rent_log)
名称 类型 约束条件 说明
rent_id int 无重复 借阅记录标识，主键
r_id int 不允许为空 用户标识，和Renter_table.renter_id关联
b_id int 不允许为空 书籍标识，和Book_table.book_id关联
rent_date datetime 不允许为空 借阅时间
……
为了实现按批查询借阅记录，我们可以再建一个表来保存批量借阅的信息，例如：
批量借阅表(Batch_rent)
名称 类型 约束条件 说明
batch_id int 无重复 批量借阅标识，主键
batch_no int 不允许为空 批量借阅编号，同一批借阅的batch_no相同
rent_id int 不允许为空 借阅记录标识，和Rent_log.rent_id关联
batch_date datetime 不允许为空 批量借阅时间
这样的设计好吗？我们来看看为了列出某个用户某次借阅的所有书籍，需要如何查询？首先检索批量借阅表(Batch_rent)，把符合条件的的所有记录的rent_id字段的数据保存起来，再用这些数据作为查询条件带入到借阅记录表(Rent_log)中去查询。那么，有没有什么办法改进呢？下面给出一种简洁的批量设计方案，不需添加新表，只需修改一下借阅记录表(Rent_log)即可。修改后的记录表(Rent_log)如下：
借阅记录表(Rent_log)
名称 类型 约束条件 说明
rent_id int 无重复 借阅记录标识，主键
r_id int 不允许为空 用户标识，和Renter_table.renter_id关联
b_id int 不允许为空 书籍标识，和Book_table.book_id关联
batch_no int 不允许为空 批量借阅编号，同一批借阅的batch_no相同
rent_date datetime 不允许为空 借阅时间
……
其中，同一次借阅的batch_no和该批第一条入库的rent_id相同。举例：假设当前最大rent_id是64，接着某用户一次借阅了3本书，则批量插入的3条借阅记录的batch_no都是65。之后另外一个用户租了一套碟，再插入出租记录的rent_id是68。采用这种设计，查询批量借阅的信息时，只需使用一条标准T_SQL的嵌套查询即可。当然，这种设计不符合3NF，但是和上面标准的3NF设计比起来，哪一种更好呢？答案就不用我说了吧。
五、冗余数据的取舍
上篇的“树型关系的数据表”中保留了一个冗余字段，这里的例子更进一步——添加了一个冗余表。先看看例子：我原先所在的公司为了解决员工的工作餐，和附近的一家小餐馆联系，每天吃饭记账，费用按人数平摊，月底由公司现金结算，每个人每个月的工作餐费从工资中扣除。当然，每天吃饭的人员和人数都不是固定的，而且，由于每顿工作餐的所点的菜色不同，每顿的花费也不相同。例如，星期一中餐5人花费40元，晚餐2人花费20，星期二中餐6人花费36元，晚餐3人花费18元。为了方便计算每个人每个月的工作餐费，我写了一个简陋的就餐记账管理程序，数据库里有3个表：
员工表(Clerk_table)
名称 类型 约束条件 说明
clerk_id int 无重复 员工标识，主键
clerk_name char(10) 不允许为空 员工姓名
每餐总表(Eatdata1)
名称 类型 约束条件 说明
totle_id int 无重复 每餐总表标识，主键
persons char(100) 不允许为空 就餐员工的员工标识集合
eat_date datetime 不允许为空 就餐日期
eat_type char(1) 不允许为空 就餐类型，用来区分中、晚餐
totle_price money 不允许为空 每餐总花费
persons_num int 不允许为空 就餐人数
就餐计费细表(Eatdata2)
名称 类型 约束条件 说明
id int 无重复 就餐计费细表标识，主键
t_id int 不允许为空 每餐总表标识，和Eatdata1.totle_id关联
c_id int 不允许为空 员工标识标识，和Clerk_table.clerk_id关联
price money 不允许为空 每人每餐花费
其中，就餐计费细表(Eatdata2)的记录就是把每餐总表(Eatdata1)的一条记录按就餐员工平摊拆开，是个不折不扣的冗余表。当然，也可以把每餐总表(Eatdata1)的部分字段合并到就餐计费细表(Eatdata2)中，这样每餐总表(Eatdata1)就成了冗余表，不过这样所设计出来的就餐计费细表重复数据更多，相比来说还是上面的方案好些。但是，就是就餐计费细表(Eatdata2)这个冗余表，在做每月每人餐费统计的时候，大大简化了编程的复杂度，只用类似这么一条查询语句即可统计出每人每月的寄餐次数和餐费总帐：
SELECT clerk_name AS personname,COUNT(c_id) as eattimes,SUM(price) AS ptprice FROM Eatdata2 JOIN Clerk_tabsle ON (c_id=clerk_id) JOIN eatdata1 ON (totleid=tid) WHERE eat_date>=CONVERT(datetime,’”&the_date&”‘) AND eat_date<DATEADD(month,1,CONVERT(datetime,’”&the_date&”‘)) GROUP BY c_id
想象一下，如果不用这个冗余表，每次统计每人每月的餐费总帐时会多麻烦，程序效率也够呛。那么，到底什么时候可以增加一定的冗余数据呢？我认为有2个原则：
１、用户的整体需求。当用户更多的关注于，对数据库的规范记录按一定的算法进行处理后，再列出的数据。如果该算法可以直接利用后台数据库系统的内嵌函数来完成，此时可以适当的增加冗余字段，甚至冗余表来保存这些经过算法处理后的数据。要知道，对于大批量数据的查询，修改或删除，后台数据库系统的效率远远高于我们自己编写的代码。
２、简化开发的复杂度。现代软件开发，实现同样的功能，方法有很多。尽管不必要求程序员精通绝大部分的开发工具和平台，但是还是需要了解哪种方法搭配哪种开发工具的程序更简洁，效率更高一些。冗余数据的本质就是用空间换时间，尤其是目前硬件的发展远远高于软件，所以适当的冗余是可以接受的。不过我还是在最后再强调一下：不要过多的依赖平台和开发工具的特性来简化开发，这个度要是没把握好的话，后期维护升级会栽大跟头的。
阅读(0 次)
浅谈数据库设计技巧(上)
星期二 六月 03rd 2008, 10:09 上午
类归于：
软件设计说到数据库，我认为不能不先谈数据结构。1996年，在我初入大学学习计算机编程时，当时的老师就告诉我们说：计算机程序＝数据结构＋算法。尽管现在的程序开发已由面向过程为主逐步过渡到面向对象为主，但我还是深深赞同8年前老师的告诉我们的公式：计算机程序＝数据结构＋算法。面向对象的程序开发，要做的第一件事就是，先分析整个程序中需处理的数据，从中提取出抽象模板，以这个抽象模板设计类，再在其中逐步添加处理其数据的函数(即算法)，最后，再给类中的数据成员和函数划分访问权限，从而实现封装。 数据库的最初雏形据说源自美国一个奶牛场的记账薄(纸质的，由此可见，数据库并不一定是存储在电脑里的数据^_^)，里面记录的是该奶牛场的收支账目，程序员在将其整理、录入到电脑中时从中受到启发。当按照规定好的数据结构所采集到的数据量大到一定程度后，出于程序执行效率的考虑，程序员将其中的检索、更新维护等功能分离出来，做成单独调用的模块，这个模块后来就慢慢发展、演变成现在我们所接触到的数据库管理系统(DBMS)——程序开发中的一个重要分支。
下面进入正题，首先按我个人所接触过的程序给数据库设计人员的功底分一下类：
１、没有系统学习过数据结构的程序员。这类程序员的作品往往只是他们的即兴玩具，他们往往习惯只设计有限的几个表，实现某类功能的数据全部塞在一个表中，各表之间几乎毫无关联。网上不少的免费管理软件都是这样的东西，当程序功能有限，数据量不多的时候，其程序运行起来没有什么问题，但是如果用其管理比较重要的数据，风险性非常大。
２、系统学习过数据结构，但是还没有开发过对程序效率要求比较高的管理软件的程序员。这类人多半刚从学校毕业不久，他们在设计数据库表结构时，严格按照教科书上的规定，死扣E-R图和3NF(别灰心，所有的数据库设计高手都是从这一步开始的)。他们的作品，对于一般的access型轻量级的管理软件，已经够用。但是一旦该系统需要添加新功能，原有的数据库表差不多得进行大换血。
３、第二类程序员，在经历过数次程序效率的提升，以及功能升级的折腾后，终于升级成为数据库设计的老鸟，第一类程序员眼中的高人。这类程序员可以胜任二十个表以上的中型商业数据管理系统的开发工作。他们知道该在什么样的情况下保留一定的冗余数据来提高程序效率，而且其设计的数据库可拓展性较好，当用户需要添加新功能时，原有数据库表只需做少量修改即可。
４、在经历过上十个类似数据库管理软件的重复设计后，第三类程序员中坚持下来没有转行，而是希望从中找出“偷懒”窍门的有心人会慢慢觉悟，从而完成量变到质变的转换。他们所设计的数据库表结构有一定的远见，能够预测到未来功能升级所需要的数据，从而预先留下伏笔。这类程序员目前大多晋级成数据挖掘方面的高级软件开发人员。
５、第三类程序员或第四类程序员，在对现有的各家数据库管理系统的原理和开发都有一定的钻研后，要么在其基础上进行二次开发，要么自行开发一套有自主版权的通用数据库管理系统。
我个人正处于第三类的末期，所以下面所列出的一些设计技巧只适合第二类和部分第三类数据库设计人员。同时，由于我很少碰到有兴趣在这方面深钻下去的同行，所以文中难免出现错误和遗漏，在此先行声明，欢迎大家指正，不要藏私哦8)
一、树型关系的数据表
不少程序员在进行数据库设计的时候都遇到过树型关系的数据，例如常见的类别表，即一个大类，下面有若干个子类，某些子类又有子类这样的情况。当类别不确定，用户希望可以在任意类别下添加新的子类，或者删除某个类别和其下的所有子类，而且预计以后其数量会逐步增长，此时我们就会考虑用一个数据表来保存这些数据。按照教科书上的教导，第二类程序员大概会设计出类似这样的数据表结构：
类别表_1(Type_table_1)
名称 类型 约束条件 说明
type_id int 无重复 类别标识，主键
type_name char(50) 不允许为空 类型名称，不允许重复
type_father int 不允许为空 该类别的父类别标识，如果是顶节点的话设定为某个唯一值
这样的设计短小精悍，完全满足3NF，而且可以满足用户的所有要求。是不是这样就行呢？答案是NO！Why？
我们来估计一下用户希望如何罗列出这个表的数据的。对用户而言，他当然期望按他所设定的层次关系一次罗列出所有的类别，例如这样：
总类别
类别1
类别1.1
类别1.1.1
类别1.2
类别2
类别2.1
类别3
类别3.1
类别3.2
……
看看为了实现这样的列表显示(树的先序遍历)，要对上面的表进行多少次检索？注意，尽管类别1.1.1可能是在类别3.2之后添加的记录，答案仍然是N次。这样的效率对于少量的数据没什么影响，但是日后类型扩充到数十条甚至上百条记录后，单单列一次类型就要检索数十次该表，整个程序的运行效率就不敢恭维了。或许第二类程序员会说，那我再建一个临时数组或临时表，专门保存类型表的先序遍历结果，这样只在第一次运行时检索数十次，再次罗列所有的类型关系时就直接读那个临时数组或临时表就行了。其实，用不着再去分配一块新的内存来保存这些数据，只要对数据表进行一定的扩充，再对添加类型的数量进行一下约束就行了，要完成上面的列表只需一次检索就行了。下面是扩充后的数据表结构：
类别表_2(Type_table_2)
名称 类型 约束条件 说明
type_id int 无重复 类别标识，主键
type_name char(50) 不允许为空 类型名称，不允许重复
type_father int 不允许为空 该类别的父类别标识，如果是顶节点的话设定为某个唯一值
type_layer char(6) 限定3层,初始值为000000 类别的先序遍历，主要为减少检索数据库的次数
按照这样的表结构，我们来看看上面例子记录在表中的数据是怎样的：
type_id type_name type_father type_layer
1 总类别 0 000000
2 类别1 1 010000
3 类别1.1 2 010100
4 类别1.2 2 010200
5 类别2 1 020000
6 类别2.1 5 020100
7 类别3 1 030000
8 类别3.1 7 030100
9 类别3.2 7 030200
10 类别1.1.1 3 010101
……
现在按type_layer的大小来检索一下：SELECT * FROM Type_table_2 ORDER BY type_layer
列出记录集如下：
type_id type_name type_father type_layer
1 总类别 0 000000
2 类别1 1 010000
3 类别1.1 2 010100
10 类别1.1.1 3 010101
4 类别1.2 2 010200
5 类别2 1 020000
6 类别2.1 5 020100
7 类别3 1 030000
8 类别3.1 7 030100
9 类别3.2 7 030200
……
现在列出的记录顺序正好是先序遍历的结果。在控制显示类别的层次时，只要对type_layer字段中的数值进行判断，每2位一组，如大于0则向右移2个空格。当然，我这个例子中设定的限制条件是最多3层，每层最多可设99个子类别，只要按用户的需求情况修改一下type_layer的长度和位数，即可更改限制层数和子类别数。其实，上面的设计不单单只在类别表中用到，网上某些可按树型列表显示的论坛程序大多采用类似的设计。
或许有人认为，Type_table_2中的type_father字段是冗余数据，可以除去。如果这样，在插入、删除某个类别的时候，就得对type_layer 的内容进行比较繁琐的判定，所以我并没有消去type_father字段，这也正符合数据库设计中适当保留冗余数据的来降低程序复杂度的原则，后面我会举一个故意增加数据冗余的案例。
二、商品信息表的设计
假设你是一家百货公司电脑部的开发人员，某天老板要求你为公司开发一套网上电子商务平台，该百货公司有数千种商品出售，不过目前仅打算先在网上销售数十种方便运输的商品，当然，以后可能会陆续在该电子商务平台上增加新的商品出售。现在开始进行该平台数据库的商品信息表的设计。每种出售的商品都会有相同的属性，如商品编号，商品名称，商品所属类别，相关信息，供货厂商，内含件数，库存，进货价，销售价，优惠价。你很快就设计出4个表：商品类型表(Wares_type)，供货厂商表(Wares_provider)，商品信息表(Wares_info)：
商品类型表(Wares_type)
名称 类型 约束条件 说明
type_id int 无重复 类别标识，主键
type_name char(50) 不允许为空 类型名称，不允许重复
type_father int 不允许为空 该类别的父类别标识，如果是顶节点的话设定为某个唯一值
type_layer char(6) 限定3层,初始值为000000 类别的先序遍历，主要为减少检索数据库的次数
供货厂商表(Wares_provider)
名称 类型 约束条件 说明
provider_id int 无重复 供货商标识，主键
provider_name char(100) 不允许为空 供货商名称
商品信息表(Wares_info)
名称 类型 约束条件 说明
wares_id int 无重复 商品标识，主键
wares_name char(100) 不允许为空 商品名称
wares_type int 不允许为空 商品类型标识，和Wares_type.type_id关联
wares_info char(200) 允许为空 相关信息
provider int 不允许为空 供货厂商标识，和Wares_provider.provider_id关联
setnum int 初始值为1 内含件数，默认为1
stock int 初始值为0 库存，默认为0
buy_price money 不允许为空 进货价
sell_price money 不允许为空 销售价
discount money 不允许为空 优惠价
你拿着这3个表给老板检查，老板希望能够再添加一个商品图片的字段，不过只有一部分商品有图片。OK，你在商品信息表(Wares_info)中增加了一个haspic的BOOL型字段，然后再建了一个新表——商品图片表(Wares_pic)：
商品图片表(Wares_pic)
名称 类型 约束条件 说明
pic_id int 无重复 商品图片标识，主键
wares_id int 不允许为空 所属商品标识，和Wares_info.wares_id关联
pic_address char(200) 不允许为空 图片存放路径
程序开发完成后，完全满足老板目前的要求，于是正式启用。一段时间后，老板打算在这套平台上推出新的商品销售，其中，某类商品全部都需添加“长度”的属性。第一轮折腾来了……当然，你按照添加商品图片表的老方法，在商品信息表(Wares_info)中增加了一个haslength的BOOL型字段，又建了一个新表——商品长度表(Wares_length)：
商品长度表(Wares_length)
名称 类型 约束条件 说明
length_id int 无重复 商品图片标识，主键
wares_id int 不允许为空 所属商品标识，和Wares_info.wares_id关联
length char(20) 不允许为空 商品长度说明
刚刚改完没多久，老板又打算上一批新的商品，这次某类商品全部需要添加“宽度”的属性。你咬了咬牙，又照方抓药，添加了商品宽度表(Wares_width)。又过了一段时间，老板新上的商品中有一些需要添加“高度”的属性，你是不是开始觉得你所设计的数据库按照这种方式增长下去，很快就能变成一个迷宫呢？那么，有没有什么办法遏制这种不可预见性，但却类似重复的数据库膨胀呢？我在阅读《敏捷软件开发：原则、模式与实践》中发现作者举过类似的例子：7.3 “Copy”程序。其中，我非常赞同敏捷软件开发这个观点：在最初几乎不进行预先设计，但是一旦需求发生变化，此时作为一名追求卓越的程序员，应该从头审查整个架构设计，在此次修改中设计出能够满足日后类似修改的系统架构。下面是我在需要添加“长度”的属性时所提供的修改方案：
去掉商品信息表(Wares_info)中的haspic字段，添加商品额外属性表(Wares_ex_property)和商品额外信息表(Wares_ex_info)2个表来完成添加新属性的功能。
商品额外属性表(Wares_ex_property)
名称 类型 约束条件 说明
ex_pid int 无重复 商品额外属性标识，主键
p_name char(20) 不允许为空 额外属性名称
商品额外信息表(Wares_ex_info)
名称 类型 约束条件 说明
ex_iid int 无重复 商品额外信息标识，主键
wares_id int 不允许为空 所属商品标识，和Wares_info.wares_id关联
property_id int 不允许为空 商品额外属性标识，和Wares_ex_property.ex_pid关联
property_value char(200) 不允许为空 商品额外属性值
在商品额外属性表(Wares_ex_property)中添加2条记录：
ex_pid p_name
1 商品图片
2 商品长度
再在整个电子商务平台的后台管理功能中追加一项商品额外属性管理的功能，以后添加新的商品时出现新的属性，只需利用该功能往商品额外属性表(Wares_ex_property)中添加一条记录即可。不要害怕变化，被第一颗子弹击中并不是坏事，坏的是被相同轨道飞来的第二颗、第三颗子弹击中。第一颗子弹来得越早，所受的伤越重，之后的抵抗力也越强8)(待续)
阅读(0 次)
飞行员总结自己开车有太多不良习惯
星期六 五月 17th 2008, 9:18 上午
类归于：
娱乐搞笑1、上坡时老是向后拉方向盘；
2、总觉得速度小；
3、见了交通警察总想说些啥；
4、老是以为油门在右手；
5、减速的时候老想用减速板；
6、遇到红灯时的第一个念头就是想转一圈；
7、右座没有人就觉得不对劲；
8、下车后老是想提个包包啥的下车；
9、老是喜欢压着黄实线开车；
10、每次加油都不想给钱，只想签个字就走人；
11、转弯时，总不喜欢打转向灯，还觉得应该带点坡度；
12、安全带总觉得少了一条；
13、下坡时，总往前推方向盘；
14、停车熄火后，拉起手刹还想旋转一下；
15、总觉得汽车的按钮开关没飞机多，老把里程表当高度表；
16、比前车快，想要超车的时候，既不往左，也不往右，就对正前车，一打油门，往后拉方向盘；
17、上路前，先找检查单逐项核对车况；
18、发动机熄火时，跟交警报告：发动机失效，请求协助；
19、总想看仪表，相信仪表，不注意观察外面；
20、老是想有人送上咖啡。
21、有朋友搭便车时，要先看一看人家的加机组证明（公务乘机通行证）；
22、学车时第一次上车，师傅说标准动作是两手握方向盘，只有在需要时才换档。结果我们三个人（一个教员、两个正驾驶）都是一个毛病，左手握方向盘，右手握排挡。后来听说公司里在他那里学车的飞行员都是一个模子里刻出来的动作；
23、出门遇上下雪天就想找防冰开关；
24、看到有别的车抢档就要向交警投诉；
25、一有雾就想开雷达；
26、停车不好停时老想找引导车；
27、汽车开动后老想开应答机；
阅读(0 次)
青春无悔–同学毕业留念(图)
星期三 四月 30th 2008, 7:32 上午
类归于：
娱乐搞笑青春无悔–同学毕业留念
近日，网络上流传着这样一篇文章《谁能告诉我：女学生如此大胆裸拍到底为什么》，帖子中刊载了数张穿着暴露的女中学生照片，据文章透露，这是部分女同学受网络正红火的“赤裸特工”事件和“艳照门”事件启发，自发组织、自制的一份毕业留念人体电子相册，传到网上电子相册时未加密码导致流出。该组照片在网上一露面，就引起轩然大波，专家认为，“艳照门”等系列事件会给心智发育尚未成熟的中小学生们带来不良影响。
暴露的女中学生照片
暴露的女中学生照片
中学女生另类毕业照网上传
“太疯狂了!”这是帖子的作者、网民“君傲”用以引领全文的一句感慨。他表示，自己无意中进了一个90后女生的个人网页，随意点开一个叫《青春无悔——同学毕业留念》的专辑相册，“一下子就傻眼了。”原来其中图片非常大胆，几乎全是一些90后女生摆着各种大胆姿势的自拍裸照或半裸照，据称，“照片数量有惊人的百张之多，而且没有一个人是重复的。” 如此多的照片，如此大胆的尺度，又涉及如此众多的90后女生——这让“君傲”萌生了对照片进行调查的念头。
在顺利成为网页主人的QQ好友之后，“君傲”很快旁敲侧击地弄清了照片的由来——据这名90后女生说，他们年级的部分女同学在交换初中毕业留念照片时，受当时网络正红火的“赤裸特工”事件和“艳照门”事件启发，决定别出心裁，自发组织、自制一份毕业留念人体电子相册，名为“青春无悔”，要求参与的女同学每人提供全裸或半裸照片一张，自拍或艺术照片不限，相册制成后给提供照片者人手一份，以作留念。而没想到的是，此活动开始后，有大量即将毕业的女同学都表示支持并提供了形形色色的照片，后来，甚至其他年级的女生闻讯都主动表示要参加，最终提供照片的女生人数竟然超过了150人。在两人交谈的最后，90后女生明确表示并不在意自己置于主页的这些“艳照”被人看到，更问了一个让“君傲”大跌眼镜的问题，“照片上，我的身材你觉得性感吗?”
一帖激起千层浪
尽管从那位90后女生口中得知，她在照片贴出的两个小时后便已为相册设定了密码，“君傲”恰在之前进入这才得以一见，但调查的结果，照片的尺度与主角们年龄的强烈反差，以及女生言语中那种无所谓的态度还是让“君傲”大感震惊。他当即将自己的所见写成文章发到了网上，并留下了一连串“感叹号”：90一代啊，如此暴露的图片你们也敢上网来晒!难道网络对你们的影响真有如此之大!是我的思想太过保守还是你们的理念太过于前卫!看来，有孩子的父母真要重视网络对孩子们的负面影响了!不然，90版艳照很快就会再现网络!搞不好其中就有你的孩子……
短短三天，这篇帖子在网上引起了轩然大波，近500网友在原帖后留言热议，网络各大论坛中也纷纷出现了此文的转帖，所到之处无不是一片哗然。记者发现，虽然部分网友怀疑帖子本身的真实性，质疑发帖人或所谓的“90后女生”的身份，认为只是一次基于吸引眼球目的的拙劣炒作。但更多的跟帖者则是与“君傲”共鸣：网友chengwulibin不无激愤地表示“你还认为艳照门是无足轻重的事情么?它已经开始毒害青少年了，它会扭曲他们的价值观和荣辱观!”“ayxtlzc”高呼，“太不可思议了!90后的女孩们不要太疯狂了，否则最后哭的还是你们自己!”网友“大猫”则认为，“年纪不大，学的不良东西倒不少，家长真应该多和孩子们沟通。”……
关注网络时代的青春
昨日记者就此事采访了一些社会心理学以及教育学方面的专家学者，综合大家的观点有三：首先，如那位90后女生所说，她们产生拍艳照的想法是受了“艳照门”事件的影响，这多少证实了一个当时“艳照门”事件发生后便已被广泛提及的担忧，就是媒体和网络在传播报道一些事件时，是否过分追求话题性而忽视了导向性?其次，自拍艳照的提议在中学女生中竟会“一呼百应”，如果事情属实，那就不能再简单地用“偶然性”和“单一性”去界定它，这多少反映了一种“过分开放”和“过分浮躁”的心态已在年轻一代中具有了某种共性，这暴露了网络时代来临后，学校和家庭对年轻一代的教育还是存在疏漏和不足，如何让青少年尽可能规避网络世界的不良影响因素，并通过教育、沟通让他们及早形成面对网络趋利避害的自主能力，是相关职能部门、网络运营者和家长、学校们需要共同重视的问题。最后，90后毕竟还是一个心态并未完全成熟的群体，对他们的所作所为，应尽量地理解、包容和冷静，“君傲”对照片的关注和痛心态度值得肯定，但他把照片置于网络传播的做法值得商榷，因为由此引发的批评、指责且无论那些90后们一下子能否承受，其意义和作用也可能会适得其反。 (来源：扬子晚报 作者：张磊)
青春无悔–同学毕业留念
阅读(0 次)
Windows 死机代码全解析
星期五 四月 11th 2008, 2:57 上午
类归于：
未分类使用Windows出现蓝色屏幕是经常的事,而且每每因为不清楚错误的来源而频繁重新安装系统,劳神费时.下列收集了一些Windows死机密码,供大家参考.
0×0000 操作完成
0×0001 不正确的函数
0×0002 系统找不到指定的文件
0×0003 系统找不到指定Sample TextSample TextSample Text的路径
0×0004 系统无法打开文件
0×0005 拒绝存取
0×0006 无效的代码
0×0007 内存控制模块已损坏
0×0008 内存空间不足，无法处理这个指令
0×0009 内存控制模块地址无效
0×000a 环境不正确
0×000b 尝试载入一个格式错误的程序
0×000c 存取码错误
0×000d 资料错误
0×000e 内存空间不够，无法完成这项操作
0×000f 系统找不到制定的硬盘
0×0010 无法移除目录
0×0011 系统无法将文件移到其他的硬盘
0×0012 没有任何文件
0×0019 找不到指定的扇区或磁道
0×001a 指定的磁盘或磁片无法存取
0×001b 磁盘找不到要求的扇区
0×001c 打印机没有纸
0×001d 系统无法将资料写入制定的磁盘
0×001e 系统无法读取指定的装置
0×001f 连接到系统的某个装置没有作用
0×0021 文件的一部分被锁定
0×0024 开启的分享文件数量太多
0×0026 到达文件结尾
0×0027 磁盘已满
0×0036 网络繁忙
0×003b 网络发生意外的错误
0×0043 网络名称找不到
0×0050 文件已经存在
0×0052 无法建立目录或文件
0×0053 int24失败
0×006b 因为代用的磁盘尚未插入，所以程序已经停止
0×006c 磁盘正在使用中或被锁定
0×006f 文件名太长
0×0070 硬盘空间不足
0×007f 找不到指定的程序
0×045b 系统正在关机
0×045c 无法种植系统关机，因为没有关机的动作在进行中
0×046a 可用服务器储存空间不足，无法处理这项指令
0×047e 指定的程序需要新的Windows版本
0×047f 指定的程序不是Windows或MS-DOS程序
0×0480 指定的程序已经启动，无法再启动一次
0×0481 指定的程序是为旧版的Windows所写的
0×0482 执行此应用程序所需的程序库文件之一毁坏
0×0483 没有应用程序与此项操作的指定文件建立关联
0×0484 传送指令到应用程序发生错误
0×04b0 指定的装置名称无效
0×05a2 窗口不是子窗口
0×05aa 系统资源不足，无法完成所要求的服务
0×05ab 系统子还不足，无法完成所需要的服务
0×05ac 系统资源不足，无法完成所要求的服务
0×06b9 资源不足，无法完成操作
阅读(0 次)