Hi Everyone,

I want to build the site for independent sales representatives, can anyone tell me that how can i design the database for sales representatives. means, how many tables i requried, or can i find those type of database creation tips on the net.

""URGENT""

Regards,

Faisal

will you be storing any data besides information pertaining to each sales rep? if so, what is it?

Well, if it's urgent then you'd better make sure you get it right the first time.

Now, having done projects like this where the first few designs were completely screwed up, I can tell you that jumping right in to coding or trying to cut and paste stuff from the web is the worst way of going about it.

Here are three tools you can use to work out a design: (there are many more)

1. Use-case scenarios. Basically, you imagine what people are going to do and work out exactly what they'll be working with. Personally, I think these are best when you're considering adding a feature to an existing project, or as a means of documentation. For a new system, the next feature is probably better.

2. Prototyping. It's obvious: you build something quick and dirty that lets you see how it's going to work with the intent of scrapping it and doing the actual design from scratch. The road to hell being paved with good intentions, there are probably a lot of systems that are built on prototypes that never got scrapped.

3. A requirements document. This is a non-technical discussion of all the things your product has to do. Requirements are often broken down into functional and non-functional where a functional requirement is "the product is required to perform this function" and a non-functional requirement is something like "we're running on Windows so the product must run on Windows." If it's just you writing the software, you probably don't need to worry about non-functional stuff.

Now, as to implementation:

Web sites and apps need lots of windows and pages and menus and whatnot. You'll want to do a storyboard that shows how all these things fit together. Your storyboard also needs to detail all the data that is needed to populate each page or window. For a UI heavy application, a well annotated storyboard is the best implementation document.

Once you've worked out the requirements and your storyboard, you can state your business rules. The layout of your tables and fields (known as the database schema) should follow pretty naturally from those rules. And if you're using a language like PHP the storyboard will tell you how to code each page.

One last thing: testing. You probably don't have the manpower to do full usability testing, but at least try to grab a few people, give them a set of tasks to complete and see if they can figure it out without hand-holding.

Hi Scoo8y,
I liked your answer recommending Use-case scenarios and so on.
It makes a lot of sense.

Do you have any recommendations for tools to support the quick and easy creation of scenarios, prototyping, requirements documents and so on ?

I don't like UML and Use Cases.

I find myself using Screenshots, or prototyped HTML Pages, coupled with a Data Dictionary and narrative User Scenarios.

But this approach too labour-intensive and doesn't help a lot in getting any application code written.

I look forward to hearing from you.

Thanks very much.

B.Dimple

For most small projects (one or two people actually writing code) I think a good word processor for the writing and paper and pencil for the diagrams.

Yeah, UML is great for people who love standards. If everyone knew UML it would be great. But it's probably quicker for them to read your one page of paper detailing the symbols you use then to try and look up the official UML symbols.

Documentation isn't about writing code. It's about making the code you write work. To be frank, anything worth getting paid for is inherently complex. Therefor, there's a limit to how simple your code can be. If your code isn't simple, it has to be well designed and that will take a certain amount of time and effort.