<p>I have some products that belongs to the some category.</p>

<p>Each category can have different properties.</p>

<p>For example, </p>

<ul>
<li>category <em>cars</em> has properties <em>color</em>,
power, ... </li>
<li>category <em>pets</em> have properties  <em>weight</em>, <em>age</em>, ...</li>
</ul>

<p>Number of categories is about 10-15.
Number of properties in each category is 3-15.
Number of products is very big.</p>

<p>Main requirement for this app is very good search. We will select category, and enter criteria for each property in this category.</p>

<p>Have to design database for this scenario. (SQL Server 2005)</p>

If the user of the application
has
to select a category before they can search, I would separate your products into different database tables by category.  This solution is also indicated by the fact that the categories themselves have so little in common.  Breaking it down by category will also make each search much faster, since time won't be wasted searching through cars when your user is looking for a pet.
Once you have the products split up in to categories, it should be easy to create the tables using the common properties of the products in each category.  The user interface of your application should be dynamic (I'm thinking of a web form), in that the properties the user can choose from should change when the user selects a category.
Please note that if you have products that you want listed in multiple categories, this solution will result in duplicate data in your tables.  There is a trade-off between speed and normalization when designing a database.  If you
don't
have products that fit in multiple categories, then I think this will be the fastest solution (in terms of search speed).