[thelist] Data structure help

Steve Cook sck at biljettpoolen.se
Mon Nov 27 06:28:53 CST 2000


Hi folks,

I'm planning to build a tool for our intranet to help plan and manage our
sales strategy. The idea is to build up an "active document" for each
prospective customer. The "document" will be a series of web pages that draw
information from a database to show the following information;
	Which tasks need to be performed
	Which tasks have been completed
	Who completed each task
	When it was completed

Each page holds information about a specific part of the process (i.e.
identifying a prospect, contacting a prospect etc). The idea is that when a
sales person first creates a document for a prospect, it presents a table of
contents and each page. The pages contain information about the steps
involved in the process, but all the actual tasks are marked as incomplete.
The application is both a sales manual, helping to bring new salespeople up
to scratch in a short space of time and a record of all the sales activity
over time.

I want the sales person to then be able to simply start selecting
information on the page from built in form elements such as drop-downs, or
checkboxes. Selecting information will automoatically reload the page and
send the updated info to the database.

Some parts of the process will require the addition of extra information and
I envisage that clicking a link in the document will open a pop-up box which
contains a form for entering that type of data.

I have built a structure for the actual process and produced some template
pages. Now I'm thinking about the data structure and I'm feeling very
divided over the best way to structure the database which is used to store
this information.

One problem I'm having is that some of the data has one possible option for
a specific prospect (e.g. How did we learn about this prospect?) while other
data can have multiple values (e.g. Who are the contact people for this
prospect?). 

The other problem is that I want to record information automatically about
who last updated a particular piece of information. This can easily be
detected as the system is for intranet use, but I wonder whether I need to
create a second field for every updatable item, listing who updated it?

The first data structure I envisaged used a table with a row for each
prospect and a great many "single option" fields, with a second user-field
for each. Then a number of separate tables for the "multiple option" fields.

The second data structure considers the fact that I will only ever be
opening one page at a time. There would be a small central table that
identifies the most basic information about a prospect. Then there would be
a table for each page's "single options" similar to the main table in the
first data structure and a set of exctra tables for the "multiple option"
fields.

The second seems to be more complicated to program, while the first seems
like it would require a very large table with a great amount of fields. Am I
missing something? Does anyone know of a program I can look at with a
similar sort of structure? Is my description making any sense at all?

I should add that I've also taken a look at XML data structures to see if
that might help, but unfortunately my XML knowledge is worse than useless!
However I was thinking that using XML I might be able to make the
application sufficiently flexible that I could write a generic program to
create and parse any process flow.

Any thoughts / insights at all are appreciated :-)

.steve


----------------------------------
   WapWarp - http://wapwarp.com
 Wap-Dev - http://www.wap-dev.net
 Cookstour - http://cookstour.org
----------------------------------





More information about the thelist mailing list