Re: Database Hosting

Volker Hetzer wrote:

> Murdoc schrieb:
> > Bob Badour wrote:
> >
> > > Joshua J. Kugler wrote:
> > >
> > > > Murdoc wrote:
> > > >
> > > >
> > > > > Hi all,
> > > > >
> > > > > Our company is about to embark on rewriting our entire application to be
> > > > > truly client/server based, and bring the UI up to .NET. One of the
> > > > > additional services that our CEO wants to provide is the hosting of the
> > > > > software ourselves (to save our smaller clients the licensing costs of the
> > > > > database server software, etc).
> > > > >
> > > > > However, the proposed solution to this is to simply have a single database
> > > > > with every client's data in it, and add a 'client-code'/'client-id' field
> > > > > to EVERY single table in the database.
> > > > >
> > > > > Now, to me this seems to be a seriously flawed method of doing it, when a
> > > > > much simpler option (one database per client) is available.
> > > > >
> > > > > What are your thoughts, and how do other companies provide a similar
> > > > > service?
> > > > How is security laid out? Is it table or row based permissions? If it is
> > > > table based permissions, a user could log in with another client for your
> > > > SQL server and issue queries on data that does not belong to them. I would
> > > > *highly* recommend doing one database per customer. Security (in my mind,
> > > > anyway) will be greatly simplified.
> > > Is the security function in SQL Server really that bad?
> >
> > I didn't mention the database server software that was being used. We are using Progress, not SQL Server.
> 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.

> 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. 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.

> For serious database applications think about a serious database.

No comment.

--