Thứ Ba, 22 tháng 5, 2012

Tạo Widgets bài viết liên quan cho Blogger BlogSpot

Bắt đầu: Đăng nhập vào Blogger bằng tài khoản Gmail của các bạn. Chọn blog các bạn muốn chỉnh sửa: 

Thiết kế -> Chỉnh sửa HTML, đánh vào ô Mở rộng mẫu tiện ích 



CtrL + F tìm đến thẻ </head> trong Templates của các bạn và thêm đoạn code sau trước thẻ này: 

<style> #related-posts { float : left; width : 540px; margin-top:20px; margin-left : 5px; margin-bottom:20px; font : 11px Verdana; margin-bottom:10px; } #related-posts .widget { list-style-type : none; margin : 5px 0 5px 0; padding : 0; } #related-posts .widget h2, #related-posts h2 { font-size : 20px; font-weight : normal; margin : 5px 7px 0; padding : 0 0 5px; } #related-posts a { text-decoration : none; } #related-posts a:hover { text-decoration : none; } #related-posts ul { border : medium none; margin : 10px; padding : 0; } #related-posts ul li { display : block; background : url("https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgnvQEOMH7PD47gfcjxcNkzdr-VzQ3BkJxainJpZZgOYwsDmm0Yt4aX1ReErBiMY-PoOra3efmjyJ02A8znmyTK4BgbpCqqCszzr3NQkoYXCgdZzfueCeLfLcIfb2Hf4Cmpr3SlSgn4sQU/") no-repeat 0 0; margin : 0; padding-top : 0; padding-right : 0; padding-bottom : 1px; padding-left : 21px; margin-bottom : 5px; line-height : 2em; border-bottom:1px dotted #cccccc; } </style> <script src='http://vntim.googlecode.com/files/VnTim%20Related%20Posts%20Skill%20Link.js' type='text/javascript'/>

Tiếp đến, tìm <data:post.body/> (hoặc <div class='post-body'> ) và thêm vào ở dưới đoạn code các các bạn vừa tìm được: 

<b:if cond='data:blog.pageType == "item"'>
<div id="related-posts">
<font face='Arial' size='3'><b>Related Posts : </b></font><font color='#FFFFFF'><b:loop values='data:post.labels' var='label'><data:label.name/><b:if cond='data:label.isLast != &quot;true&quot;'>,</b:if><b:if cond='data:blog.pageType == &quot;item&quot;'>
<script expr:src='&quot;/feeds/posts/default/-/&quot; + data:label.name + &quot;?alt=json-in-script&amp;callback=related_results_labels&amp;max-results=5&quot;' type='text/javascript'/></b:if></b:loop> </font>
<script type='text/javascript'> removeRelatedDuplicates(); printRelatedLabels();
</script>
</div></b:if>

Cuối cùng là Save lại

Làm Sao Giảm Bớt Dung Lượng File LOG Của SQL Server



Vũ Minh Tâm

Vào một ngày đẹp trời, bạn nhận thấy rằng file LOG của mình quá lớn, chiếm gần hết ổ cứng và không thể thực hiện bất kì một thao tác nào trên dữ liệu.
Hay bạn thấy, trong khi dữ liệu của mình chỉ có vài GB, mà file LOG lên đến tận hàng trăm GB.
Phải làm thế nào ?
Có rất nhiều cách để giải quyết vấn đề này
- Detach DB, xóa file LOG, sau đấy ATTACH lại DB
Tuy nhiên với CSDL đòi hỏi tính sẵn sàng cao, thì ko mấy ai cho phép bạn làm điều này.
- Backup LOG với OpTION là TRUNCATE_ONLY hoặc NO_LOG
Với phiên bản SQL Server 2008 thì đã bỏ Option này
SQL Server 2005 Books Online:
“[TRUNCATE_ONLY]
This option will be removed in a future version of SQL Server. Avoid using it in new development work, and plan to modify applications that currently use it.
We recommend that you never use NO_LOG or TRUNCATE_ONLY to manually truncate the transaction log…”.
Tôi thường dùng cách thứ 3.
Giả sử DB của tôi là Test.
File Data : Test_Data.MDF
File Log  : Test_Log.LDF
USE Test;
GO
 
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE Test
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (Test_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE Test
SET RECOVERY FULL;
GO
Giải thích
- Có 3 chế độ Recovery trong SQL Server , FULL, SIMPLE và BULK LOGGED
Chế độ mặc định là FULL.
Bạn có thể vào phần Option của DB, xem trong Recovery Model.
Khi ở chế độ này,  bất kì một transaction nào, kể cả khi đã commit cũng đều được lưu trong LOG, do đó có thể dựa vào những transaction này để “quay lui (rollback)” DB về bất kì thời điểm nào. Vì thế với những DB có Transaction nhiều, DATA ít thì file LOG vẫn có thể rất lớn.
- Đầu tiên SET RECOVERY của DB về SIMPLE, ở chế độ này, sau khi transaction được COMMIT, sẽ tự động xóa. Do vậy File LOG của DB ở chế độ này thường rất nhỏ.
- Dùng DBCC SHRINKFILE để SHRINK file log xuống còn 1 Mb
Nếu không set Recovery về SIMPLE, thì sẽ ko thể xóa bỏ hết các transaction đã được COMMIT.
SHRINKFILE chỉ thu dọn và sắp xếp  và phân bố lại dữ liệu, bỏ các vùng trống để giải phóng bộ nhớ, chứ không phải xóa dữ liệu. Vì thế ở chế độ FULL, SHRINKFILE hầu như ko tác dụng, hoặc nếu có thì file LOG dung lượng giảm đi ko đáng kể.
- Sau đó SET RECOVERY về lại FULL
Trên MSDN cũng khuyên nếu muốn Backup LOG, các bạn nên chuyển về chế độ SIMPLE, hơn là backup LOG với Truncate_Only và No_LOG
* Chú ý: Với những DB lớn, có kế hoạch Backup riêng, bạn cần hỏi ý kiến của DBA trước khi thực hiện. Vì một vài chế độ BackUp dựa rất nhiều vào file LOG.
Tuy nhiên nếu có DBA, thì không bao giờ để xảy ra trường hợp này, vì công việc của họ là thường xuyên theo dõi, giám sát và xử lý  để Server hoạt động tốt.
Nguồn www.sqlviet.com

Các Chế Độ Phục Hồi Của Database



Vũ Huy Tâm

Chế độ phục hồi (recovery model) là thuộc tính của database, liên quan đến cơ chế sử dụng log file và do đó, liên quan đến khả năng khôi phục dữ liệu của database. Các model đó là FULL, SIMPLE, và BULK-LOGGED.
Bạn có thể xem và thay đổi chế độ phục hồi của database bằng code như sau:
-- lấy chế độ phục hồi hiện tại của database
SELECT recovery_model_desc FROM SYS.databases WHERE name='AUXDB'
 
-- thiết lập chế độ phục hồi cho database
ALTER DATABASE AUXDB SET RECOVERY FULL
ALTER DATABASE AUXDB SET RECOVERY SIMPLE
ALTER DATABASE AUXDB SET RECOVERY BULK_LOGGED
Bạn cũng có thể dùng giao diện trong Management Studio bằng cách right-click vào database, chọn Properties, rồi chuyển tới tab Options:
FULL: Lưu tất cả các transaction tuần tự trong log file và giữ chúng ở đó đến khi log file được backup. Khi log backup được thực hiện, các transaction xảy ra kể từ lần log backup trước được ghi ra backup file và loại bỏ khỏi log file. Chính xác ra là chúng được đánh dấu là đã được backup và có thể được ghi đè bởi các transaction đến sau. Nếu là lần log backup đầu tiên kể từ khi database được tạo thì nó gồm tất cả transaction từ lần full backup. Vì thế bạn chỉ có thể backup log nếu (1) recovery model là FULL và (2) database đã từng được full backup.
Ở chế độ FULL, các transaction được lưu nguyên vẹn và thành chuỗi liên tục. Khi được sao lưu log backup định kỳ, database có thể được khôi phục tới một thời điểm bất kỳ, và do đó hạn chế tối đa mất mát dữ liệu khi có sự cố xảy ra. Đây là chế độ cần thiết cho các OLTP database, và cũng là chế độ mặc định mỗi khi database mới được tạo.
Cũng vì các transaction được lưu nguyên vẹn đến khi được log backup, nếu bạn không thực hiện log backup định kỳ kích thước của log file sẽ không ngừng tăng lên. Khi log file đầy, SQL Server sẽ xin cấp phát thêm không gian đĩa để log file có thể chứa thêm transaction. Nếu bạn đặt kích thước tối đa cho log file và đã tăng tới kích thước này, hoặc đĩa hết chỗ trống, SQL Server sẽ báo lỗi và hủy bỏ transaction.
Có thể so sánh chế độ FULL với quyển sổ ghi nhật ký hàng ngày của bạn. Giả sử bạn muốn giữ quyển sổ nhật ký luôn có độ dày 100 trang. Cứ mỗi tuần bạn lại sao lưu các trang đã viết bằng cách xé chúng khỏi sổ và cất vào tủ, đồng thời thêm ngần đấy trang trắng vào thay thế. Các trang trắng này lại được dùng để viết nhật ký cho các ngày tiếp. Nếu không sao lưu, bạn không thể thêm trang trắng vào sổ và chằng bao lâu cuốn sổ sẽ đầy không còn chỗ để viết tiếp. Muốn viết tiếp bạn phải tăng số trang của quyển sổ lên hơn 100 và thêm các trang trắng vào cuối.
SIMPLE: Chế độ SIMPLE không quan tâm đến chuyện log đã được backup hay chưa. Mỗi khi transaction kết thúc, nó sẽ được đánh dấu là cho phép ghi đè lên và các transaction tiếp theo sẽ dùng lại không gian đó. Vì thế log backup không thể thực hiện ở chế độ này và kích thước log file cũng không bị tăng liên tục. Tuy nhiên trong nội bộ 1 transaction, các cập nhật vẫn được lưu vào log file đầy đủ, và log file vẫn cần đủ lớn để chứa các cập nhật này. Vì thế kích thước log file tương đương với kích thước của transaction lớn nhất đã từng được thực hiện trong database. Trở lại việc so sánh tương đồng với sổ nhật ký, chế độ SIMPLE giống như khi viết đến trang cuối thì bạn quay lại trang đầu, tẩy hết những gì đã viết và viết đè lên đó.
Vì không thể thực hiện được log backup, chế độ SIMPLE không cho phép khả năng khôi phục dữ liệu đến một thời điểm nhất định. Bạn chỉ có thể khôi phục lại dữ liệu từ bản full backup (hoặc differential backup) gần đây nhất. Do đó chế độ này không thích hợp với các hệ thống OLTP. Tuy nhiên do ưu điểm giảm nhẹ gánh nặng về quản lý log file bạn có thể đặt chế độ này cho các database ở môi trường development. Bạn cũng có thể chọn đặt chế độ này cho các database phục vụ báo cáo, database cho các ứng dụng DW/BI.
BULK-LOGGED: Chế độ này hoạt động giống như chế độ FULL, tuy nhiên nó chỉ log tối thiểu các thao tác bulk (liên quan đến nhiều bản ghi) như bcp, BULK INSERT, hay SELECT INTO. Điều này giúp cho các thao tác trên thực hiện nhanh hơn, vì không phải log chi tiết từng thay đổi như với chế độ FULL. Giống như FULL, chế độ này vẫn đòi hỏi phải backup log định kỳ nếu không kích thước log file sẽ tăng. Nhưng nó lại mất khả năng khôi phục tới một thời điểm nhất định như với chế độ FULL. Bản thân tôi không nhìn thấy nhiều giá trị của chế độ BULK-LOGGED.
Nguồn www.sqlviet.com

Các Loại Ràng Buộc Trong SQL Server


Vũ Huy Tâm

Ràng buộc trong SQL Server được dùng để duy trì tính nhất quán của dữ liệu, đảm bảo dữ liệu phù hợp với các qui định theo yêu cầu của bài toán. Ví dụ một database về bán hàng đòi hỏi mỗi bản ghi phải có ID sản phẩm hợp lệ, số lượng bán phải là một số nguyên và giá bán phải lớn hơn 0. Đó là các yêu cầu về tính nhất quán của dữ liệu và các ràng buộc cần được khai báo để thực thi các yêu cầu này. Do đó, ràng buộc giúp ngăn chặn dữ liệu không hợp lệ và chỉ cho phép dữ liệu hợp lệ được lưu vào database.
SQL Server cung cấp các loại ràng buộc sau:
PRIMARY KEY: khóa chính của bảng, là định danh duy nhất cho mỗi bản ghi trong bảng. Nó đòi hỏi cột (hoặc các cột) tạo thành khóa chính phải thỏa mãn hai điều kiện: không NULL và mỗi giá trị phải duy nhất trong toàn bảng. Mỗi bảng chỉ cho phép tối đa một khóa chính và theo nguyên tắc thiết kế, mỗi bảng đều cần có khóa chính. Có ba cách khai báo khóa chính:
--Cách 1
CREATE TABLE dbo.Bang(
Cot_1 INT NOT NULL PRIMARY KEY,
Cot_2 VARCHAR(100),
...
)
 
--Cách 2
CREATE TABLE dbo.Bang(
Cot_1 INT NOT NULL,
Cot_2 VARCHAR(100),
...
CONSTRAINT PK_Bang PRIMARY KEY (Cot_1, Cot_2)
)
 
--Cách 3, thêm ràng buộc cho bảng đã có sẵn
ALTER TABLE dbo.Bang ADD CONSTRAINT PK_Bang PRIMARY KEY (Cot_1, Cot_2)
Khi có khai báo khóa chính, SQL Server tự động tạo một unique index để thực thi tính duy nhất. Đây là cách làm tối ưu để kiểm tra xem một giá trị có duy nhất hay không. Mỗi khi có giá trị mới được thêm vào hay được cập nhật, hệ thống sẽ định vị trên cây index để tìm vị trí thích hợp cho nó. Nếu giá trị này đã xuất hiện, hệ thống sẽ văng ngược trở ra và báo lỗi. Ngược lại, giá trị mới được lưu vào cây index.
Index được tạo cùng với khóa chính một cách mặc định là clustered index. Bạn có thể chỉ định nó là non-clustered khi cần thiết, nhưng thông thường bạn nên để ở chế độ mặc định.
Bạn nên chọn trường có kích thước nhỏ làm khóa chính. Khi có nhiều trường kết hợp với nhau xác định định danh của bản ghi (ví dụ ba trường tên, ngày sinh và nguyên quán của bảng thí sinh), bạn có thể tạo thêm một trường THISINH_ID kiểu INTEGER làm đại diện và dùng nó làm khóa chính, và đưa ba trường kia vào một khóa duy nhất (xem phần dưới đây).
UNIQUE KEY CONSTRAINT: ràng buộc duy nhất, yêu cầu các giá trị trong cột phải khác nhau. Ràng buộc này cho phép cột hoặc các cột cấu thành khóa phải là NULL, tuy nhiên chỉ một giá trị NULL được phép xuất hiện (về khác biệt giữa định nghĩa khóa duy nhất của ANSI và SQL Server, mời bạn đọc thêm bài Tạo Ràng Buộc Duy Nhất Bằng Filtered Index). Bạn có thể tạo nhiều ràng buộc duy nhất trên cùng một bảng. Ràng buộc duy nhất cũng kéo theo một unique index giống như với khóa chính, và cơ chế kiểm tra tính duy nhất cũng giống như vậy. Điểm khác là unique index được tạo ở đây mặc định là non-clustered, trừ khi bạn chỉ định nó là clustered.
Bạn có thể thấy về mặt logic, ràng buộc duy nhất cộng thêm NOT NULL tương đương với khóa chính. Và ngoại trừ một vài khác biệt nhỏ, tạo một unique index trên cột cũng tương đương với tạo ràng buộc duy nhất trên cột đó.
Tạo ràng buộc duy nhất:
ALTER TABLE ThiSinh ADD CONSTRAINT UC_ThiSinh UNIQUE (Ten, NgaySinh, NguyenQuan)
FOREIGN KEY: ràng buộc khóa ngoại. Nó đòi hỏi cột chỉ được phép chứa giá trị xuất hiện trong cột khóa chính của bảng khác. Ràng buộc này đảm bảo tính toàn vẹn tham chiếu dữ liệu. Ví dụ với database bán hàng, bạn có bảng SanPham với SanPham_ID là khóa chính, và bảng BanHang có trường SanPham_ID với mục đích chứa ID của các sản phẩm có trong bảng SanPham. Khi đó, bạn cần tạo ràng buộc khóa ngoại trên trường Sanpham_ID của bảng BanHang, tham chiếu đến trường Sanpham_ID của bảng SanPham. Ràng buộc này đảm bảo:
- Không ai có thể đưa các giá trị SanPham_ID “tầm bậy” vào bảng BanHang. Các giá trị đều phải tồn tại trong bảng SanPham. Ví dụ, bảng SanPham chứa các ID từ 1 – 100; bạn không thể thêm một bản ghi vào bảng BanHang với SanPham_ID = 101. Nói cách khác, các hóa đơn bán hàng phải chứa các sản phẩm đã có trong danh mục.
- Nếu một SanPham_ID đã xuất hiện trong bảng BanHang (sản phẩm đã có giao dịch), không ai có thể xóa bản ghi của SanPham_ID đó trong bảng SanPham. Ví dụ, trong bảng SanPham có chứa sản phẩm Kindle Fire với ID = 52; sau khi có giao dịch bán hàng trên sản phẩm này, bảng BanHang sẽ xuất hiện bản ghi với SanPham_ID = 52; khi đó bạn không thể xóa bản ghi của Kindle Fire khỏi bảng SanPham, vì bản ghi kia trong bảng BanHang sẽ trở nên mồ côi (tham chiếu đến một sản phẩm ID không tồn tại).
Code:
ALTER TABLE dbo.BanHang ADD CONSTRAINT FK_SanPham_ID FOREIGN KEY (SanPham_ID) REFERENCES dbo.SanPham(SanPham_ID)
Một vài lưu ý với ràng buộc khóa ngoại:
- Tuy cột là khóa của bảng, nhưng các giá trị cho phép của nó lại được qui định từ một cột ở bảng khác. Vì thế có tên gọi khóa ngoại.
- Cột được tham chiếu phải là unique (primary key hoặc unique key).
- Bảng được tham chiếu phải nằm trong cùng database.
NOT NULL: ràng buộc này đơn giản là yêu cầu dữ liệu nhập vào cho cột phải chứa giá trị chứ không được để NULL. Khi bạn sửa lại một cột thành NOT NULL của bảng đã chứa dữ liệu (dùng ALTER TABLE), Toàn bộ các bản ghi của bảng đó sẽ được kiểm tra. Nếu hệ thống tìm thấy NULL nó sẽ báo lỗi và hủy bỏ lệnh ALTER TABLE. Lệnh sau sửa lại cột SanPham_ID thành NOT NULL:
ALTER TABLE dbo.BanHang ALTER TABLE SanPham_ID INT NOT NULL
DEFAULT: ràng buộc mặc định. Khi nhập dữ liệu cho bảng mà cột đó không được cung cấp giá trị thì giá trị mặc định sẽ được sử dụng. Ví dụ bạn có thể tạo ràng buộc DEFAULT cho trường NgayGD (ngày giao dịch) của bảng bán hàng là ngày giờ hệ thống:
ALTER TABLE dbo.BanHang ADD CONSTRAINT DF_NgayGD DEFAULT GETDATE() FOR NgayGD
CHECK: ràng buộc kiểm tra. Yêu cầu cột tương ứng phải thỏa mãn một biểu thức logic. Ví dụ, ràng buộc sau đòi hỏi cột SL (số lượng) phải lớn hơn 0:
ALTER TABLE dbo.BanHang ADD CONSTRAINT Chk_SL CHECK (SL>0)
Bạn có thể dùng hàm trong biểu thức của ràng buộc check, miễn là hàm phải thuộc loại trả về giá trị đơn (scalar function, không được dùng hàm kiểu bảng).
* Lưu ý
Bạn có thể thắc mắc, tất cả các ràng buộc trên đây đều có thể tự viết code để thực hiện. Ví dụ thay vì tạo ràng buộc duy nhất, trước khi insert bạn có thể thêm lệnh IF EXISTS để kiểm tra xem giá trị đã tồn tại hay chưa, và chỉ cho insert nếu không tồn tại. Vậy tại sao cần khai báo các ràng buộc? Lý do thứ nhất là tính đơn giản, bạn chỉ cần khai báo một lần mà không cần viết lại code. Thứ hai là đây là hàng rào cuối cùng và tin cậy để kiểm tra xem dữ liệu có hợp lệ hay không. Khi viết code bạn chỉ có thể đảm bảo cho ứng dụng của bạn, còn những ứng dụng khác cùng truy nhập vào database sẽ nằm ngoài tầm kiểm soát của bạn. Thậm chí cùng một ứng dụng khi được viết vào những thời điểm khác nhau, bạn cũng không thể nhớ hết mỗi cột tuân theo những ràng buộc nào. Trong khi những ràng buộc được khai báo trong database nằm ngay bên ngoài vỏ của dữ liệu, và thực thi các kiểm tra khi dữ liệu đi vào dù bằng đường nào. Lý do nữa là ràng buộc có thể giúp tối ưu hóa thực hiện câu lệnh. Ví dụ một cột có ràng buộc CHECK giá trị phải lớn hơn 0; khi gặp câu lệnh tìm trên cột đó với giá trị âm, hệ thống sẽ tức thì trả về 0 bản ghi thay vì phải tìm từng bản ghi trong bảng.
Nguồn www.sqlviet.com

Sử Dụng Hàm ROW_NUMBER


Vũ Huy Tâm


Hàm ROW_NUMBER được đưa vào từ bản 2005, dùng để trả về một con số tuần tự gắn với mỗi bản ghi (do đó có tên như vậy, số của bản ghi). Hàm này giúp giải quyết một số bài toán dễ dàng hơn. Bài viết này giới thiệu hai ứng dụng của hàm ROW_NUMBER, nếu bạn có sử dụng hàm này vào những tình huống khác xin hãy bổ sung ở phần comment.
1. Phân trang: Đây là ứng dụng khá phổ biến của hàm ROW_NUMBER và chỉ khai thác một dạng thức đơn giản của hàm. Trong ví dụ dưới đây tôi dựa vào dữ liệu từ database AdventureWorks. Giả sử tôi có một trang web hiển thị các đơn bán hàng trong tháng 6/2004. Vì có khá nhiều đơn hàng (hơn 2000) nên tôi muốn chia làm nhiều trang với mỗi trang chỉ hiển thị 100 đơn hàng. Khi muốn liệt kê đơn hàng cho trang thứ hai (đơn hàng từ 101-200) tôi có thể dùng code như sau:
SELECT * 
FROM(
 SELECT SalesOrderID, CustomerID, OrderDate, ROW_NUMBER() OVER(ORDER BY OrderDate) RN
 FROM Sales.SalesOrderHeader
 WHERE OrderDate BETWEEN '2004-06-01' AND '2004-06-30'
) a
WHERE RN BETWEEN 101 AND 200
ORDER BY OrderDate
Cú pháp tổng quát của hàm là ROW_NUMBER() OVER(), rườm rà hơn các hàm thông thường. Trong ví dụ trên, “ROW_NUMBER() OVER(ORDER BY OrderDate)” nghĩa là gán một con số tăng tuần tự cho mỗi bản ghi theo thứ tự của OrderDate, bắt đầu từ 1. Trong trường hợp tổng quát, bạn có thể viết một thủ tục và nhận các tham số vào là kích thước trang và số trang để tăng khả năng tùy biến:
ALTER PROC dbo.pGetOrder
@PageSize INT,
@PageNum INT
AS
SELECT * 
FROM(
 SELECT SalesOrderID, CustomerID, OrderDate, ROW_NUMBER() OVER(ORDER BY OrderDate) RN
 FROM Sales.SalesOrderHeader
 WHERE OrderDate BETWEEN '2004-06-01' AND '2004-06-30'
) a
WHERE RN BETWEEN (@PageNum-1)*@PageSize+1 AND @PageNum*@PageSize
ORDER BY OrderDate 
GO
 
-- ví dụ: 50 bản ghi mỗi trang và lấy cho trang 3
EXEC dbo.pGetOrder 50, 3
Ở bản SQL Server 2000, giải pháp cho bài toán trên thường là SELECT vào một bảng tạm vốn đã có một trường IDENTITY, và sau đó SELECT từ bảng tạm với điều kiện lọc trường IDENTITY nằm trong khoảng cần trả về. Cách làm dùng hàm ROW_NUMBER ở trên gọn gàng hơn một chút, tuy nhiên về hiệu năng tôi cho là cả hai cách đều giống nhau.
2. Lấy về TOP bản ghi theo chủng loại: Cũng dựa vào ví dụ trên, giả sử nay tôi muốn lấy về top 5 đơn hàng có trị giá lớn nhất tại mỗi vùng (TerritoryID). Như vậy nếu có 10 vùng thì tôi sẽ nhận được 50 bản ghi trong đó mỗi vùng chiếm 5 bản ghi chứa các đơn hàng có giá trị lớn nhất của vùng đó:
SELECT *
FROM (
 SELECT TerritoryID, SalesOrderID, TotalDue, ROW_NUMBER() OVER(PARTITION BY TerritoryID ORDER BY TotalDue DESC) RN
 FROM Sales.SalesOrderHeader
 WHERE OrderDate BETWEEN '2004-06-01' AND '2004-06-30') a
WHERE RN <=5
Ở ví dụ trên hàm có sử dụng thêm mệnh đề “PARTITION BY TerritoryID” để chỉ định rằng giá trị chỉ tăng tuần tự trong phạm vi của TerritoryID, khi gặp một TerritoryID mới thì reset lại giá trị từ 1. Còn mệnh đề “ORDER BY TotalDue DESC” đảm nhiệm sắp xếp các bản ghi theo thứ tự TotalDue giảm dần. Do đó bản ghi có TotalDue lớn nhất được gán là 1, bản ghi tiếp theo là 2… Đến khi gặp TerritoryID mới nó lại lặp lại quá trình đó và bản ghi có TotalDue lớn nhất ở TerritoryID mới này lại được gán là 1 và cứ tiếp tục như thế. Ở đây bạn mới thấy thế mạnh của hàm ROW_NUMBER. Trước kia khi muốn làm một điều tương tự, chắc bạn vẫn phải SELECT vào một bảng tạm rồi dùng một thuật toán rất loằng ngoằng để gán số thứ tự cho các bản ghi như vậy.
Nguồn www.sqlviet.com

Top 35 WordPress Plugin Được Download Nhiều Nhất

Hiện nay, có hàng triệu wordpress plugins được tạo ra và đăng lên WordPress Directory để các blogger có thể dễ dàng sử dụng theo các mục đích khác nhau. Tuy nhiều, nhưng không phải plugin nào cũng có thể sử dụng và thiết nghĩ chúng ta chỉ nên dùng những plugin nào có lượng download nhiều và có rating cao. Sở dĩ phải làm như thế bởi các plugin đó là an toàn, không sử dụng nhiều tài nguyên host và luôn được tác giả cập nhật các bản vá lỗi.
Hôm nay, blogviet xin phép đăng lại một bài tổng hợp của tác giả Serradinho về 35 WordPress plugin có lượng download nhiều nhất và cũng được các blogger yêu thích nhất để các bạn tiện tham khảo và biết đâu trong số các plugin này, các bạn sẽ tìm được vài cái mà mình đang cần.

  1. All in One SEO Pack – 3,296,121 Downloads
  2. Contact form 7 – 926,506 Downloads
  3. Google XML Sitemaps – 1,995,042 Downloads
  4. NextGEN Gallery – 1,163,814 Downloads
  5. SexyBookmarks – 63,366 Downloads
  6. Easy AdSense – 265,594 Downloads
  7. GD Star Rating – 252,503 Downloads
  8. Yet Another Related Posts Plugin – 258,779 Downloads
  9. WP-Cumulus – 293,879 Downloads
  10. Add to Any: Share/Bookmark/Email Button – 499,738 Downloads
  11. WPtouch iPhone Theme – 217,894 Downloads
  12. Page Flip Image Gallery – 270,389 Downloads
  13. Akismet – 1,921,123 Downloads
  14. Viper’s Video Quicktags – 381,751 Downloads
  15. Google XML Sitemaps – 11,034 Downloads
  16. Broken Link Checker – 135,412 Downloads
  17. WP Super Cache – 742,225 Downloads
  18. WordPress.com Stats – 945,382 Downloads
  19. WP-Polls – 335,328 Downloads
  20. Simple Tags – 316,006 Downloads
  21. Platinum SEO Pack – 126,019 Downloads
  22. WP-PageNavi – 381,408 Downloads
  23. WP e-Commerce – 293,683 Downloads
  24. Google Analyticator – 554,005 Downloads
  25. Sociable – 664,866 Downloads
  26. Google Analytics for WordPress – 542,263 Downloads
  27. WP Security Scan – 237,632 Downloads
  28. TweetMeme Button – 64,617 Downloads
  29. Bad Behavior – 83,465 Downloads
  30. Twitter Tools – 273,979 Downloads
  31. WP Ajax Edit Comments – 144,566 Downloads
  32. WP-DB-Backup – 344,095 Downloads
  33. WordPress Related Posts – 111,997 Downloads
  34. WP-PostRatings – 233,025 Downloads
  35. Twitter for Wordpress – 182,588 Downloads
Hy vọng danh sách các plugin trên đây sẽ giúp các WordPress fan có thêm thông tin về những công cụ cần thiết khi thiết kế và sử dụng WordPress Blog của mình.