Building asp.net apps for multiple customers

N

NH

Hi,

I am sure this has been discussed before but I can't find much on it. I am
building a hosted asp.net 2.0 application that is going to be used by
mulitple customers. Or course they should only be able to see their own data
and there is a possibility that they may want to customise their own web app.

So what is the standard for doing this? Seperate websites on IIS for each
customer? Seperate databases for each customer or a shared database?

Thanks
 
S

sloan

My where I am at... different databases is the way to go.
Having to throw "Where CustomerID=123" all over the place sucks.

...

If they need customizations... you need a STRONG business layer, and strong
datalayer.

Then you can either skin/theme it.....per customer. Or have a website per
customer.

The the functionality is the SAME, then theme/skin would be preferred.

This is one opinion. You'll need to read the other opinions as well.

...

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry
For an example of a business layer.

.................

I am also assuming you are using the same RDBMS for each customer. (Sql
Server?)
If you need to support multiple RDBMS, please mention that as well. That's
a different motza ball.

...
 
N

NH

Thanks sloam,

Yes I am just using SQL Server 2005. I thought seperate databases would be
the best approach alright.
 
O

oaksong

Hi,

I am sure this has been discussed before but I can't find much on it. I am
building a hosted asp.net 2.0 application that is going to be used by
mulitple customers. Or course they should only be able to see their own data
and there is a possibility that they may want to customise their own web app.

So what is the standard for doing this? Seperate websites on IIS for each
customer? Seperate databases for each customer or a shared database?

Thanks

I would strongly dis-recommend multiple databases, if you expect to
have more than a dozen customers. Even this many will produce a
maintenance nightmare when it comes to trying to keep the structures
in synch.

I worked on an app several years ago where we expected to have
thousands of customers and multiple databases would have been a bad
joke.

Think in terms of a bank, which has hundreds of thousands if not
millions of customers. They only have "one" database.

I was getting pushed to produce multiple databases and once I'd shown
the amount of effort required to make a simple change, the idea was
quickly rejected.

What's important is providing appropriate customer id fields in your
upper level tables that will allow you to easily get and put records
based on customer id. You will also need a strong security layer. Do
NOT under any circumstances provide database access to the customers,
only the application should be able to open the database. This also
eliminates a huge password maintenance issue.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,997
Messages
2,570,239
Members
46,827
Latest member
DMUK_Beginner

Latest Threads

Top