storage of orders

[El Nino]

In a dynamic website I manage some (1000) articles in Access MDB.
My articles are "static" but the orders are very dinamic, write, modificy,
delete after 60 days, etc...

The storage of orders can I make it in the same MDB or better in a new MDB?

Thanks

EN

[Bob Barrows]

On the face of it, I see no compelling reason for a different database, but
I probably don't know the whole story. Why don't you try listing your
reasons both for and against creating a new database and let us critique the
list.

--
Microsoft MVP - ASP/ASP.NET - 2004-2007
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[El Nino]

"Bob Barrows" <reb0...@NOyahoo.SPAMcom> ha scritto nel messaggio
news:uOZ1ZZ3D...@TK2MSFTNGP05.phx.gbl...

The first MDB is almost "static". The articles, now about 1000, very little
change; no need almost no maintenance.
Contains Item ID, description, pricing, category, sub-category, shipping and
so on ..

The second, the orders, is continuously increased because for each order
enter a new record
The order records are modified (shiiping date, shipping number, etc..), and
then removed when obsolete after 60 days.
This MDB show to the customers the order status.
This second MDB needs more maintenance because each record/order is deleted
after 60 days.

I hope that I explained, and sorry for English.

Thanks

EN

[Bob Barrows]

El Nino wrote:
> The first MDB is almost "static". The articles, now about 1000, very
> little change; no need almost no maintenance.
> Contains Item ID, description, pricing, category, sub-category,
> shipping and so on ..
>
> The second, the orders, is continuously increased because for each
> order enter a new record
> The order records are modified (shiiping date, shipping number,
> etc..), and then removed when obsolete after 60 days.
> This MDB show to the customers the order status.
> This second MDB needs more maintenance because each record/order is
> deleted after 60 days.
>

That is simply repeating what you originally said :-)

You need two lists:
one containing reasons to keep everything in a single database
the other containing reasons to split the orders off into another
database

Start with these and add to them:

Single database:
1. less chance for errors/confusion with connection strings in
application code
2. slightly less code to write since you will only be opening a single
connection per page*
3. less memory used by connection objects since again, only one
connection will be opened per page*
4. there is nothing preventing Orders from being maintained just because
a static table exists in the same database
* assuming that both orders and reports will be used by a single page

Multiple databases:
1. Reports do not need to be backed up as often as Orders, so using two
databases will facilitate using diferent maintenance (backup) plans

So there is nothing really compelling that i can think of. Can you add
to these reasons? Start with why you think you need multiple databases.
Given that the reports are static, the size issue is not really relevant
in my mind.

--
HTH,
Bob Barrows