Re: Database Hosting
From: Volker Hetzer <firstname.lastname_at_ieee.org>
Date: Tue, 21 Nov 2006 17:23:51 +0100
Message-ID: <ejv96m$28e$1_at_nntp.fujitsu-siemens.com>
>> 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?
Btw, how many customers do you expect?
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.
Date: Tue, 21 Nov 2006 17:23:51 +0100
Message-ID: <ejv96m$28e$1_at_nntp.fujitsu-siemens.com>
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.
Btw, how many customers do you expect?
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.
For serious database applications think about a serious database.
Lots of Greetings!
Volker
-- For email replies, please substitute the obvious.Received on Tue Nov 21 2006 - 17:23:51 CET