Subject | Re: [firebird-support] Design question |
---|---|
Author | Alexandre Benson Smith |
Post date | 2004-05-17T22:56:34Z |
Jesper B. Kiær wrote:
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
>HiHi Jezzper,
>
>
>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
>
>
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