Hi

Thanks for the quick reponse :-)

My question on designing the database "the right way" is not so much the
application I'm working on but more in a generelle sense...like when is a
certain amount af tables considered "too many" design wise?

I plan to use Firebird a lot in the future, so would really like to do it
"the right way"

I come from a Lotus Notes/Domino world where it is normal to split data
into different databases

Not being able to do cross database joins, I guess forces one to use a
single database pr. application ?


regards
Jesper B. Kiær

Jezzper Consulting
Website : http://www.jezzper.com




Alexandre Benson Smith <iblist@...>
17-05-2004 19:56
Please respond to
firebird-support@yahoogroups.com


To
firebird-support@yahoogroups.com
cc

Subject
Re: [firebird-support] Design question






Jesper B. Kiær wrote:

>Hi
>
>
>I'm no Firebird expert so I could use some advise. I need to make a
>database which potentionally could be large with lots of tables and data
>
>
>When should an applications data be split to several databases?
>
>I have no idea what is the normal/correct way to do it in consideration
>to number of tables, rows and so on.
>
>My main concern is of course performance
>
>I would appreciate some guidelines. Anyone?
>
>
>regards
>Jesper B. Kiær
>
>Jezzper Consulting
>Website : http://www.jezzper.com
>
>

Hi Jezzper,

A good designed database should not suffer to be big (millions of
records).

FB does not accept cross database joins (if one table are on a database
you could not join to tables on others databases..)

FB 1.5 uses 64 bit I/O for file handling, so the file size should be
not a problem (of course the Operating System should allow 64 I/O too).

If you have a large (very intensive) database using a plenty of SCSI
discs on a RAID will be very good for performance.

You could have 2 databases:
1.) Live database, where everyone will put and search for "hot"
information.
2.) A historical database, that will be refreshed (restored from backup
from live database) every week (day/month/etc.) that could be used for
Large Reports and Data Mining

Could you be more precise in terms of size for all tables and for your
biggest table, number of concurrent users, typical usage, etc.

see you !

--

Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br





Yahoo! Groups Links








[Non-text portions of this message have been removed]