> Thanks for your advices.
> For my problem "stock management" is management of IN and OUT
> things.

When you say things, and you mean something specific that you have
already modeled in your database but you want to be abstract in your
communication, then it's fine. But, if you really mean literally "things"
in my experience that's recipe for trouble. You do not manage things,
you manage something that is semantically defined.
Of course, I might be completely wrong and you have modeled things
and it works for you, then it's also very fine.

> For stock I'll use a single table.Application has to
> create various reports like "In/out from 01/07/2007 to
> 31/07/2007" that's way I decided to organize stock by moth.
> I'll take a report example :
>
> In/out from 01/07/2007 to 31/07/2007
> --------------------------------------------------
> Id Begin quant.(on.01/07/2007) In Out Rest(on 31/07/2007)
> ------------------------------------------------
> So, the stock is organized by months,it's true that depend of
> I/O of every day.
> Rest = Begin quant+In-Out.
>

Reporting is very easy if you have done your database model right.
When posting code try to use SQL and not some pseudo .Net code
because this group can really help you with SQL.

Another advice I would give you is to prepare sql scripts to insert random
but meaningfull
data into your tables. It should be set up in a way that enables you to
generate
as many rows in tables as you need. That way you will be able to really test
how
your application behaves under more or less something that will be used in
production.
That will also enable you to see problems with you SQL code in advance,
since it is very
easy to write SQL that gives you right results, but is totally useless
speed-wise when you
have 500.000 rows in a table. Differently written sql statement will also
give you results
but in much less time.

Sasha