Re: Database Hosting
Date: Wed, 22 Nov 2006 16:27:04 +0100
Message-ID: <ek1q88$17m$1_at_nntp.fujitsu-siemens.com>
Murdoc schrieb:
> Volker Hetzer wrote:
>> No idea about them. If it were one of the big three (oracle, db2, sqlserver), >> I'd advise merging the data too, using the databases row level security >> features and maybe partitioning (one table partition per customer) for >> performance reasons.
>
> Hmm ... I'll research whether Progress has similar security.
>
>> Btw, how many customers do you expect?
>
> We wouldn't expect more than about 25 clients using this service. We are in a niche,
> country-specific market.
25 users is not much. And the number of clients only changes if you sell to a new client and this doesn't happen several times a minute, I presume.
In that case there's a third possibility: Does your database has the concept of "users"? I'm not mocking you here, oracle has, mysql IMHO not, I don't know about your database. I.e. can you have 25 accounts in one database, each account having its own set of tables, plus individual username/password combinations?
>> Databases cost maintenance hours too, don't forget that. You have to backup >> and update them all (software and schema objects) and doing so for a >> thousand or more is no easy job.
>
> Updating is not a problem, as we can easily script schema and source code changes, and
> apply those in bulk across all the DBs.
Er, yes. I'd love that too. And then 3 of the 25 databases make trouble and you have only one front end web server (or whatever) which /requires/ all databases to be identical and there you are.
With just one database you can always have a spare one for trial runs instead of 25.
> The maintenance gain that I see with using
> multiple DBs is that if a single client requires the restore of their data, we can do
> that far easier than if we used a single DB.
With two databases you can have that too. Again, I have no idea about whether
/your/ database can do that but with the big ones it often looks like that:
You've got one primary db, one standby db (with log transfer and everything) and one spare hardware/software installation without a database running. The purpose of the primary/standby pair is obvious. The purpose of the spare one is restore and trial runs. So, if the customer demands a restore from one week ago, you restore the whole database into the spare, export the data he wants to be restored (all, some tables or just some rows) and put it into the production database.
Of course, if that happens often, versioning of data might be worth thinking about.
Your mileage may vary of course.
Apropos, what amount of data are we talking about? If one user has a bunch of terabytes and needs 16GB of RAM, you'll probably need one "telephone booth" per client.
And what does "one database" in the Progress sense mean anyway? Is it one server with processes taking five minutes to start up or is Progress just a dll, like Berkeley DB?
If it's just a dll and your application runs on five files called "database", then one database per user is entirely reasonable.
Lots of Greetings!
Volker
-- For email replies, please substitute the obvious.Received on Wed Nov 22 2006 - 16:27:04 CET