Subject | Re: [firebird-support] Design question |
---|---|
Author | Jesper B. Kiær |
Post date | 2004-05-18T13:48:20Z |
Hi
I was not trying to compare Lotus Domino to RDBMS, merely stating that
speading data to several databases in Domino/notes is quite normal. It is
true that IBM is moving to DB2 ín Domino 7 as an option, but you can still
use the old format.
The "real life" information about the RDBMS is very valuable, thank you!
Could you tell what MOM is?
"Never delete rows.." ? What are the reasons for not deleting data ?
regards
Jesper B. Kiær
Jezzper Consulting
Website : http://www.jezzper.com
"David Johnson" <d_johnson@...> wrote on 18-05-2004 06:22:47:
I was not trying to compare Lotus Domino to RDBMS, merely stating that
speading data to several databases in Domino/notes is quite normal. It is
true that IBM is moving to DB2 ín Domino 7 as an option, but you can still
use the old format.
The "real life" information about the RDBMS is very valuable, thank you!
Could you tell what MOM is?
"Never delete rows.." ? What are the reasons for not deleting data ?
regards
Jesper B. Kiær
Jezzper Consulting
Website : http://www.jezzper.com
"David Johnson" <d_johnson@...> wrote on 18-05-2004 06:22:47:
> Lotus Notes is not really comparable to RDBMS's, or so the Lotus[Non-text portions of this message have been removed]
> Notes group at work tells me. The RDBMS is much more efficient for
> large structures, but notes works well for small scale rapid
> development. IBM is rewriting Notes to start using DB2 as its back
> end because of the issues with the Notes SAM structures in large
> scale environments.
>
> Where I work, our real-time production database is roughly 8TB in
> size. We support roughly 8,000 concurrent users in a real-time
> business environment on multiple platforms, processing roughly 1,
> 200,000 database transactions per hour. We're not using Firebird at
> work, but the principles of ISAM based RDBMS design don't vary a lot
> - only the specifics for particular implementations.
>
> In my experience, we break relational databases apart so that the
> real-time processes are not impacted by ad-hoc querying for decision
> support, or for security reasons. Each of our databases has several
> hundred tables (1,200 is the figure that comes to mind), with
> anywhere from 1 to several million rows. Busy tables will be broken
> into a "current" and "warehouse" table, with a nightly archive job
> that moves data from the current to the warehouse as it ages. Where
> data must be propagated between databases in a timely manner, we use
> a MOM product.
>
> Indexing is critical for your database app. Design compact indeces
> and minimize I/O. Keep relationships simple, and the processes to
> maintain them simple as well. Avoid duplicated work. Never delete
> rows (hot button ... oops), except as the cleanup after a successful
> archival process..
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>