Can an ASP.net website/project have more than 1 Database?

Question

I have this programming task due in about 15 days and I've decided to make a sort of shopping cart/web sales thing.

I'll have a Database with Products, Prices, Images, etc.

I was thinking of having another Database with processed orders, etc.

Should I just make a combination that works (make a single Database) or should I use Separate Databases for those cases?

ps. I'm not talking about Tables, I'm talking about DATABASES. Thanks guys

Answer 1

Unless you have a really good reason to have several databases, stick with one.

Having said that, there are no technical limitations on the number of databases for a single project.

EDIT: Reasons to have more than one database. In addition to already mentioned scalability option, you may also want to archive some very old stuff (by year, for example), if you see from the nature of your application that these old records will not be needed very often.

Answer 2

Although I'm sure there are plenty of reasons why you might need a seperate database for this, I would stick with a single database, and an orders table, (since im guessing you'll be refering to those same products within the orders). it will make foreign key references.... simpler....

Answer 3

If you use a single database, you can enforce the data integrity If you use two database you can distribute the charge

Answer 4

that'd be pretty poor database design splitting it up into products and orders it would'nt really work.

Answer 5

Keep to a single database unless there is actual reason to do so. For instance, if you mix pre-built apps that like to drop all tables before loading their own. Even then, you could hack their scripts and go with 1 db.

Also, unless you have a number of people working with you - creating a viable shopping cart in 15 days is going to be somewhat of a challenge. You may really want to look around for an OS cart that you can mod up. If you are a webforms guy, theres DashCommerce + a couple others out there. If you are into MVC, there is Kona you could mod.

Answer 6

At the enterprise level you want to limit the number of databases that need to be supported.

In SQL 7/2000 we took this to the extreme and used the same database for 30+ applications. These days we refer to that as a landfill database - it is incredibly difficult to support. We eventually settled on putting small one-off applications into the landfill database but creating a new database for anything that had 10+ tables, 100k+ records, etc..

With SQL 2005 we are hoping to use schema separation so the DBAs can have fewer databases but the developers can rely on schemas to understand which objects belong to which applications. We haven't perfected this concept yet but I'm relatively sure it will work out.

Answer 7

I don't see any reason for you to use multiple databases. The only advantages I can see of multiple databases are:

• Scaling - if you are a big commercial web site, it will be easier to scale using several databases (you can put each on a different server).
• Security - if you need certain information to be much more secure and you don't want to save it on the same database that has user created content (and thus might be exploited, i.e. SQL injection) you can separate it to another database on another machine on another internal network.

The main disadvantage is development complexity and the extra maintenance. Usually you could achieve some of the goals without another database. For example, if it is for security, it seems much more cost effective to me to try all the queries sanitizing and DB authentication schemes first

Answer 8

Most shopping carts and e-commerce solutions to buy use one database. Why are you thinking of multiple databases?

Are you thinking of multiple dbs to get performance benefits? You can use replication instead.

One instance of a problem with multiple dbs may be foreign keys. Some dbs, you can't create them across dbs.

Answer 9

The project I'm currently using is actually using three databases, with good reasons too. One database is used for users to provide data to the system and to review this data. The users are just in-house colleagues who are keeping the data for our applications up-to-date. The second database contains extracts from this user database, which is sent to the customers of our software products. These customers can't modify our data and we don't want to provide them access to the live data, especially since we first want to make sure the data is valid. The third database is used for generic error/message logging and for maintaining a user database.

The reason to divide the whole project over three databases was partly done for security. If someone has access to one database, the other two would still be secure. If one goes down, the other two would still be useful. The data in the three databases is completely unrelated, even though the data from one database is used to generate data for the other two. This is the most important conditions for using multiple DB's: the data should not be related to each other. (Although some DBMS systems do allow these cross-database links!)

Answer 10

My current project uses at least four databases, but that's because my project was a late addition, intended to pull data from three of them and display it on a map. The fourth database was created as part of the project, to store information about the maps and project users.

If I had to add new information that didn't fit with the database I created, I'd consider adding an entirely new database. But there's a major cost making sure that all the database work (SPs, views, table structure) stays consistent over three environments (local, test, production). I'm not sure I'd want to do it for multiple databases of my own creation. (I'm already lucky that it's someone else's job to maintain the other databases my project uses.)