About scaling a system

[Tony Johansson]

Hello!

TicketSystem
***********

Description:
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.

Specification:
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
information.
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
keys.

Conditions

* 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.

//Tony

 

[Brian Cryer]

Hello!

TicketSystem
***********

Description:
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,

If you don't 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.

the delegates, if so, then the head of the IT department can make the
delegate of the ticket later.

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.

Specification:
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
information.
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.

No. Firstly the biggest problem with comments is that there often aren't
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" doesn't mean anything.

I would suggest a comment for every block of code.

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
keys.

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?

Conditions

* 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.

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 doesn't
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.

* 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.

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'm 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.

 

[bradbury9]

El jueves, 14 de junio de 2012 10:11:10 UTC+2, Tony Johansson escribió:

Conditions

* 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 ?

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

can somebody gove me some guidelines what I must think of when designing and
implementing this so called ticket system.

Dont reivent the wheel. Check opensource c# ticket systems like http://en.wikipedia.org/wiki/BugTracker.NET maybe you safe time implementing it ratherthan coding and debugging it.

 

[Jeff Gaines]

Dont reivent the wheel. Check opensource c# ticket systems like
http://en.wikipedia.org/wiki/BugTracker.NET maybe you safe time
implementing it rather than coding and debugging it

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

 

[Brian Cryer]

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

True, but the suggestion is still sound.

There are 10 types of people in this world - those who understand binary and
those who don't.

 

[Jeff Johnson]

Dont reivent the wheel. Check opensource c# ticket systems like
http://en.wikipedia.org/wiki/BugTracker.NET maybe you safe time
implementing it rather than coding and debugging it.

Seriously? You didn't get that this is an educational assignment and the
whole purpose is to design and create a system, not just find one off the
shelf?

 

[Registered User]

Seriously? You didn't get that this is an educational assignment and the
whole purpose is to design and create a system, not just find one off the
shelf?

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.

regards
A.G.

 

[bradbury9]

El jueves, 14 de junio de 2012 18:02:57 UTC+2, Jeff Johnson escribió:

Seriously? You didn't get that this is an educational assignment and the
whole purpose is to design and create a system, not just find one off the
shelf?

I must say that I read he post fast, without paying much attention. After reading it again I realized that if was some sort of homework

 

[Tony Johansson]

Hello!

I can't 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

of people who are raising these tickets - but what that mechanism is will
depend on where it would be used.

What do you mean with this text about keeping a list with priorities ?
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.

//Tony

 

[Arne Vajhøj]

Conditions

* 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 ?

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
partitioning.

can somebody gove me some guidelines what I must think of when designing
and implementing this so called ticket system.

Follow normal design process.

Arne

 

[Brian Cryer]

Hello!

I can't see why you write that a need might exist to validate the identity
of a user that create the ticket

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.

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

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

Hope this helps.