Results 1 to 5 of 5
  1. #1
    Join Date
    Dec 2006
    Posts
    1

    Database Design Problem?

    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
    Last edited by r937; 12-23-06 at 07:55.

  2. #2
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    will you be storing any data besides information pertaining to each sales rep? if so, what is it?
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  3. #3
    Join Date
    Oct 2002
    Location
    Baghdad, Iraq
    Posts
    697
    Quote Originally Posted by diptra
    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""
    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.

  4. #4
    Join Date
    Jul 2003
    Posts
    74

    Any recommendations for tools ?

    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

  5. #5
    Join Date
    Oct 2002
    Location
    Baghdad, Iraq
    Posts
    697
    Quote Originally Posted by bdimple
    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 ?
    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.

    I don't like UML and Use Cases.
    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.

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •