Các lĩnh vực khác : Solution

"University of tayside" - Help ..thanks nhiều!

automail-noreply@dot.net.vn — Wed, 22 Oct 2008 15:59:01 GMT

Chào anh chị!

Anh chị có làm project "University of Tayside" (asp.net) rồi,reply bên dưới cho em biết nhé,em có vài điều trao đổi,..để yahoo cho em liên lạc hén, vì em ít time lên mạng lắm, thanks anh chị đã đọc!

Select với ký tự đặt biệt trong dotnet 2005

automail-noreply@dot.net.vn — Wed, 08 Oct 2008 17:35:55 GMT

trong đối tượng DataTable của dotnet có suport Method DataTable.Select('điều kiện Filter'), có một vấn đề là khi tôi select với chuỗi có ký tự đặt biệt ví dụ là dấu nháy đơn thì trong dotnet 2005 ko suport cho kiểu select này các cao thủ có giải pháp gì xin giúp đở cho mọi người cùng học hỏi luôn, nói thêm theo tôi được biết ,vấn đề này được giải quyết tốt trong dotnet 2008 (dùng linQ),mong nhận được góp ý của các Bác thanks.

Mỗi tuần một ý tưởng

automail-noreply@dot.net.vn — Wed, 08 Oct 2008 00:17:23 GMT

- Nơi ghi lại tất cả các ý tưởng của các bạn, dù đó là 1 ý tưởng nho nhỏ hay là 1 idea điên rồ. Có thể bạn là người nêu ra và không giải quyết được, nhưng có thể người khác sẽ giúp ích được. Trên tinh thần "knowledge is free" mình muốn có 1 chủ đề tập hợp lại các ý tưởng của cộng đồng dot.net
- Các bạn hãy thể hiện khả năng về ý tưởng của mình vào đây, cộng đồng chúng ta sẽ cùng nhau trao đổi về vấn đề này.
- Các bạn nghĩ sao khi mình tạo chủ đề này, đây cũng chính là 1 idea.
- Trên wiki cá nhân của mình thường xuyên ghi lại những ý tưởng điên rồ, hay là những ideas vô ích. Dù thế nào đi nữa thì đó cũng là IDEA.
- Là người create chủ đề, hôm nay mình pop lên 1 số ý tưởng của bản thân mình

Crawler nhận biết có nội dung mới trên forum

Khi mình quan tâm đến chủ đề nào đó trên diễn đàn. Để có thể nhận biết được có bài viết mới trong chủ đề của mình đang quan tâm, ý tưởng của mình là viết 1 con crawler nhỏ tự động phân tích chủ đề cần quan tâm trên forum đó. Khi crawler phát hiện có nội dung mới sẽ tự động gửi nội dung mới về email của mình.

Ứng dụng Hadoop, HBase xây dựng hệ thống SubVersion

Crawler lấy email từ yahoo blog

Đây là ý tưởng khá táo bạo. Trong yahoo blog ta có thể lấy tất cả các friends list từ blog yahoo của mổi cá nhân. Và từ mỗi cá nhân trong friends list đó ta lại tiếp tục lấy friends list. Như vậy là ta có được tập các yahoo blog, điều này là thực hiện được
Vấn đề khó khăn ở đây là trong mỗi blog yahoo cá nhân đó ta chỉ thấy được liên kết của cá nhân đó với đoạn ID cho nick name đó, ta không thể thấy được nick name của chủ nhân blog đó.
Ví dụ: Ta có blog http://360.yahoo.com/profile-5TEeWNUidKgSGMiFaWR5SVVc. bây giờ muốn lấy nick name hoặc email của ông này thì bó tay. Không biết dòng mã hóa 5TEeWNUidKgSGMiFaWR5SVVc có phải là ID hay không, và yahoo có hỗ trợ API cho phép lấy nick name hay email từ dòng mã hóa đó hay không

Abstract and interface

automail-noreply@dot.net.vn — Sat, 23 Aug 2008 20:40:46 GMT

Abstract:
- Single inheritance
- Fast performance
- Security problem (trong môi trường distributed application, rõ ràng ta không muốn đưa code cho clients mà nên dùng interface để cho phép clients có thể làm chuyện gì đó thôi đặng khỏi bị reverse engineer)
- Khi base class thay đổi thì class kế thừa sẽ bị ảnh hưởng theo. (Điều này vừa tốt vừa xấu, muốn biết tại sao thì xem blogs của Whidbey architects có bàn về chuyện này)

Interface:
- multiple inheritance. Chính xác hơn thì interace không phải là inheritance mà là một "contracts".
- Chậm hơn tí xíu nhưng flexible hơn abstract hoặc virtual
- Tuyệt vời khi cần tách biệt giữa những thứ mà mà 1 assembly cung cấp hoặc yêu cầu với code thực tế. (vì lý do bảo mật, vì mô hình module, vv.)
- Một điểm nữa là interface được sử dụng rất nhiều trong design patterns.

Bạn cứ áp dụng design patterns nhiều nhiều đi. Sẽ có lúc những thứ này ăn vào da vào thịt bạn đến độ khỏi suy nghĩ cũng biết nên sử dụng abstraction hay interface cho từng trường hợp

Code ví dụ:
Abstract:

Code:

             public abstract class AnimalBase
	{
		public abstract void Roar();

		public abstract int NumberOfLegs{get;set;}
	}

	public class Dog : AnimalBase
	{
		public override void Roar()
		{
			MessageBox.Show("Bark bark bark");
		}

		public override int NumberOfLegs
		{
			get { return 4; }
			set { throw new Exception("Huh? A dog with more than 4 legs?"); }
		}
	}

[b]Interface:[b]

Code:

             public interface ICanRoar
	{
		void Roar();
	}

	public interface IHasLegs
	{
		int NumberOfLegs { get;set;}
	}

	public class Cat : ICanRoar, IHasLegs
	{
		public void Roar()
		{
			MessageBox.Show("Meow");
		}

		public int NumberOfLegs
		{
			get { return 4; }
			set { throw new Exception("Sorry you meanie, I don't wanna change my little cat's DNA"); }
		}
	}

Benchmark performance of Abstract, Virtual and Interface:
Sau đây là kết quả mà mình đạt được nhờ benchmarking. (Mình dùng đỡ DateTime.Now.Ticks, tuy không chính xác như querycounter nhưng cũng chấp nhận được)

- Method calling 1 billion times - Virtual class: 3366.576 ms
- Method calling 1 billion times - Abstract class: 3382.162 ms
- Method calling 1 billion times - Interface: 966.332 ms

- Property accessing 1 billion times - Virtual class: 3397.748 ms
- Property accessing 1 billion times - Abstract class: 3460.092 ms
- Property accessing 1 billion times - Interface: 996.332 ms
(Compiled with Whidbey 2.0 beta 2, release mode, CPU: AMD 3000+, 1GB RAM)

Kết quả hoàn toàn ngược lại như mình dự đoán. Mình đoán rằng Interface sẽ chậm hơn vì phải qua boxing (nếu bạn chưa biết hiện tượng boxing/unboxing thì rất nên tìm đọc về chuyện này, major performance hit đấy). Trong khi đó, abstract và virtual không phải qua boxing, không phải qua context checking, lẽ ra phải nhanh hơn, nhưng ngược lại thì lại chậm hơn interface thấy rõ. Ngoài ra, cũng cùng 1 benchmark nếu compile trong .NET 2.0 thì nhanh hơn .NET 1.1 một tẹo.

Mình rất bất ngờ, đã cố gắng kiếm tài liệu xem như thế nào. Nhưng chưa tìm ra nên đành tạm giải thích rằng Interface cũng như type reflection là một trong những công cụ nền tảng của .NET nên đã được optimize rất kỹ. (Đúng là reflection chậm, nhưng type reflection nhanh cực kỳ đấy, .NET dùng quá nhiều type reflection mà). Hy vọng bữa nào rảnh rảnh mình sẽ xem cái emitted IL code xem .NET compiler đã optimize cho Interface như thế nào.

Đây là benchmark code, bạn cứ copy, paste để tự mình test lấy:

Code:

using System;

namespace AbstractVsInterface
{
	class Program
	{		
		static void Main(string[] args)
		{
			int tmp;
			DateTime StartTime;
			DateTime EndTime;
			TimeSpan Duration;
			int Iteration = 1000000000;

			Console.WriteLine("In same assembly, same namespace");

			#region Benchmark Method calling - virtual class
			VirtualDog vdog = new VirtualDog();
			StartTime = DateTime.Now;
			for (int i = 0; i < Iteration; i++)
			{
				vdog.Roar();
			}
			EndTime = DateTime.Now;
			Duration = new TimeSpan(EndTime.Ticks - StartTime.Ticks);
			Console.WriteLine(string.Format("Method calling ({0:#,###} times) - virtual: {1} ms", Iteration, Duration.TotalMilliseconds));
			#endregion

			#region Benchmark Method calling - abstract class
			Dog dog = new Dog();
			StartTime = DateTime.Now;
			for (int i = 0; i < Iteration; i++)
			{
				dog.Roar();
			}
			EndTime = DateTime.Now;
			Duration = new TimeSpan(EndTime.Ticks - StartTime.Ticks);
			Console.WriteLine(string.Format("Method calling ({0:#,###} times) - Abstract: {1} ms", Iteration, Duration.TotalMilliseconds));
			#endregion

			#region Benchmark method calling - interface
			Cat cat = new Cat();
			StartTime = DateTime.Now;
			for (int i = 0; i < Iteration; i++)
			{
				cat.Roar();
			}
			EndTime = DateTime.Now;
			Duration = new TimeSpan(EndTime.Ticks - StartTime.Ticks);
			Console.WriteLine(string.Format("Method calling ({0:#,###} times) - Interface: {1} ms", Iteration, Duration.TotalMilliseconds));
			#endregion

			Console.WriteLine();
			
			#region Benchmark Property accessing - virtual
			StartTime = DateTime.Now;
			for (int i = 0; i < Iteration; i++)
			{
				tmp = vdog.NumberOfLegs;
			}
			EndTime = DateTime.Now;
			Duration = new TimeSpan(EndTime.Ticks - StartTime.Ticks);
			Console.WriteLine(string.Format("Property accessing ({0:#,###} times) - Virtual: {1} ms", Iteration, Duration.TotalMilliseconds));
			#endregion
		
			#region Benchmark Property accessing - abstract
			StartTime = DateTime.Now;
			for (int i = 0; i < Iteration; i++)
			{
				tmp = dog.NumberOfLegs;
			}
			EndTime = DateTime.Now;
			Duration = new TimeSpan(EndTime.Ticks - StartTime.Ticks);
			Console.WriteLine(string.Format("Property accessing ({0:#,###} times) - Abstract: {1} ms", Iteration, Duration.TotalMilliseconds));
			#endregion

			#region Benchmark Property accessing - interface
			StartTime = DateTime.Now;
			for (int i = 0; i < Iteration; i++)
			{
				tmp = cat.NumberOfLegs;
			}
			EndTime = DateTime.Now;
			Duration = new TimeSpan(EndTime.Ticks - StartTime.Ticks);
			Console.WriteLine(string.Format("Property accessing ({0:#,###} times) - Interface: {1} ms", Iteration, Duration.TotalMilliseconds));
			#endregion

			Console.ReadLine();
		}

		#region Virtual class
		public class VirtualAnimalBase
		{
			public virtual void Roar() { }

			public virtual int NumberOfLegs 
			{
				get { return 4; }
				set { }
			}
		}

		public class VirtualDog : VirtualAnimalBase
		{
			public override void Roar()
			{
			}

			public override int NumberOfLegs
			{
				get { return 4; }
				set { throw new Exception("Huh? A dog with more than 4 legs?"); }
			}
		}
		#endregion

		#region Abstract class
		public abstract class AnimalBase
		{
			public abstract void Roar();

			public abstract int NumberOfLegs { get;set;}
		}

		public class Dog : AnimalBase
		{
			public override void Roar()
			{
			}

			public override int NumberOfLegs
			{
				get { return 4; }
				set { throw new Exception("Huh? A dog with more than 4 legs?"); }
			}
		}
		#endregion

		#region Interface
		public interface ICanRoar
		{
			void Roar();
		}

		public interface IHasLegs
		{
			int NumberOfLegs { get;set;}
		}

		public class Cat : ICanRoar, IHasLegs
		{
			public void Roar()
			{
			}

			public int NumberOfLegs
			{
				get { return 4; }
				set { throw new Exception("Sorry you meanie, I don't wanna change my little cat's DNA"); }
			}
		}
		#endregion
	}
}

@Bazen:
Ý của mình là trong môi trường distributed application (web, client-server, vv) thì nên có interface riêng. Client và Server chỉ nói chuyện qua interface, còn Server sẽ giữ implementation code riêng không cho phép client được rờ mó gì vô ráo trọi. Mô hình này bạn sẽ gặp rất nhiều trong service-oriented-programming. Đại khái là càng đưa ít code cho clients càng tốt. Với lại clients đâu có cần biết nhiều, chỉ cần biết nó dùng "service" gì để thực hiện 1 công việc, thế là đủ. Interface chính xác là 1 contract, giữa người mua và kẻ bán chỉ "tiền trao cháo múc", người nhận tiền, kẻ nhận hàng, không cần quan tâm đến chuyện gì khác.

Ngoài ra, interface được dùng nhiều để lập trình theo mô hình module (plug-in, snap-in, vv). Tức là phần host không quan tâm tới chuyện cái plug-in của mình tròn méo ra làm sao, miễn là plug-in đó thỏa điều kiện IPlugin nào đó. Một ví dụ khác là bản thân .NET đấy, bạn viết ngôn ngữ C#, J#, VB.NET chi chi cũng được. Bản thân .NET FX đâu thèm quan tâm, miễn là code của bạn thỏa ICompiler để biên dịch ra ngôn ngữ chung IL là chạy được tất.

Cỏn abstraction dùng để cung cấp features cho những lớp kế thừa. Lấy ví dụ hôm nay tui định nghĩa con vật gồm 4 chân, biết kêu. Mai mốt tui định nghĩa thêm con vật có răng, biết cắn thì tất cả các con vật kế thừa (chó, gà, heo, vịt, ...) đều ngay lập tức được thừa hưởng đặc tính mới này.

@Contrarin:
Performance of Java versus C#:
kẻ tám lạng, người nửa cân. Bạn cứ việc tìm trên mạng sẽ tha hồ thấy nhiều benchmark, scientific study, commercial research về so sánh giữa Java và C# (hay .NET). Nói ngắn gọn lại thì tùy mỗi lúc mỗi khác à. Có cái thì Java nhanh, viết code ít. Có cái thì C# hay hơn.

Bữa hổm mình đọc 1 bài viết ca ngợi Java, nói C# chạy chậm rùa bò, chậm hơn đến 20-30 lần làm mình tức quá, chép cái code của hắn về chạy lại. Kết quả: y chang nhau :-) (có lẽ hắn xài .NET 1.0, còn mình dùng 2.0.5)

Có người nói Java chạy chậm trong win, chạy nhanh trong embedded, còn .NET thì ngược lại. Vân vân và vân vân.

Theo mình thì .NET mới ra đời, còn Java ra lâu rồi. Mấy cái benchmark đó đều là benchmark giữa 1 chàng thanh niên và 1 cậu bé, làm sao mà so sánh đây? Nói .NET chậm ư? Thế thì đừng dùng .NET 1.1 nữa mà nhảy lên whidbey nhé, xem coi có còn chậm nữa không? Nhanh rùng rợn đấy, chả kém java đâu. Đó là còn chưa kể đến 3rd-party optimization nữa (cho value type, cho generics), họ còn tuyên bố làm cho whidbey chạy nhanh hơn vài lần nữa kìa.

Nói tóm lại thì chuyện performance chỉ là marketing-hype. Quan trọng là optimization ra làm sao. Nếu .NET hoặc Java có chỗ nào đó chưa nhanh thì chính bạn phải optimize lấy, nếu không thì đợi phiên bản kế tiếp.

Về chuyện

Quote:

Em nghĩ C# chính là Java-on-.NET nên những issue của .NET có thể áp dụng trên Java được

thì mình chưa rõ ý của bạn lắm.
Java-on-.NET thì đã có J#

"issue của .NET"? Issues nào vậy bạn? Mình chỉ thấy là C# nói riêng và .NET nói chung = C + Delphi + Java + 20% innovation.
Nếu bạn nói về tốc độ và architecture thì bạn hãy đợi Whidbey + Avalon + Indigo. Hai cái Longhorn pillars đó cũng dễ sợ đấy, mấy thứ đó được design ngay từ đầu để đối mặt với Java, hay chính xác hơn là những hạn chế trong software development nói chung. Như có lần mình đã nói, mình chẳng tâng bốc Microsoft đâu, nhưng mình phải chấp nhận là Microsoft có rất nhiều tiền, đủ để mua architects về để cạnh tranh mà. Mình thấy rất thú vị khi ngay bản thân những technology mới của Microsoft rất... quen thuộc. Từ cả tên cho tới architecture design. Mới thì có mới nhưng vẫn cứ là thiên hạ có gì hay thì chôm lại, phát triển thêm rồi gắn mác MS$. Nhưng có gì lạ đâu, ai chả thế

1. Bạn đã thực hiện bao nhiêu lần thí nghiệm này??? Nếu bạn mới chỉ thí nghiệm một lần thì cần thí nghiệm nhiều lần nữa mới có thể kết luận được. Vì môi trường chúng ta đang dùng là môi trường đa nhiệm, không thể kết luận chắc chắn là trong lúc bạn đang bấm giờ lại không có một "Process" của Window đang tranh giành CPU. Ví dụ lúc bạn chạy Interfacing thì CPU đang rỗi, nhưng lúc bạn chạy Abstraction thì CPU có nhu cầu xử lý một process khác.

2. Trước đây mình nghĩ là Interfacing chỉ có ý nghĩa về mặt thiết kế và lập trình, còn Khi đã dịch thì phương thức có trong lớp (được chỉ ra trong Interfacing) cũng giống như mọi phương thức khác. Vì vậy cũng không có căn cứ để kết luận cái nào chạy nhanh hơn: abstraction hay interfacing.

3. Ý kiến thứ 2 của mình là suy nghĩ khi thực hiện trên một máy đơn, còn trong ứng dụng phân tán thì không biết.

@mt333:
1/ Vâng thưa bạn mình biết một tí về GC và Multi-threading cho nên trước khi benchmark đã chọn release mode (best optimized), tắt hết các chương trình khác (most RAM available), chọn số lần iteration là 1 tỉ iteration cho mỗi benchmark, không sử dụng Thread.Sleep, không sử dụng Timers, thậm chí không có bất kỳ processing code nào hết (=> GC và memory management là irrelevant hoặc insignificant).
Tất nhiên, quan trọng nhất là mình phải test đi test lại để xem kết quả có đồng nhất không. Thậm chí mình còn đi xa hơn một bước là test cùng 1 code cho 2 máy tính khác nhau: 1 AMD, 1 Intel platform.
Kết quả benchmark tuy gây ngạc nhiên nhưng mình cảm thấy vẫn hợp lệ.

2/ Về lý thuyết thì interface và abstraction đều như nhau (tất cả chỉ là method pointer, thậm chí giống luôn cả direct method call). Sự khác nhau nảy sinh trong .NET là context bound, boxing/unboxing, và code access security. Do đó sẽ dẫn đến optimization khác nhau.
Nếu bạn nghi ngờ, hãy chạy test trên dưới chế độ debug mode bạn sẽ thấy kết quả y như nhau, không có cái nảo nhanh hơn cái nào.

@Bazen:

Quote:

Được gửi bởi bazen

Anh bienca101 đo tốc độ như thế nào vậy, anh chỉ em cách đo được ko? Dùng hàm hay tools vậy anh ?

Bazen ạ, đo tốc độ thì có khá nhiều cách:
1/Profiler: dùng 3rd-party profiler hoặc System.Diagnostic sẽ có ích trong việc tweak performance của toàn bộ chương trình.

2/Đối với benchmarking, làm như thế không ổn mà cần phải cặp "que dò" ngay tại chỗ phát sinh code gần nhất. Càng gần processing code càng tốt. Trong .NET không có timer chính xác sẵn cho bạn. Hoặc bạn dùng cách đo bằng TimeSpan như trong code ví dụ của mình đấy:
TimeSpan ts = new TimeSpan(EndTime.Ticks - StartTime.Ticks);

Cách trên lợi dụng tính chất của type DateTime là thực chất nó chỉ là longint không hơn không kém (mỗi giá trị là 1 "tick"). Một tick này hoàn toàn chả ăn nhập gì với core CPU "tick" cả, do đó nó kém chính xác là ở chỗ đó. (nhưng vẫn còn ăn đứt cái Timer)

Cách chính xác hơn là phải dùng đến WinAPI, gồm 2 hàm QueryPerformanceCounter và QueryPerformanceFrequency. Hai hàm này cung cấp thời gian theo xung nhịp của CPU nên độ chính xác rất cao. Thường là best-choice-timer cho game.

Nếu bạn muốn chính xác tuyệt đối thì bạn phải mua 1 mạch đồng hồ nguyên tử. Mình chỉ nghe kể là máy tính quân sự thì có cái này thôi chớ cũng chưa được rớ tới bao giờ

theo mình biết 1 "ticks" mà bạn nói đúng là chả liên quan đến CPU, mà là phụ thuộc vào OS (Hệ điều hành). Một "tick" của WinXP không nhớ rõ là bao nhiêu hình như >= 7ms hay 5ms. Vì thế, nếu ai dùng Thread.Sleep(x) (x<7) thì sẽ chả có tác dụng.

Không phải là không có đâu. Có tác dụng đấy nhưng do ngắn ngủi quá nên bạn không cảm nhận thấy đó thôi.

Để minh chứng, bạn chạy thử cái test này đi. Mình cho lặp đi lặp lại 10.000 lần Thread.Sleep(1).
Expected time = 10.000 x 1ms = 10.000ms
Actual elapsed time = 19.654ms

Khác biệt thấy rõ đấy. Điều này chẳng có gì lạ bởi vì overhead cho cái ThreadPool trong .NET tốn kém quá mà.

Code:

int Iteration = 10000;
			Console.WriteLine("Start - Please wait about 10 seconds");
			DateTime StartTime;
			DateTime EndTime;
			TimeSpan elapsed = new TimeSpan();
			for (int i = 0; i < Iteration; i++)
			{
				StartTime = DateTime.Now;
				System.Threading.Thread.Sleep(1);
				EndTime = DateTime.Now;
				elapsed += new TimeSpan(EndTime.Ticks - StartTime.Ticks);
			}
			Console.WriteLine("Stop");

			Console.WriteLine(string.Format("Elapsed time: {0:#,###}ms - Expected: {1:#,###}ms", elapsed.TotalMilliseconds, Iteration));
			Console.ReadLine();

1/Abstract:
Abstract là 1 công cụ cơ bản của lập trình hướng đối tượng. Nó bổ sung cho chức năng inheritance (kế thừa). Lớp kế thừa được thừa hưởng những đặc tính và chức năng của lớp cha. Khi những đặc tính và chức năng đó của cha chưa được biết trước thì người ta dùng abstraction.

Ví dụ:
- Định nghĩa con vật thì phải có chân, số chân bi nhiêu thì chưa biết trước.
- Con mèo kế thừa từ con vật, vậy con mèo cũng có chân.
- Con vịt cũng là con vật, con vịt có chân.

Code:

public class Animal
	{
		public bool HasLegs
		{ get { return true; } }
	}

	public class Cat: Animal
	{
	}

	public class Duck : Animal
	{
	}

Nhờ kế thừa nên cả Duck lẫn Cat không cần viết dòng code nào vẫn nghiễm nhiên được thừa hưởng thuộc tính HasLegs. Tuy nhiên, con vịt có 2 chân, con mèo có bốn chân. Vậy làm sao mình đếm được số chân của 1 con vật bất kỳ nào đó? Mình sẽ dùng abstraction để sửa lại như sau:

Code:

public class Animal
	{
		public bool HasLegs
		{ get { return true; } }

		public abstract int NumberOfLegs
		{ get;}
	}

	public class Cat: Animal
	{
		public override int NumberOfLegs
		{
			get { return 4; }
		}
	}

	public class Duck : Animal
	{
		public override int NumberOfLegs
		{
			get { return 2; }
		}
	}

Thật tiện lợi, phải không? Nhờ có abstract nên ngay từ lớp cha (Animal) đã có thể định nghĩa được thuộc tính NumberOfLegs mà không biết trước sẽ có bao nhiêu chân cả. Lớp kế thừa (Duck, Cat) sẽ có nhiệm vụ trả lời chuyện này.

2/Interface:

Interface thực ra chính là abstraction nhưng cao cấp hơn abstract đơn thuần như đã nói ở trên. Interface uyển chuyển hơn abstract rất nhiều do đó nó gần như là lựa chọn số một khi bạn cần thiết kế mô hình có cấu trúc mở.

Ví dụ: mình biết con mèo, con vịt có thuộc tính trọng lượng. Mình lại có những vật khác cũng lại có trọng lượng như cái bàn, cái ghế. Rõ ràng 2 nhóm đối tượng này tuy chung thuộc tính nhưng không kế thừa được, cũng không abstract được vì chúng thuộc 2 nhóm khác nhau xa lắc xa lơ. (không lẽ cái bàn lại kế thừa từ con vật?)

Do đó, thay vì dùng abstract, mình dùng interface. Ví dụ trên chính là đặc tính multiple-inheritance. (hay nói cho sang hơn, là poly-morphism)

Nhưng chức năng đặc sắc nhất của interface lại là ở chỗ "required contract". Ví dụ như Photoshop ấy. Hãng Adobe khi cho ra lò Photoshop thì dành riêng 1 số plug-ins interface để mọi người có thể viết filters cho Photoshop. Bản thân Adobe không hề biết trước khách hàng của mình sẽ cần những gì. Nhờ có plug-ins, những lập trình viên khác, nắm bắt được yêu cầu khách hàng tốt hơn, sẽ viết filters thêm cho Photoshop. Họ cứ việc dựa vào interface sẵn có của Photoshop để viết. Nếu không nhờ interface thì chuyện này sẽ không thể nào xảy ra, muốn có tính năng mới thì bắt buộc phải viết Photoshop lại, bắt buộc phải compile lại.

BẠn hãy thử với Thread.Sleep(5) thấy kết quả nó sẽ tưng tự Thread.Sleep(1).

Bạn hãy xem kỹ về ThreadPool sẽ thấy là cái ThreadPool của .NET tự động có khoảng chờ nho nhỏ trước khi thực hiện 1 WorkItem. Do đó nên Thread.Sleep(5) sẽ tương tự như Thread.Sleep(1) là hoàn toàn hợp lý.

Nhiều khi bạn sleep 5 hay 1 gì như nhau là do nhiều thứ. Bạn đang chạy trên windows. Bạn có bảo đảm trong 1 thời gian chỉ có mỗi thread của bạn chạy ko ?
Tốt nhất, nếu muốn thử thì thử 2 thread cùng start nó mới chính xác dc.

Mình chưa được rõ ý của bạn lắm Contrarin à.

abstract = must override
virtual = overridable

Do đó, trong C# nếu đã là abstract thì bắt buộc phải là virtual nốt. Làm sao lại có non-virtual abstract (not-overridable but must override) được?

Nếu ý bạn muốn nói non-virtual là direct method call thì tất nhiên là nhanh rồi, khỏi cần thử.

Quote:

Được gửi bởi nowforever

Nhiều khi bạn sleep 5 hay 1 gì như nhau là do nhiều thứ. Bạn đang chạy trên windows. Bạn có bảo đảm trong 1 thời gian chỉ có mỗi thread của bạn chạy ko ?
Tốt nhất, nếu muốn thử thì thử 2 thread cùng start nó mới chính xác dc.

@Nowforever:

Theo mình biết thì không nên benchmark bằng threads. Lý do rất đơn giản là mỗi thread sẽ được cấp timeslice hoàn toàn khác nhau. Dù cùng priority đi chăng nữa thì threads vẫn không được cấp ngang nhau. Có lúc 1, có lúc 2,3 rồi mới đến thread khác. Đó là còn chưa kể đến chuyện cái ThreadPool có cơ chế tự động đợi trước khi thực hiện 1 workitem cho nên chuyện benchmark bằng cách cho nhiều threads chạy song song là hết sức khó thực hiện cho chính xác.

Bản thân interface không phải là multiple-inheritance lẫn poly-morphism nhưng có phần nào mang tính chất đó

nơi đóng góp và chia sẽ giải pháp cho nhau

automail-noreply@dot.net.vn — Wed, 13 Aug 2008 17:49:13 GMT

trong một ứng dụng web SMS khi đồng thời lượng Connect đến Server tăng đột biến thì giải pháp đưa ra ở đây như thế nào(ứng dụng sử dụng sql Server2k5) nào chúng ta cùng nhau đóng góp cho 4room thêm sôi động đi các cao thủ

xay dung dong co thu thap tu dong bao dien tu

automail-noreply@dot.net.vn — Sat, 14 Jun 2008 21:45:11 GMT

Co ai biet cach tim kiem ngu nghia trong mot trang web khong chi cho minh di

Tại sao template nước ngoài lại đẹp không rườm rà như Việt Nam

automail-noreply@dot.net.vn — Tue, 13 May 2008 22:21:37 GMT

Những từ viết tắt sử dụng trong bài viết:
Web nước ngoài: Những trang Web phối hợp hài hoà yếu tố thẩm mỹ và tính tiện dụng
Web Việt Nam: Những trang Web Việt Nam nói chung không đáp ứng việc phối hợp hài hoà

Trước khi phân tích Web nước ngoài và Web Việt Nam, mời các bác dạo với em một vòng để tìm hiểu về trục thiết kế trong thiết kế Web trước đã nhé.

Mục đích của thiết kế giao diện Web là định hướng giao tiếp. Có thể hiểu giàu tính thẩm mỹ là một chức năng của cái đẹp, của sự cuốn hút, của cảm xúc sâu và sự ảnh hưởng thị giác.

Sự phong phú của chức năng có thể hiểu là tính tiện ích, là tổng hợp của dễ sử dụng và tính ứng dụng của các chức năng.

I. Thiết kế Web là thiết kế sản phẩm trên trục thẩm mỹ và chức năng

Hình minh hoạ 1: Trục thiết kế

Vùng màu vàng là phạm vi mà một sản phẩm có thể hoạt động. Tất cả các sản phẩm đều nằm đâu đó bên trong các đường biên của hình cầu. Mô hình thể hiện các khía cạnh quan trọng của thiết kế và hướng giải quyết vấn đề trong sự ràng buộc của sáng tạo.

Mô hình này chỉ ứng dụng khi đối tượng là sản phẩm thị giác và có yếu tố truyền thông; không áp dụng cho mỹ thuật công nghiệp hoặc máy móc.

Sản phẩm có yêu cầu hiệu ứng thị giác cao và đẹp sẽ có vị trí cao nhất trên trục Giàu tính thẩm mỹ. Càng đề cao vẻ đẹp và chất lượng thẩm mỹ thì càng giảm hiệu năng sử dụng. Một thiết kế không đẹp, rườm rà có vị trí thấp trong trục này.

Một thiết kế sản phẩm đem lại tính tiện dụng cao sẽ có trị trí cao nhất trong trục Phong phú chức năng. Phong phú chức năng là tổng hợp của:

Thông tin trong truyền thông thị giác dễ hiểu và rõ ràng
Cung cấp nhiều cách nhập thông tin hiệu quả
Cung cấp nhiều công cụ giúp dễ dàng thực hiện các chức năng phức tạp

Một sản phẩm đẹp, phong phú các chức năng và dễ sử dụng nó nằm ở đâu đó điểm (3)
Một sản phẩm xấu xí và sử dụng khó khăn nằm gần gốc toạ độ
Một sản phẩm sử dụng được nhưng có giao diện xấu thì nằm ở điểm (1) và ngược lại thì nó nằm tại điểm (6)

II. Trục thiết kế có ý nghĩa gì?

Đây là mối giao hoà tự nhiên giữa sự phong phú chức năng và giàu tính thẩm mỹ. Bạn không thể vừa có một sản phẩm có trình ứng dụng chức năng cao cấp và giao diện thiết kế tuyệt vời. Nếu có thì sản phẩm này nằm ngoài hình cầu của thiết kế. Lý do là nếu sản phẩm có tính thẩm mỹ cao và cuốn hút nhất thì bạn sẽ dừng làm việc và ngắm nhìn chúng; trong khi những sản phẩm có chức năng hiệu quả nhất thì giúp bạn thực hiện tốt công việc của bạn mà không phải lưu tâm việc ngắm nghía chúng. Không thể xảy ra cả hai.
Giao diện thiết kế là một cuộc đối thoại hai chiều giữa ý đồ thiết kế và người dùng. Ý đồ thiết kế giao tiếp và người truy nhập tương tác lẫn nhau thông qua ngôn ngữ của thiết kế, ở đây là tính thẩm mỹ và chức năng.
a. Hầu hết những Web site có chức năng tốt đều phong phú thông tin, tải nhanh và sử dụng thuận tiện. Chúng tập trung vào chức năng nhưng nếu muốn cuốn hút, ấn tượng người dùng thì hiệu suất sử dụng lại phải thoả hiệp.
b. Những thiết kế đẹp nhất - luôn khiến bạn dừng lại và ngắm nhìn, chúng giàu tính biểu đạt. Nếu muốn có tính hữu dụng cao, họ không thể tăng tỉ trọng các chức năng cao cấp vào.
Những giao diện thiết kế có tính ứng dụng cao đều cần thẩm mỹ cao. Những thiết kế tiện dụng, hay sử dụng ( chẳng hạn các hướng dẫn lắp đặt đồ gia dụng, chỉ dẫn kỹ thuật, biểu mẫu và báo cáo) đem lại hiệu quả cao nhất khi chúng phối hợp các yếu tố thẩm mỹ như tính cân bằng, màu sắc và độ tương phản.
Những giao diện có tính thẩm mỹ cao cũng cần hoà trộn với tính tiện dụng. Nếu sản phẩm không có khả năng sử dụng, nó chỉ đơn thuần là nghệ thuật không phải thiết kế. Xa hơn một Web site, những sản phẩm đẹp nhất sẽ chỉ thu hút sự chú ý của con người khi nó có thể sử dụng.
Vị trí lý tưởng cho một sản phẩm nằm ở đường biên giữa vị trí (3) (chỉ toàn chức năng) và (chỉ có vẻ đẹp). Một sản phẩm trí tuệ là sự phối hợp của việc ngắm và làm việc.
Có thể gọi đây là một tiêu chuẩn mới dựa trên sự cân bằng của tính thẩm mỹ và chất lượng chức năng. Điều cơ bản và cũng quan trọng nhất của một thiết kế viên là luôn có ý đồ rõ ràng khi thiết kế sản phẩm và sản phẩm thiết kế phải nằm trên phạm vi này.

Một site mà mục đích chính là phục vụ công việc người dùng và có nhiều chức năng chẳng hạn thuế, kế toán, tài chính ngân hàng nên nằm phía Bắc của giao điểm.
Một site phục vụ các mục đích như quảng bá thương hiệu, giải trí, cuộc sống nên nằm phía Đông của giao điểm.

Khi thiết kế các sản phẩm có chức năng truyền thông, thiết kế tiện dụng là đơn giản và cũng là tốt nhất. Tính tiện dụng là yếu tố chính để thiết kế thành công.

Hầu hết các thiết kế viên đều nghĩ sự đối nghịch của thiết kế và tính tiện dụng cũng là sự đối nghịch của nghệ thuật đồ hoạ và thiết kế; và đa số các cuộc tranh luận đều xoay quanh hai điểm quan trọng của tính thẩm mỹ và chức năng (nhìn thay vì làm việc). Thiết kế giao diện Web là nguyên tắc ứng dụng các kỹ thuật đồ hoạ, Web để giải quyết vấn đề truyền thông; trong khi Nghệ thuật đồ hoạ là sử dụng các kỹ năng tương tự dùng cho lợi ích của họ. Nghệ thuật có chỗ đứng của nó và là một phần quan trọng của Web site tuy nhiên thành công của Web site được đem lại hoàn toàn từ Thiết kế. Thiết kế là tìm kiếm những giải pháp tốt nhất để giải quyết các vấn đề truyền thông.

Web nên bao gồm cả sự cuốn hút thị giác và tính dễ sử dụng. Hai yếu tố này không loại trừ lẫn nhau. Trong một số trường hợp thiết kế thành công dựa trên sự cuốn hút thị giác. Hiệu ứng cuốn hút và đẹp có thể khiến người sử dụng dừng chân trên Web lâu hơn hoặc khám phá sâu hơn, làm tăng trải nghiệm cụ thể và tạo sự cuốn hút một sản phẩm để bán hàng.

Tuy nhiên vấn đề thường phát sinh khi nghệ thuật đồ hoạ được sử dụng thay thế cho thiết kế. Khi nghệ thuật đồ hoạ được ứng dụng để đạt các mục tiêu của Web, hậu quả kinh tế thường khá nghiêm trọng. Thông thường nguyên nhân của thiết kế không truyền thông hiệu quả là do tính thẩm mỹ không đạt. Những điều xảy ra trong lĩnh vực web cũng đang xảy ra trong các lĩnh vực truyền thông khác nhưng trong khoảng thời gian nhanh hơn.

Luôn xảy ra áp lực sáng tạo giữa cách thiết kế mang tính thẩm mỹ và trách nhiệm để sản xuất ra một sản phẩm phục vụ cho công việc. Và đây là vấn đề chính của thiết kế Web.

Cùng với năng lực nhận thức, năng lực ứng dụng chưa cao, nhiều Web Việt Nam mới chỉ dừng lại ở nghệ thuật đồ hoạ hoặc công cụ. Điều này khiến cho Web Việt Nam trở nên hoặc rườm rà, không khoa học hoặc khó sử dụng. Nhiều Web Việt Nam nằm tại gốc toạ độ của trục Thẩm mỹ - Chức năng. (Xem hình minh hoạ 2)
Chú ý rằng bạn đang giao tiếp không phải thiết kế. Tất cả các yếu tố đơn lẻ và quyết định phải giúp người sử dụng đạt được mục đích của họ và mục đích của site.

Một vài ví dụ tại Việt Nam. Đây là các đánh giá độc lập của iGURU.

Hình minh hoạ 2: Sắp xếp các Site trên trục thiết kế

Các Website được đánh giá:

1.www.mozilla.org
2.http://vi.wikipedia.org
3.www.baamboo.com
4.www.vietnamworks.com
5.www.iguru.vn
6.www.google.com.vn
7.http://www.yahoo.com.vn
8.www.cyworld.vn
9.www.vietnamnet.vn
10.www.templatesmonster.com
11.www.24h.com.vn
12.www.firewheel.com
13.www.designchapel.com
14.www.chodientu.vn
15.www.clip.vn
16.www.vietspace.net.vn
17.www.tamtay.vn
18.www.cinet.gov.vn

Câu hỏi mở rộng:

Theo bạn, các Site Việt Nam nên đi theo hướng nào trong Thiết kế Web?
Vị trí biên nào phù hợp với site của bạn? Bạn cần yêu tố nào hơn: chức năng hay tính thẩm mỹ? Và tại sao?

Tải phiên bản PDF: http://files.myopera.com/iguru/blog/TrucThietKeTrongThietKeWeb2008.10.04.pdf
Traceback: http://my.opera.com/iguru/blog/web-template-iguru-ban-su-dung-trai-phep-nuoc-ngoai

định hướng lập trình game chơi qua Lan

automail-noreply@dot.net.vn — Tue, 06 May 2008 00:07:19 GMT

mình có đồ án làm game chơi qua mang mạng lan nhưng mình kô điịnh hướung được phải làm những công vịêc j,
nên xây dựng theo hướng nào, phải lập trình theo kiểu TCP/Ip hay UDP ???
nói chung mình mới đọc tài liệu mà ko hiểu lắm. mong các bạn đưa ra cách giải quyết vấn đề này giùm mình
cám ơn các bạn

Optimize

automail-noreply@dot.net.vn — Fri, 25 Apr 2008 09:29:25 GMT

Tui đọc dc cái này, thấy hay, post lên cho mọi người cùng xem

Viết lại đoạn code sau để chạy nhanh hơn : )

Lang: C#

Code:

int CountBit (bool[] bits)
{
   int total = 0;

   for (int i = 0; i < bits.Length; i++)
   {
     if (bits[i])
     {
        total++;
     }
   }

   return total;
}

Đây là kết quả benchmark tui thử nghiệm (bits chứa 1024 items, mỗi phương pháp test 10.000 iterations):

Original : 20,62 ms - CPU cycles per count: 4,31
CountBit2 : 17,67 ms - CPU cycles per count: 3,69 - Improvement: 16,70%
Unsafe : 15,44 ms - CPU cycles per count: 3,22 - Improvement: 33,56%
Ints : 13,19 ms - CPU cycles per count: 2,75 - Improvement: 56,39%

Lưu ý là benchmark chạy trên Xeon QuadCore CPU, với cpu ko phải Xeon hay Itanium thì kết quả có lẽ khác hẳn.

Còn đây là code:

CountBit2: đưa biến total ra ngoài. Cách optimize này tùy trường hợp cụ thể mà có thể nhanh hơn, có thể chậm hơn.

Code:

        int total = 0;
        int CountBit2(bool[] bits)
        {
            total = 0;

            for (int i = 0; i < bits.Length; i++)
            {
                if (bits[i])
                {
                    total++;
                }
            }

            return total;
        }

Unsafe: Array là primitive structure có overhead cao nhất do có range checking, dùng unsafe pointer để tránh chuyện này.

Code:

        unsafe int UnsafeCount(bool[] bits)
        {
            int total = 0;
            int len = bits.Length;

            fixed (bool* t = &bits[0])
            {
                bool* b = t;

                for (int i = 0; i < bits.Length; i++)
                {
                    if (*b == true) total++;
                    b++;
                }
            }

            return total;
        }

Ints: thay vì dùng mảng bool[] thì dùng ints[]. Thường thì optimization phụ thuộc rất nhiều vào cấu trúc dữ liệu. Trong trường hợp này, thay vì lưu boolean thì lưu 0, 1 với int. (Chủ yếu để khỏi phải có code branching ở đoạn if )

Code:

        int CountInt(int[] bits)
        {
            int total = 0;

            for (int i = 0; i < bits.Length; i++)
            {
                total += bits[i];
            }

            return total;
        }

Cái Ints không hợp lệ rồi, không sửa input.

Test bé quá, có 1024 items, đề nghị test với 32 * 1024 * 1024 items trở lên.

Còn vài hướng optimize nữa mà ;; )

FasterCount1: bool của .NET thực tế là byte với giá trị 0, 1. Kết hợp với unsafe code loại bỏ range check, branch miss.

Code:

        static unsafe int FasterCount1 (bool[] bits)
        {
            int total = 0;

            fixed (bool * boolPtr = bits)
            {
                byte* bytePtr = (byte*) boolPtr;

                for (int i = 0; i < bits.Length; i++)
                {
                    total += *bytePtr;
                    bytePtr++;
                }
            }

            return total;
        }

Test với 32 * 1024 * 1024 items

Code:

            for (int i = 0; i < bits.Length; i++)
            {
                bits [i] = i % 2 == 0;
            }

Data này là worst-case của OrginalCount (CPU không đoán đúng được if rẽ đi đâu)

FasterCount1 = 7.18x OrginalCount trong trường hợp này.

Với test 10,000 iteration 1024 items.

50% true: FasterCount1: 8.5ms, UnsafeCount: 30.9ms --> 3.63x
10% true: FasterCount1: 8.5ms, UnsafeCount: 15.8ms --> 1.85x

FasterCount2 Tương tự như FasterCount1 nhưng thay vì xử lí từng byte thì xử lí theo từng block 4 byte (32 bit).

Code:

        static unsafe int FasterCount2(bool[] bits)
        {
            int total = 0;            
            int len = bits.Length/4;

            fixed (bool* boolPtr = bits)
            {
                int* intPtr = (int*)boolPtr;                

                for (int i = 0; i < len; i++)
                {
                    int x = * intPtr;

                    total += (x & 1) + ((x & 256) >> 8) + ((x & 65536) >> 16) + ((x & 16777216) >> 24);

                    intPtr++;
                }
            }

            return total;
        }

FasterCount2 nhanh hơn FasterCount1 ~19% (1.19x)

Chài, đã lén lén đưa unsafe vào tính ăn gian rồi, ai dè Zero còn ăn gian đậm nữa, unsafe type casting luôn. Chưa nói tới chuyện người ta dùng int[] thì kêu phạm quy, còn gian lận cast bool sang int thì lại được.

Thôi, buồn ngủ nữa rồi, kệ. Để ăn no ngủ kỹ, đợi các hảo hán khác lên tỉ thí với Zero trước đã.

T/B: Zero này, FasterCount2 cũng là dạng thường gặp. Nhưng ko biết sang 64bit CPU + 64bit OS, nếu mình dùng cách này (tăng thêm 4 op nữa thành 8 op) có nhanh hơn ko nhỉ? Về mặt lý thuyết thì có, nhưng tui chưa có thử. (Lười quá, tối qua cũng có nghĩ tới cách gôm 4 op vô 1 iteration như FasterCount2 nhưng buồn ngủ quá nên thui)

Sẵn cũng hỏi nốt, tối qua tui cũng nghĩ tới chuyện với single-core CPU thì đương nhiên mình optimize thế là nhanh. Nhưng nếu có multi-core và lots of data, mình dùng threading thì performance có cao hơn ko nhỉ? (Dạ, cũng lại là lười nốt, chưa thử, nên sẵn Zero đã đố thì biết đâu đã test rồi, nên hỏi cho nhanh)

Quote:

Được gửi bởi bienca101

Chài, đã lén lén đưa unsafe vào tính ăn gian rồi, ai dè Zero còn ăn gian đậm nữa, unsafe type casting luôn. Chưa nói tới chuyện người ta dùng int[] thì kêu phạm quy, còn gian lận cast bool sang int thì lại được.

Input không có bị sửa

Quote:

Được gửi bởi bienca101

T/B: Zero này, FasterCount2 cũng là dạng thường gặp. Nhưng ko biết sang 64bit CPU + 64bit OS, nếu mình dùng cách này (tăng thêm 4 op nữa thành 8 op) có nhanh hơn ko nhỉ? Về mặt lý thuyết thì có, nhưng tui chưa có thử. (Lười quá, tối qua cũng có nghĩ tới cách gôm 4 op vô 1 iteration như FasterCount2 nhưng buồn ngủ quá nên thui)

Em nghĩ là khó mà nhanh hơn được do các tính toán dạng này khá đơn giản, chỉ 2-3 cycles/op. Bottle-neck sẽ là memory-access, 64 bit cũng không giúp được. (L2, L3 lớn là chuyện khác )

Thường khi optimize mọi người chỉ chú ý đến calculation chứ ít khi optimize memory access - L2 cache miss có thể cost 100-150 CPU cycles.

Quote:

Được gửi bởi bienca101

Sẵn cũng hỏi nốt, tối qua tui cũng nghĩ tới chuyện với single-core CPU thì đương nhiên mình optimize thế là nhanh. Nhưng nếu có multi-core và lots of data, mình dùng threading thì performance có cao hơn ko nhỉ?

Multi-core: compiler tối ưu khá tốt cho cái này, nhất là mấy cái loop, anh để ý Task Manager sẽ thấy là CPU bị đẩy lên 50-75% (Quad-core) trong khi đúng ra max chỉ là 25% (single-thread).

Còn trong trường hợp này: bottle neck ở memory.

Với C++ hay native code có thể chạy nhanh hơn nữa nhờ memory prefetch - hide cost của L2 miss, rất tiếc JIT, IL, C# ko có vụ này :|

Join hai DataTable lại với nhau!

automail-noreply@dot.net.vn — Thu, 20 Mar 2008 19:13:48 GMT

Join hai DataTable lại với nhau!

Vì có một số lý do nên tớ phải lấy dữ liệu từ hai Database khác nhau lên hai DataTable, tất nhiên là hai table có thể kết nối được với nhau.

Tớ muốn xây dựng thuật toán "LEFT OUTER JOIN" hay "INNER JOIN" cho hai table này trên C#, có bạn nào biết không nhỉ?
Mình chưa hiểu rõ ý của bạn lắm. Có phải bạn có 2 table từ database(s) đâu đó, không có mối liên hệ nào cả. Sau khi đã nạp vô .NET (dataset của ADO.NET, maybe), thì bạn muốn tạo relationship cho 2 tables này giống như là đã dùng Inner Join của SQL phải vậy không?

Nếu bạn dùng dataset, xem cách dynamically add relationship của dataset. (Cứ google hoặc vô MSDN)

Nếu bạn không dùng dataset mà đọc trực tiếp vào data collection nào đó của bạn thì bạn phải làm bằng tay thôi. Lúc đó thì lại có nhiều vấn đề để bàn lắm chẳng hạn như bạn muốn chạy nhanh hay muốn ít tốn bộ nhớ, có muốn sau này bind vô một cái datagrid nào không.

1/ Thuật toán dễ nhất, tốn bộ nhớ, cách mà SQL nói chung hay làm khi bạn dùng join là Product:

Table 1:
A
B

Table 2:
1
2

Product của nó là mảng 2 chiều:
array[,] = { (A,1), (A,2), (B,1), (B,2) }

Khi đó, muốn lấy ra kết quả theo A chẳng hạn sẽ là: array[A, x]
Còn muốn lấy theo 2 chẳng hạn thì sẽ là: array[x, 2]

2/ Một cách khác ít tốn bộ nhớ hơn và nhanh tương đương: dùng Hashtable (Dictionary trong .NET 2.0)

a/ Hash of hash: Hash(table 1, Hash (table 2))
b/ Hash - List - Hash:
table 1: Hash (table 1, list(table 2 - ID))
table 2: Hash (table 2, list(table 1 - ID))

Cách a chính là Left Outer Join đấy. Còn cách b thậm chí cho bạn M:N relationship luôn. Nhìn sơ qua thì thấy cách b chiếm nhiều bộ nhớ hơn phương pháp Product nhưng thực tế không phải vậy bởi vì HashTable chỉ lưu reference pointer thôi.

Bạn nói tớ cũng hiểu sơ sơ, hiện tại tớ không quan tâm nhiều đến performance của nó, output của tớ chỉ cần return một datatable là đủ, ý tớ muốn nói rằng vì hiện tại hai Table không cùng nằm trên một Database nên tớ không thể SELECT các giá trị trên hai bảng đấy bằng cách LEFT OUTER JOIN chúng nó (tớ quan tâm đến LEFT OUTER JOIN hơn), do vậy tớ phải load hai table đấy lên hai DataTable của C# và bắt buộc phải SELECT các giá trị và LEFT OUTER JOIN trên đấy.

Khổ nổi thằng Dataset trên C# không hỗ trợ câu lệnh SELECT như trong Database, chỉ có thằng DataTable chỉ hỗ trợ câu lệnh SELECT thôi. Do vậy bằng cách nào đấy tớ vẫn có thể lấy dữ liệu trên hai DataTable như là lấy dữ liệu bằng câu lệnh SELECT và LEFT OUTER JOIN hai table như trong Database.

Ví dụ nhé:

Giả sữ tớ đã load lên hai DataTable:

Table1

ObjectCode Description
... ...

Table2

UserID Name Email
... ... ....

Nếu hai table trong một Database thì quá dễ:

SELECT ObjectCode, Description, Email
FROM Table1 LEFT OUTER JOIN table2
ON Table1.ObjectCode = Table2.Name

Bi giờ tớ muốn lấy dữ liệu trả về DataTable y như câu lệnh SELECT ở trên nhưng bằng code C#

Mình không hiểu tại sao bạn lại phải khổ công như thế, nếu bạn chỉ muốn filter records của một table thì dùng dataview, nếu bạn muốn lấy records của 1 table dựa theo relationship của nó với table khác thì dùng relation giống như bài viết này:
http://www.c-sharpcorner.com/databas...RelationVK.asp

Còn nếu bạn vẫn cứ "ngoan cố" khăng khăng đòi cho bằng được cái left outer join đó bằng C# thì đây, mình làm cho bạn rồi nè. Bạn nợ mình 1 ly cafe đá vì cái "tội" làm mình mất đứt 45 phút. :-)

Tóm tắt "quy trình công nghệ" như sau:
- Tạo hashtable (để lookup cho lẹ) với key là join field ID của table 1
- tạo table mới với tất cả columns của cả table 1 lẫn table 2
- iterate toàn bộ rows trong table 2, chép dữ liệu sang table kết quả, dùng hashtable để kiếm row tương ứng của table 1 và điền sang table kết quả luôn.

Cách làm này sẽ chậm hơn SQL join query nếu dữ liệu ít, còn nếu dữ liệu nhiều thì tất nhiên sẽ nhanh hơn bởi vì SQL phải làm product join trước khi left join.

Source của class chính nằm dưới đây. Cho mình email nếu bạn muốn cả cái demo project nữa.

(xin lỗi bác admin cho tui paste code ở đây nhá, bữa nay làm biếng quá nên post source ở đây luôn cho lẹ)

Code:

public class JoinTable
    {
        /// <summary>
        /// This method is similar to the following SQL query:
        /// 
        /// SELECT *
        /// FROM T1 LEFT OUTER JOIN T2 
        /// ON T1.T1JoinField = T2.T2JoinField
        /// </summary>
        public static DataTable LeftOuterJoin(DataTable T1, DataTable T2, string T1JoinField, string T2JoinField)
        {
            DataTable result = new DataTable();

            //add all columns of T1 to result table
            for (int i=0; i< T1.Columns.Count; i++)            
            {
                DataColumn newcolumn = new DataColumn(T1.Columns[i].ColumnName, T1.Columns[i].DataType);
                result.Columns.Add(newcolumn);
            }

            //add all columns of T2 to result table
            for (int i = 0; i < T2.Columns.Count; i++)
            {
                DataColumn newcolumn = new DataColumn(T2.Columns[i].ColumnName, T2.Columns[i].DataType);
                result.Columns.Add(newcolumn);
            }

            //create a hash for lookup of T1, key is T1JoinField
            Hashtable T1hash = new Hashtable();
            DataColumn dc = T1.Columns[T1JoinField];
            for (int i=0; i< T1.Rows.Count; i++)
            {
                DataRow dr = T1.Rows[i];
                T1hash.Add(dr[dc], dr);
            }

            //iterate through all rows in T2, add to result table
            int MergedColumnCount = T1.Columns.Count + T2.Columns.Count;
            DataColumn dcLookup = T2.Columns[T2JoinField];
            for (int r = 0; r < T2.Rows.Count; r++)
            {
                DataRow dr = T2.Rows[r];
                object[] data = new object[MergedColumnCount];

                //get lookup key
                object key = dr[dcLookup];

                //copy values from T1 row    
                DataRow T1Row = (DataRow)T1hash[key];
                for (int i = 0; i < T1.Columns.Count; i++)
                {
                    data[i] = T1Row[i];
                }

                //copy values from T2 row
                for (int i = 0; i < T2.Columns.Count; i++)
                {
                    data[i + T1.Columns.Count] = dr[i];
                }

                //add new row to result table
                result.Rows.Add(data);
            }

            return result;
        }
    }

nhưng hình như "quy trình công nghệ" của bạn không mang tính LEFT OUTER JOIN, vì trong trường hợp với một row trong T1 nó lại không có các child rows của nó trong T2, với trường hợp này chúng ta cũng phải nhét 1 row với các trường của T2 là null vào trong bảng result và ngược lại với RIGHT OUTER JOIN, một row trong T2 nó không có parent row trong T1.

Bạn hãy nhìn vào đoạn code này:

//copy values from T1 row
DataRow T1Row = (DataRow)T1hash[key];
for (int i = 0; i < T1.Columns.Count; i++)
{
data[i] = T1Row[i];
}

trong trường hợp T1Row trả về null thì sao ---> gần như chương trình sẽ báo lỗi, tớ thay đổi code một chút:

DataRow T1Row = (DataRow)T1hash[key];
if (T1Row != null)
{
for (int i = 0; i < T1.Columns.Count; i++)
{
data[i] = T1Row[i];
}
}

có thể với code như vậy thì giải quyết được vấn đề INNER JOIN.

Tớ cũng đã nghĩ ra cách giải quyết như thế này, nhưng chưa code:

1. Add hai DataTable T1, T2 vào trong một DataSet, tạo DataRelation cho hai DataTable đó.
2. Tạo bảng T3 có column là tất cả T1 và T2
3. Iterate toàn bộ row trong T1 -> với mỗi row trong T1 lấy các childrows của nó trong T2

4. Nếu childrows.Length > 0:
iterate các childrows, và add vào T3, với mỗi childrow lấy parentrow tương ứng với nó để add vào T3.

5. Nếu childrows.Lenghth == 0:
add row trong T1 vào T3 với các trường của T2 là null.

Nếu bỏ trường hợp 5 là bài toán INNER JOIN.

Đúng vậy đấy bạn ạ. Mình có kiểm tra và phát hiện lỗi này khi viết code cho bạn. Có điều mình nghĩ viết cái code trên để tóm tắt cách làm thôi chứ không cần phải hoàn chỉnh hết cho bạn. Mình đang viết opensource cho bạn mà, muốn customize hay finish thì ngoài ly cafe bạn phải trả thêm tô hủ tiếu nữa cho phí consulting chứ

Cái ý tưởng của bạn là đúng hướng rồi đấy. Có điều hình như bước 3 là Right outer join chớ đâu phải Left nhỉ? Mình không chắc cho lắm. Mà cũng chả sao, miễn ra kết quả bạn cần là được rồi.

Mình thắc mắc tại sao bạn lại phải nhọc công thế nhỉ? Có phải vì bạn muốn tạo table tạm thời cho reporting chăng? Mình mắc cái tật không thích chơi với ADO.NET và CrystalReport cho nên cũng không thích SQL nốt. Chương trình của bạn có Data Abstraction Layer không đó? Nếu có thì không cần sql join chi vậy cho mệt đâu. Mình có 1 cái DAL made-in-tự-tui không đến nỗi xuất sắc nhưng cũng khá hay. Ví dụ để select table 2 với ID là SomeID1 chẳng hạn thì chỉ cần thế này:

SimpleCondition condition = Condition.Equal("ID", SomeID1);
objects = Database.Get(typeof(Table2), condition);

Còn cái chuyện join khỏi cần là vì với object, mình hoàn toàn có thể làm vầy:
table2object.table1object.Description = "something";

Tức là reference giữa object với object là chuyện đương nhiên, khỏi cần select với chả join.

Các DAL khác cũng na ná như của mình vậy. (nếu bạn chưa tìm hiểu về DAL thì có thể google các khái niệm: Objection-Relational database mapper, Persistent framework layer)

Về câu hỏi của bạn thì tùy:
- tùy theo reporting engine nào (threaded hay không, có server hay không, có cache hay không, vv)
- tùy theo khả năng DBA của bạn (reporting engine lớn được đầu tư rất nhiều để optimize data-load mà. Còn mình chắc gì đã bằng họ. Nhiều khi thấy câu SQL query có 1, 2 dòng nghĩ là nhanh nhưng chưa chắc đã vậy).
- tùy theo database engine và reporting engine nằm cách nhau bao xa. (remote or local)
- tùy theo report engine và user interface cách nhau bao xa (thin, fat, hay smart client)
- tùy theo chương trình của bạn cần scalable như thế nào, có bao nhiêu tier.

Nói túm lại thì phải "trông trời trông đất trông mây, trông cho chân cứng đá mềm...."

Mình nghĩ quan trọng nhất là project của bạn cần phải hoàn tất trong bao lâu, budget bi nhiêu, sau này có cần sửa đổi nhiều hay không. Chớ còn cái chuyện optimize giữa SQL và Reporting cái nào hơn thì khó nói lắm bạn ạ. Bản thân professional DBA chưa chắc gì đã dám khẳng định cái nào hơn.

Tuy nhiên, không phải là đã www.pótay.com . Nếu bạn có thời gian thì cứ benchmark hết tất cả mọi thứ là xong. Benchmarking và profiling tốn nhiều thời gian lắm (vì thấy kết quả chậm quá phải xóa hết đi viết lại). Tuy nhiên nó sẽ cho bạn nhiều kinh nghiệm ngạc nhiên mà đến dân pro cũng chưa chắc đã biết.