MSSQL网页编程之数据库视图的利用

刚安装好的MySql包含一个含空密码的root帐户和一个匿名帐户，这是很大的安全隐患，对于一些重要的应用我们应将安全性尽可能提高，在这里应把匿名帐户删除、root帐户设置密码视图|数据|数据库
　

明天用了一把数据库中的视图，事变是如许，实践请求从约10多个数据表中查询出5个了局集传送给另外一个模块。入手下手筹办间接用sql语句，但感到很欠好，一个一个的写sql语句，一个字累。很天然地想到了视图，历程很复杂，如许做的优点是将程序中两个逻辑分隔，视图界说好了，程序中间接select每一个字段就好，省往了贫苦的innerjoin&outerjoin，并且看上往更加明晰。
另外一个长处是：如许做极年夜的延长了事情工夫，一旦试图界说好了，哗哗哗几下了局就出来了；一旦堕落即刻能够找到毛病的地点，明晰开阔爽朗，并且在界说视图的时分利用便利的isnull()等帮助函数，更削减了第二模块的事情量。

视图的界说办法：（形如.）

CREATEVIEWdbo.group_UserJoin
AS
SELECTuu_GroupUser.user_id,uu_GroupInfo.group_name,
uu_RegisterUser.user_name,uu_GroupUser.join_time
FROMuu_GroupUserINNERJOIN
uu_GroupInfoON
uu_GroupUser.group_id=uu_GroupInfo.group_idINNERJOIN
uu_RegisterUserONuu_GroupUser.user_id=uu_RegisterUser.user_id
[WITHCHECKOPTION]


Archive非常适合存储大量的独立的，作为历史记录的数据。因为它们不经常被读取。Archive拥有高效的插入速度，但其对查询的支持相对较差

无法深入到数据库系统层面去了解和探究

一个百万级别的基本信息表A，一个百万级别的详细记录表B，A中有个身份证id，B中也有身份id；先要找出A中在B的详细记录。

原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。

微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数据库的一些概念可以实现了。

而写到本地,我又考虑到效率问题.大家来讨论讨论吧,分数不打紧,就给10分,十全十美,没啥对错,各抒己见,但是要有说服力的哦~

数据库物理框架没有变动undo和redo都放在数据库得transaction中，个人感觉是个败笔。如果说我们在设计数据库的时候考虑分多个数据库，可能能在一定程度上避免I/O效率问题。

还不是性能有问题！否则面向对象的数据库早就实现了！建议使用CLR的地方一般是和应用的复杂程度或操作系统环境有很高的耦合度的场景。如你想构建复杂的算法，并且用到了大量的指针和高级数据模型。