.NET Framework - About scaling a system

Asked By Tony Johansson on 14-Jun-12 04:11 AM


A ticket system in this case is a system for handling information / files
submitted by various users.
A ticket may be a bug, an expansion or a different type of task.
Ticket system can in practice be used by an IT department, then develop it
as if you were to sit in it.
There should not be a login page so it will be open to all who visit it.
Nor shall there be any permissions, ie anyone can do all in it.
The person who puts up a ticket does not have to specify who should take
care of the task,
the delegates, if so, then the head of the IT department can make the
delegate of the ticket later.

Each ticket contains the title (text), description (text), priority (0-100),
owners (id of the user), date (datetime), done (bool).
The owner in this table is the user which the ticket has been delegete to
There should be a page that lists all the tickets with relevant
You should be able to specify which user you want tickets for,
alternatively, also specify the tickets do not have a user. It should also
be able to sort the tickets more than one column;
For example, priority, date.
You should be able to post new tickets, edit and delete existing tickets
and flag a ticket as complete.
The application will be developed in ASP.NET with C # and SQL Server
database to be used.
All code should be written in English and be well documented.
One should in principle be able to read everything that happens in the
program without reading one line of code, ie just by reading the comments.
An SQL dump of tables and content must also be provided.
There must be no SELECT statements that run without the use out of index


* It is expected to be as up to 16 users in the system.
* It is expected to be available as more than 500,000 tickets.
* The title is at most 32 characters long.
* The description shall be as long as possible.

I just wonder how will these four points have influence on the design and
implementation of the taskSystem ?
can somebody gove me some guidelines what I must think of when designing and
implementing this so called ticket system.


Brian Cryer replied to Tony Johansson on 14-Jun-12 05:29 AM
If you do not have a login page then you cannot verify the identify of the
person who raised the ticket. This means you will inevitably have wrong or
invalid people in your system . If it is at all important to be able to feed
back to the originator when the ticket has been closed then you will need
some form of login page.

At the very least you will require some form of account control for who can
delegate and who can respond to or close a ticket.

No. Firstly the biggest problem with comments is that there often are not
any. So its good to comment your code. BUT if you choose good names for
things and your code is well laid out then it is reasonable that someone
should be able to follow the code.

For example:
i += 1;    // Increment i by 1.
The comment is unnecessary, but the variable name "i" is a poor name because

I would suggest a comment for every block of code.

This sounds like a high-school project. Is it?
I think the specification is wrong. You should be designing all tables with
any necessary and appropriate indexes, but it is up to the database which
key (if any) it uses. Do you see the distinction?

500,000 per day, per year, per decade?
If each ticket requires (say) half an hour to close then assuming an 8 hour
day means each person can close 16 tickets/day. With 16 users you can close
256 tickets/per. So 500,000 tickets implies almost 2000 days worth, which at
200 working days a year indicates a 10 year lifespan. Of course this does not
take into account the rate at which tickets are opened. But assuming the
numbers of users is scaled to the number of tickets which will be opened,
then it sounds like the system will have a very low throughput.

As described it would be tempting to use a single table to ticket data. In
practise some tickets will require more than a single response. So for each
ticket there will be one or more responses (for want of a better term). So
those are probably best held in a separate table.

In practise you will need some mechanism to keep track of users, so that
implies another table. I think you also need a way to validate the identify
of people who are raising these tickets - but what that mechanism is will
depend on where it would be used. You might also want to keep lists of
priorities and the like as separate tables so they can be easily
configured - but for a small project it might be easier to define these
using an enum in code.

Is this the type of thing you were looking for?

I am not sure where you title "About scaling a system" comes in, becasue as
described this is a small system for which I doubt you would need to worry
much about scalability. Increase ticket rates by a factor of a thousand and
it might be different.

Hope this helps.
Brian Cryer
bradbury9 replied to Tony Johansson on 14-Jun-12 05:31 AM
El jueves, 14 de junio de 2012 10:11:10 UTC+2, Tony Johansson  escribi=F3:

If the database is well designed and indexed should be no problem with thos=
e our conditions.


Dont reivent the wheel. Check opensource c# ticket systems like http://en.w=
ikipedia.org/wiki/BugTracker.NET maybe you safe time implementing it rather=
than coding and debugging it.
Jeff Gaines replied to bradbury9 on 14-Jun-12 12:03 PM
On 14/06/2012 in message

Not sure if that would be acceptable as a submission for homework :-)

Jeff Gaines Wiltshire UK
There are 3 types of people in this world. Those who can count, and those
who cannot.
Brian Cryer replied to Jeff Gaines on 14-Jun-12 08:40 AM
True, but the suggestion is still sound.

There are 10 types of people in this world - those who understand binary and
those who do not.
Brian Cryer
Jeff Johnson replied to bradbury9 on 14-Jun-12 12:02 PM
Seriously? You did not get that this is an educational assignment and the
whole purpose is to design and create a system, not just find one off the
Registered User replied to Jeff Johnson on 14-Jun-12 07:02 PM
Problem solving requires abstraction; details should always be based upon
abstractions. Whether this is homework or not there is nothing inherently wrong
with examining existing models and abstracting their functionality into
identifiable, reproducible design patterns. When the abstractions are understood
the details start falling into place.

OTS tools and technologies do not represent solutions in and of themselves. A
suitable OTS package will match high level abstractions and will be extensible
in a manner which makes lowest level abstractions become implementation details.

BugTracker.NET may or may not provide a suitable framework for the OP to build
upon. Its abstract design can provide useful insights about what patterns will
be useful and what patterns to avoid.

bradbury9 replied to Jeff Johnson on 15-Jun-12 03:01 AM
El jueves, 14 de junio de 2012 18:02:57 UTC+2, Jeff Johnson  escribi=F3:

I must say that I read he post fast, without paying much attention. After r=
eading it again I realized that if was some sort of homework
Tony Johansson replied to Brian Cryer on 16-Jun-12 05:44 AM

I cannot see why you write that a need might exist to validate the identity
of a user that create the ticket
as you write here.
I think you also need a way to validate the identify

What do you mean with this text about keeping a list with priorities ?
You might also want to keep lists of

Arne_Vajhøj replied to Tony Johansson on 16-Jun-12 09:06 PM
It will help you estimate how big the database can become.

And that may impact the design.

In this case the data seems to be very small.

But because the choice of technology is given, then you may not be
able to utilize that for much.

Well - you can forget web server clustering and database

Follow normal design process.

Brian Cryer replied to Tony Johansson on 19-Jun-12 10:52 AM
1. To stop spammers, DOS etc.
2. To avoid people raising tickets as someone else just for a laugh.
3. You enter your username/email address wrong.

You referred to tickets having a priority. I was referring to where that
priority comes from.

Hope this helps.
Brian Cryer