置顶随笔
最近我的一位好朋友，先是母亲检查出来已经是癌症晚期，然后父亲又发现胃癌，昨晚喝酒，朋友说我这些天白头发多了不少，哎，一切都是关于健康的消息，想想自己也曾经熬夜奋战，也曾经斗志昂扬，再想想健康，自己的脊椎，从颈部到腰，都时常疼痛，朋友们，工作的同时也不要忽略了自己的健康。
posted @
2008-07-08 13:40 PerfectDesign 阅读(1969) |
评论 (5) |
编辑
摘要: 上文介绍了微软的Passport和传统的SSO在软件架构上的失败，都需要将用户名密码存储到一个地方，那样谁都不愿意，除非一方特别强势，不然谷歌和百度是谁都不愿意妥协的。
那么有什么办法来解决这个用户凭证的存储问题呢？
阅读全文
posted @
2008-04-23 22:46 PerfectDesign 阅读(2285) |
评论 (12) |
编辑
摘要: 微软在过去的身份验证服务上，一直采用的Passport验证，但已经是N年前推出来的一个软件架构，当然也被软件界很多地方采用到，由于很多安全问题以及隐私问题，导致05年eBay与Passport分手，相继不少公司也与微软身份验证服务分道扬镳。为何会这样呢？这还得从Passport流程说起：
阅读全文
posted @
2008-04-23 17:29 PerfectDesign 阅读(2386) |
评论 (17) |
编辑
2008年7月14日
一位DBA朋友狼总结了一个关于此方面的几个原则，其实我们在设计的时候也是在不经意间也遵循了这些原则，拿来跟大家共享一下，特别有感于这些天面试程序员，简历上写精通数据库设计，一问就说几个范式，其他冗余的数据都是垃圾，偶真是比较汗颜啊。。。。
不废话了，原则如下：
反规范化设计
为了提升性能而使用反规范化设计
常用方法：
A、在多个表中存储某个字段的副本
B、在父表中存储汇总值
C、将活动数据和历史数据分开存储
D、应用程序本地缓存数据
E、使用临时表、中间表、索引视图
大家如果还有其他原则，可以跟帖，谢谢！
posted @
2008-07-14 14:35 PerfectDesign 阅读(1283) |
评论 (3) |
编辑
2008年7月8日
最近我的一位好朋友，先是母亲检查出来已经是癌症晚期，然后父亲又发现胃癌，昨晚喝酒，朋友说我这些天白头发多了不少，哎，一切都是关于健康的消息，想想自己也曾经熬夜奋战，也曾经斗志昂扬，再想想健康，自己的脊椎，从颈部到腰，都时常疼痛，朋友们，工作的同时也不要忽略了自己的健康。
posted @
2008-07-08 13:40 PerfectDesign 阅读(1969) |
评论 (5) |
编辑
2008年6月29日
Storing data in a scalable web application can be tricky. A user
could be interacting with any of dozens of web servers at a given time,
and the user's next request could go to a different web server than the
one that handled the previous request. All web servers need to be
interacting with data that is also spread out across dozens of
machines, possibly in different locations around the world.
Thanks to Google App Engine, you don't have to worry about any of
that. App Engine's infrastructure takes care of all of the
distribution, replication and load balancing of data behind a simple
API—and you get a powerful query engine and transactions as well.
The App Engine datastore has a sophisticated query engine for data
models. Because the App Engine datastore is not a traditional
relational database, queries are not specified using SQL. Instead, you
can prepare queries using a SQL-like query language we call GQL. GQL
provides access to the App Engine datastore query engine's features
using a familiar syntax.
posted @
2008-06-29 18:09 PerfectDesign 阅读(3724) |
评论 (0) |
编辑
摘要:
阅读全文
posted @
2008-06-29 17:15 PerfectDesign 阅读(4051) |
评论 (0) |
编辑
2008年6月24日
这个问题困扰我好几天了，生产数据库上时常会出现
用户 'xxxx' 登录失败。 [客户端: <local machine>] （来自事件管理器）
但是服务器重启后就好了，数据库重启没有用。数据库服务器基于的用户名密码的验证方式，非windows集成验证。
没有人修改config文件，查毒也没有。
各位有遇到这种情况的吗？
附数据库版本：
Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86) Oct 14 2005 00:33:37 Copyright (c) 1988-2005 Microsoft Corporation Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2)
posted @
2008-06-24 09:59 PerfectDesign 阅读(5337) |
评论 (8) |
编辑
2008年5月28日
今天改的一个存储过程发现改了还是效率低下，仔细看了看，原来那个是一个IP日志表，因为没有适当的索引，导致全表的聚集扫描，速度非常慢。仔细分析了一下：
IPLog：
一个自增ID，一个访问时间，一个访问次数，一个IP，4个字段，80万记录。
索引：一个聚集索引在自增ID上。
执行以下语句：
set statistics io on
set statistics time on
exec IPLogInsert '255.255.255.255'
结果：
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。
表 'IPLog'。扫描计数 1，逻辑读取 3737 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
SQL Server 执行时间:
CPU 时间 = 172 毫秒，占用时间 = 514 毫秒。
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。
表 'IPLog'。扫描计数 0，逻辑读取 3 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 252 毫秒。
SQL Server 执行时间:
CPU 时间 = 172 毫秒，占用时间 = 771 毫秒。
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。
优化：
将自增ID去掉，将聚集索引建在accesstime上
执行同样语句结果如下：
SQL Server 分析和编译时间:
CPU 时间 = 16 毫秒，占用时间 = 30 毫秒。
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。
表 'IPLog'。扫描计数 1，逻辑读取 4 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 24 毫秒。
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。
表 'IPLog'。扫描计数 0，逻辑读取 3 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 6 毫秒。
SQL Server 执行时间:
CPU 时间 = 16 毫秒，占用时间 = 61 毫秒。
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。
很鲜明的对比，这就是我一直强调的日志类型表不要建ID的典型范例。
附
[IPLogInsert]详细：
-- =============================================
-- Author: Xiangxiang
-- Create date:2008-5-29
-- Description: Insert a IP log
-- =============================================
alter PROCEDURE [dbo].[IPLogInsert]
@IP char(15) = '255.255.255.255'
AS
BEGIN
SET NOCOUNT ON;
declare @currId int
declare @today datetime
--SET @currID = 0
SET @today = getdate()
--SELECT @currId = id from IPLog
--where convert(char(10), @today,101) = convert(char(10),AccessTime, 101) and @IP = IP if( @currID = 0)
-- insert into IPLog (AccessTime,IP,[Count])
-- values (@today, @IP, 1)
-- else
-- update IPLog
-- SET [count]=[count]+1
-- WHERE convert(char(10), @today,101) = convert(char(10),AccessTime, 101) and @IP = IP
-- END
update IPlog set Count = Count+1
where Ip = @IP
and AccessTime between dateadd(day,1,datediff(day,0,@today-1)) and dateadd(day,1,datediff(day,0,@today))
if(@@rowcount =0)
begin
insert into IPLog (AccessTime,IP,[Count])
values (@today,@IP,1)
end
end
posted @
2008-05-28 21:58 PerfectDesign 阅读(173) |
评论 (4) |
编辑
到新公司先看了看数据库的性能，查看一个存储占用的CPU巨多，而且执行次数也特别多，打开一看：
alter PROCEDURE [dbo].[IPLogInsert]
@IP char(15) = '255.255.255.255'
AS
BEGIN
SET NOCOUNT ON;
declare @currId int
declare @today datetime
--SET @currID = 0
SET @today = getdate()
SELECT @currId = id from IPLog
where convert(char(10), @today,101) = convert(char(10),AccessTime, 101) and @IP = IP if( @currID = 0)
insert into IPLog (AccessTime,IP,[Count])
values (@today, @IP, 1)
else
update IPLog
SET [count]=[count]+1
WHERE convert(char(10), @today,101) = convert(char(10),AccessTime, 101) and @IP = IP
END
很是汗颜啊！一个简单的需求被写成了这样。
最后我改成的是：
update IPlog set Count = Count+1 where Ip = @IP and AccessTime between dateadd(day,1,datediff(day,0,@today-1)) and dateadd(day,1,datediff(day,0,@today))
if(@@rowcount =0)
begin
insert into IPLog (AccessTime,IP,[Count])
values (@today,@IP,1)
前一个是将字段转成了char然后再比较，很无赖啊。
posted @
2008-05-28 17:35 PerfectDesign 阅读(36) |
评论 (0) |
编辑