Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

Building a Demo Server

By Steve Jones,

Building a Demo Server - Part 1 Designing The Server

Introduction

Ahh, the demo server. If your company is selling things, you probably will get asked to setup a system that allows the sales people to demonstrate your products without affecting live or production systems. Sort of a playground where salespeople and customers can make changes, try out the system and simulate any customizations you offer for potential customers or clients.

Now I know that some of you will setup accounts on your live server and allow customers to experiment there. You may have designed your system from the ground up to allow for demo capabilities. I applaud you, and will include these types of features in my future systems, but I have inherited a few systems over the years where this was not really permitted for a variety of reasons (I'll explain below). This series chronicles some of my challenges and decisions regarding my final solution.

I'm making notes as I design and implement the solution, so hopefully this will give some insight into how I build a solution and allow others to comment and critique. Since this article will not likely be released until the solution is implemented, I won't be able to incorporate feedback into the design, but I welcome your notes and comments and may modify my solution based on those comments.

Why not use the live system?

In my present job we have a couple of reasons why the live system cannot be used. The main reason is that we have a fairly integrated system with regards to moving information to downstream systems, like accounting, CRM, etc. The management doesn't want the any of this information moving downstream. Now we could add flags to various tables to prevent these feeds, but at the time when a demo system was required, this would have required quite a bit of work to modify systems and the resources were not available.

The second reason is also a reason why my previous employer also wanted a second system: load. The sales people want to be able to use this system at most anytime and allow it to perform in a manner that shows potential clients that our service is reliable. To do this, they need to be able to schedule a demo and ensure that there is not any other load on the system.

I've needed demo systems at each of my last few jobs and the reasons have always been similar. The impact of these demos might affect a live system. Or the live system might affect the demo. Not sure which is worse, but neither looks good, especially in front of a client.

Which Server?

Once you've agreed that a new server is needed, the next step if to pick a server. I've seen different choices, usually some spare server that is lying around. However, keep a few things in mind.

A demo server is the first view of your system that a potential customer sees. Not a client, not a customer, not someone who is paying you, but someone you WANT to pay you. Make this a good look. Using a spare server is fine, but I'd be sure that it's not last years model. Not an old desktop that isn't being used. Be smart and pay some money up front for a nice server that helps to sell your product. Nothing like seeing a demo run really slow and excuses from the salesperson that it's "only a demo server". This is important. Remember the sizzle sells the steak, and speed can sell your product.

Lots of people are tempted to drop the database on a development server. Not a bad idea, but this suffers from the same problems as using the live system. Load.

All it takes is one developer running a cross join on your largest tables at the wrong moment to kill the server. And a demo.

You may be budget constrained, but ask yourself how much that $4000 you're saving is really worth. do yourself a favor, choose a system that is similar to the production system. Buy RAID controllers, lots of memory and tune this server to run as well as or better than the production system. Personally, I'd classify this as a production system and treat it as such.

Choosing a server is usually the easy part. Buy a decent server, set it up and start running demos. However there are other things to think about. I'll tackle looking at data quality and freshness in part II of this series.


As always, I welcome feedback for this article (use the 'Your Opinion' tab below) and please take the time to rate this article.

Steve Jones
©dkRanch.net December 2001
Return to Steve Jones Home

 

Total article views: 6511 | Views in the last 30 days: 2
 
Related Articles
FORUM

Customize SQL Query

Customize

FORUM

Customize SQL server 2008 system error

how to track and customize error messages

FORUM

How to Create Custom System Function in SQL Server 2005

User Define System Function in SQL Server 2005

FORUM

production database sql server 2000

production database sql server 2000

FORUM

SSRS Reports deployment to Production Server

SSRS Reports deployment to Production Server

Tags
administration    
configuring    
installation    
sql server 7    
 
Contribute

Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:  

You make SSC a better place

As a member of SQLServerCentral, you get free access to loads of fresh content: thousands of articles and SQL scripts, a library of free eBooks, a weekly database news roundup, a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals that makes it such a success.

Join us!

Steve Jones
Editor, SQLServerCentral.com

Already a member? Jump in:

Email address:   Password:   Remember me: Forgotten your password?
Steve Jones