| Subject | RE: [ib-support] WHICH ONE IS BETTER |
|---|---|
| Author | David Montgomery |
| Post date | 2002-02-16T02:31:46Z |
Ben,
A couple of factors to consider:
1) How large do you expect each client's database to become?
2) How much processing activity will occur per client?
3) Will all of your clients be busy manipulating data at the same time?
4) Do you need to maintain shadow files or replication?
In our company's case, we maintain close to 3,000 separate IB files for each
of our clients to segregate their financial records. Our data definition
contains 46 tables per client. Most of our clients maintain rather small
files (< 100,000 records per database). A small minority of our clients
have more than 5,000,000 records in their files, though.
My original rationale for doing this was:
1) Client data is compartmentalized completely.
2) If one customer (or group of customers) wanted to purchase dedicated
processing power, we could move their file(s) to a dedicated machine
3) If we continue to grow, I can easily create subsequent client databases
on other IB machines
PRO's for this methodology:
---------------------------
1) High degree of data compartmentalism
2) Very flexible (as long as you are coding your applications for it since
DAY ONE: no assumptions about file location, etc.)
CON's for this methodology:
---------------------------
1) Had to write special routines to perform automated sequential backup of
files
2) Replication might not work very well (more time-consuming to setup, for
instance)
3) Had to write special routines to perform metadata changes to keep all
data files in a synchronized structure
4) Applying permissions for a user to 3,000 database files takes more than a
little time
5) When "spanning" multiple machines with database files, the isc4 password
database needs to be synchronized
6) Backups probably take longer compared to one large database with the
equivalent number of records.
Well, I have managed to not answer your question, I guess. Anyhow, we've
been operating under the "multi-file" architecture since 1998 with only a
minimum of pain and suffering... ;)
Best Regards,
David Montgomery
Do You Yahoo!?
Get your free @... address at http://mail.yahoo.com
A couple of factors to consider:
1) How large do you expect each client's database to become?
2) How much processing activity will occur per client?
3) Will all of your clients be busy manipulating data at the same time?
4) Do you need to maintain shadow files or replication?
In our company's case, we maintain close to 3,000 separate IB files for each
of our clients to segregate their financial records. Our data definition
contains 46 tables per client. Most of our clients maintain rather small
files (< 100,000 records per database). A small minority of our clients
have more than 5,000,000 records in their files, though.
My original rationale for doing this was:
1) Client data is compartmentalized completely.
2) If one customer (or group of customers) wanted to purchase dedicated
processing power, we could move their file(s) to a dedicated machine
3) If we continue to grow, I can easily create subsequent client databases
on other IB machines
PRO's for this methodology:
---------------------------
1) High degree of data compartmentalism
2) Very flexible (as long as you are coding your applications for it since
DAY ONE: no assumptions about file location, etc.)
CON's for this methodology:
---------------------------
1) Had to write special routines to perform automated sequential backup of
files
2) Replication might not work very well (more time-consuming to setup, for
instance)
3) Had to write special routines to perform metadata changes to keep all
data files in a synchronized structure
4) Applying permissions for a user to 3,000 database files takes more than a
little time
5) When "spanning" multiple machines with database files, the isc4 password
database needs to be synchronized
6) Backups probably take longer compared to one large database with the
equivalent number of records.
Well, I have managed to not answer your question, I guess. Anyhow, we've
been operating under the "multi-file" architecture since 1998 with only a
minimum of pain and suffering... ;)
Best Regards,
David Montgomery
> -----Original Message-----_________________________________________________________
> From: Ben Johnson [mailto:ben_johns@...]
> Sent: Friday, February 15, 2002 6:01 PM
> To: ib-support@yahoogroups.com
> Subject: [ib-support] WHICH ONE IS BETTER
>
>
>
> Hi,
>
> I am planning to develop an application for a tax consultancy
> firm. This firm has around 240 customers
> and this may go upto a maximum of 400.
>
> So each customers account has to be kept seperately for each
> financial year. This application requires only
> 20 tables.
>
> What I want to know is how to design the database? Do I have to
> keep seperate database for each customer?
> Or using a single database and identifying each customers
> transactions based on customer code? Which one
> is better? Pls help.
>
> Thanks in advance.
>
> Ben.
>
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
Do You Yahoo!?
Get your free @... address at http://mail.yahoo.com