--- In firebird-support@yahoogroups.com, "women_lover_best"
<talbronstien@g...> wrote:

> We are developing a POS application..on average there will be 50-60
> terminals connecting to server..and there will be many transactions

in

> day(guess 1 to 2 lakh)..now should i make my transaction table for
> each month..which means there will be 12 tables..or is there any

other

> way..i am thinking from performance and management..and reports..
> thks

No!

Single table please. If splitting it into different tables actually
helps at all, it is because you do not have one ore more adequately
defined index(es) to help your queries run.

What is your POS system going to do next year when it uses up its 12
tables?

200,000 records a day while significant should not be a problem if
your database is well designed. If this is your expected throughput,
then an index on any date field would have pretty horrible
selectivity, so perhaps combine it with something else such as the
primary key of the table.

In terms of performance and management, if you do not normalise a
database of this size it will slow to a crawl very quickly.

Adam