database - SQL Server architecture guidance -

We are preparing a new version of our existing product on a new schema. Probably with 100 concurrent users (maximum), this is an internal web application that will run on a SQL Server 2008 database.

In the discussion items recently, we have to have a single database of databases to be displayed

We are developers and not DBA, so some general guidelines It would be nice to receive

[I know that the answer is not simple because it depends on the schema, collection policy, quantity of data, etc.)

Option 1 Single Main Database [This is my favorite option]

For this scheme, all tables should be in a single database and possibly to use data grouping and partition to separate the data if necessary in many disks [if appropriate, use Schema ] It should deal with performance concerns. One of the comments is that this single server example is still processing this data, thus still processing bottle neck will be.

We have a separate reporting db for reporting but it is still being discussed.

Divide the option 2 database into 2 separate databases

DB1 - Customer, Accounting, Customer Resources etc.

DB2 - This includes bulk of data [i.e. vehicle tracking data, financial transaction tables, etc.]

These tables usually contain a lot of data [can be left on a separate server when necessary] < / P>

In this scheme, keeping the main data in a small database [DB1] and [primarily] separate DB [DB2]. The UI will mainly be read from DB1 and thus more sensitive. [I know that this option makes it difficult to apply the referential integrity.]

Points for consideration as we are in the design phase, so we have to minimize the performance issues You can make proper use of indexes. This is the reason why the option 1 for me is attractive and has a standard approach for both options, we are considering implementing a collection database.

Appropriate Concern for a Long Question is Question 1 DB or 2?

Thank you in advance,

Liam

My thoughts There is a way to go option 1.

The CPU is unlikely to interfere with the 100 concurrent users who provide your workload. You can acquire a single multi-socket server, which is available through hot swap technology with an additional CPU capacity, so that you should offer room to grow. Due to your availability requirements, you may consider using a clustering solution so that more processing fails on the second node for swapping in the CPU resource.

Displaying your disk subsystem is your biggest concern. Your design decisions will be affected by the storage solution you use, which I believe San Technology

As a minimum, you depend on your logs (red1) and data files (red 10 or 5) of different LUNs.

Depending on your table access, you may want to consider putting different file groups on separate LUNs. The division of your table data can prove to be useful for you but only for big tables.