回复整理 080307
2008-03-07 22:09 金色海洋（jyk） 阅读(512) 评论(0) 编辑 收藏 举报 向怪怪学习，做一个回帖整理。
http://www.cnblogs.com/soundbbg/archive/2008/03/07/1094937.html
一个综合设计感想-shangducms NT
2008-03-07 20:17 | 金色海洋（jyk）
2008-03-07 21:56 | 金色海洋（jyk）
封装
这个就不用考虑了吧，一定要用的。
基类不就是一种封装吗？
也许我对封装的理解不对吧。
===============================================
http://www.cnblogs.com/leonbao/archive/2008/03/07/1094821.html
关于SQL Server数据库设计的感悟，请指教
2008-03-07 21:32 金色海洋（jyk）
这个就不用考虑了吧，一定要用的。
基类不就是一种封装吗？
也许我对封装的理解不对吧。
===============================================
http://www.cnblogs.com/leonbao/archive/2008/03/07/1094821.html
关于SQL Server数据库设计的感悟，请指教
2008-03-07 21:32 金色海洋（jyk）
关于主键，我的做法那就是完全相反了。
我使用 int 自增的那种，而且会加上聚集索引（就是不会在手动的去掉），不是因为我懒，而是我认为这么作很有必要。
引用你举的那个字典的例子。
拼音检索是聚集索引，字典是根据汉字的拼音来确定排列的前后顺序，就是说字典要根据字的读音来判断这个字到底放在哪里，就是放在第几页，第几行。
部首检索，记录的是什么呢？字的所在页号，那么这个页号是怎么确定的呢？根据读音。
就是说先有聚集索引，然后才能有非聚集索引，而你说的“压根就不设”其实是不存在的，即使你不设，数据库也会帮你设一个的，要不然非聚集索引怎么做呢？
数据库里的记录也像字典里的汉字一样，也需要确定谁放在前面，谁放在后面的问题，我觉得使用自增的int字段是最好的选择，
这样可以加快修改和删除数据的速度，也会加快多表关联的速度；对于添加，也完全不会增加负担，因为新增的数据是放在最后，根本就不用移动其他的记录。
当然int字段也是有缺点的，看情况了。我现在遇到的情况都是发挥了它的优点，没遇到它的缺点的情况。
2008-03-07 21:47 金色海洋（jyk）
我使用 int 自增的那种，而且会加上聚集索引（就是不会在手动的去掉），不是因为我懒，而是我认为这么作很有必要。
引用你举的那个字典的例子。
拼音检索是聚集索引，字典是根据汉字的拼音来确定排列的前后顺序，就是说字典要根据字的读音来判断这个字到底放在哪里，就是放在第几页，第几行。
部首检索，记录的是什么呢？字的所在页号，那么这个页号是怎么确定的呢？根据读音。
就是说先有聚集索引，然后才能有非聚集索引，而你说的“压根就不设”其实是不存在的，即使你不设，数据库也会帮你设一个的，要不然非聚集索引怎么做呢？
数据库里的记录也像字典里的汉字一样，也需要确定谁放在前面，谁放在后面的问题，我觉得使用自增的int字段是最好的选择，
这样可以加快修改和删除数据的速度，也会加快多表关联的速度；对于添加，也完全不会增加负担，因为新增的数据是放在最后，根本就不用移动其他的记录。
当然int字段也是有缺点的，看情况了。我现在遇到的情况都是发挥了它的优点，没遇到它的缺点的情况。
2008-03-07 21:47 金色海洋（jyk）
1、表的主键使用GUID 类型，而且建立后要去掉聚集所用。
2、表的外键，应该也是GUID 类型的吧，为了提高打开视图的时间，把所有的外键字段都加上了非聚集索引。
3、
某回复：“用guid作索引简直就是糟蹋了索引”
回答：“我从来就没说过用guid做索引啊 ”
如果我的第二点的猜测是正确的话，那么是不是有点矛盾了呢？
4、非聚合索引就是对应每条内容的地址
我的理解是：非聚合索引就是对应每条内容的 主键。
您说的“地址”是什么呢？记录在硬盘的位置吗（扇区），想不出来这个地址是什么？
我为什么会觉得是对应主键呢？因为主键是不变的，而地址（不管指的是什么）我想应该是会变的。
请设想一种情况，当你的数据库从A电脑拷贝到B电脑之后，这个地址会不变吗？变了的话，非聚集索引怎么办？
因为你最后说了：请多提意见。
所以我就看得比较细，提了一点自己的看法，我没有故意挑你的毛病的意思，请不要误会。
=========================================
http://www.cnblogs.com/flashwind/archive/2008/03/07/1094737.html
故事与模式(1)
2008-03-07 20:02 | 金色海洋（jyk）
2、表的外键，应该也是GUID 类型的吧，为了提高打开视图的时间，把所有的外键字段都加上了非聚集索引。
3、
某回复：“用guid作索引简直就是糟蹋了索引”
回答：“我从来就没说过用guid做索引啊 ”
如果我的第二点的猜测是正确的话，那么是不是有点矛盾了呢？
4、非聚合索引就是对应每条内容的地址
我的理解是：非聚合索引就是对应每条内容的 主键。
您说的“地址”是什么呢？记录在硬盘的位置吗（扇区），想不出来这个地址是什么？
我为什么会觉得是对应主键呢？因为主键是不变的，而地址（不管指的是什么）我想应该是会变的。
请设想一种情况，当你的数据库从A电脑拷贝到B电脑之后，这个地址会不变吗？变了的话，非聚集索引怎么办？
因为你最后说了：请多提意见。
所以我就看得比较细，提了一点自己的看法，我没有故意挑你的毛病的意思，请不要误会。
=========================================
http://www.cnblogs.com/flashwind/archive/2008/03/07/1094737.html
故事与模式(1)
2008-03-07 20:02 | 金色海洋（jyk）
没看明白博主讲的是那种模式呢？
另外提点偏硬件的问题，可能和博主的意图不太一制，请原谅。
CPU和主板是要配套的，如果要给加一个判断，某个cpu只能和某某主板配合使用，而不能和某某主板配合使用，因为插槽是不一样的，呵呵。如何处理呢？
cpu有不同的接口（插槽），内存有ddr1 和 ddr2，显卡有AGP 和 PIC-E，这些都要和主板对应上。
这里提出了一个问题，可能你觉得这个问题和你的设计和你要讲解的问题（设计模式）毫不相干，但是他却是一个确实存在的问题。
我说的是后话了，就是说在当初设计的时候，由于种种原因，没有得到客户的某个要求，或者是某种情况，到了测试阶段（或者实施阶段）才发现，那么这时候要如何应对，如何快速、完美的处理。这时最难的吧。
[楼主] 2008-03-07 21:42 | 雾里清风
另外提点偏硬件的问题，可能和博主的意图不太一制，请原谅。
CPU和主板是要配套的，如果要给加一个判断，某个cpu只能和某某主板配合使用，而不能和某某主板配合使用，因为插槽是不一样的，呵呵。如何处理呢？
cpu有不同的接口（插槽），内存有ddr1 和 ddr2，显卡有AGP 和 PIC-E，这些都要和主板对应上。
这里提出了一个问题，可能你觉得这个问题和你的设计和你要讲解的问题（设计模式）毫不相干，但是他却是一个确实存在的问题。
我说的是后话了，就是说在当初设计的时候，由于种种原因，没有得到客户的某个要求，或者是某种情况，到了测试阶段（或者实施阶段）才发现，那么这时候要如何应对，如何快速、完美的处理。这时最难的吧。
[楼主] 2008-03-07 21:42 | 雾里清风
@金色海洋（jyk）
感谢你的关注，这是Builder模式
真实情况肯定比这复杂多，电脑主版跟其他的部件有一定的耦合。不是靠一个小小的模式能搞定的。
一个复杂的系统如果能把所有变化的可能性考虑进去太难了。我非常同意你的最后一句话。
感谢你的关注，这是Builder模式
真实情况肯定比这复杂多，电脑主版跟其他的部件有一定的耦合。不是靠一个小小的模式能搞定的。
一个复杂的系统如果能把所有变化的可能性考虑进去太难了。我非常同意你的最后一句话。
