Re: [sf-perl] Practical theory: graphs

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: sanfrancisco-pm(at)pm(dot)org
Cc: Quinn Weaver <qw(at)sf(dot)pm(dot)org>, SF Postgres <sfpug(at)postgresql(dot)org>
Subject: Re: [sf-perl] Practical theory: graphs
Date: 2005-12-17 07:36:58
Message-ID: 200512162336.58618.josh@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: sfpug

Quinn,

> The system of nested menus is essentially a graph.  Menus are nodes
> with children (which may themselves be menus).  An end node represents
> the place where you actually get the person (or automated system) that
> you wanted.

This doesn't sound like a generalized graph, and certainly not like a node
map. It sounds like a heirarchy with shortcuts. This is the reason Elein
was very smart to ask you for more details on the real problem; it's easier
to solve than the theoretical problem.

First off, you don't have to worry about node maps' issue with
bidirectionality. Phone menus are always directional ... you're always
working "up" the tree, except when you get to a shortcut that takes you
somewhere else.

Further, you're not concerned with "branch properties"; that is, if menu M has
parent menu Q that really doesn't "mean" anything except as a system of
navigation.

So overall your system is a pure adjacency list. Which is really the simplest
type of graph there is. And easily handled by SQL-RDBMSes in a way that
social networks are not. You just have to get away from thinking of an
adjacency list purely as a heirarchy.

You have a simple structure like this:

menu name destination_type destination
1 Support menu 2
1 Sales menu 3
2 Home hold queue cheap support phonebank
2 Commercial menu 4
3 Home hold queue junior sales reps
3 Commercial menu 5
4 Small Business hold queue SMBsupport
4 Enterprise direct call support manager
5 Small Business hold queue SMBsales
5 Enterprise direct call sales lead
etc.

So far it's pretty heirarchical. But it doesn't have to stay that way. For
example, you might decide that you want to add options on each menu to go
back to the main menu. Also, maybe you get 25% of your calls from
businesses for support so you want to add a shortcut.

Then you might do:
menu name destination_type destination
1 Support menu 2
1 Sales menu 3
1 Commercial Support menu 5
2 Home hold queue cheap support phonebank
2 Commercial menu 4
2 Main Menu menu 1
3 Home hold queue junior sales reps
3 Commercial menu 5
3 Main Menu menu 1
4 Small Business hold queue SMBsupport
4 Enterprise direct call support manager
4 Main Menu menu 1
5 Small Business hold queue SMBsales
5 Enterprise direct call sales lead
5 Main Menu menu 1

This is just a cocktail napkin sketch of an structure, but hopefully it helps
you get your head around it. BTW, regarding the user log, it's this simple:

sessionid menu from menu to exit?
5001 1 3 N
5001 3 5 N
5001 ....

Hmmm, looks like you need option identifiers there too, as well as menu ids.
But it's late and hopefully I've inspired something.

--Josh

--
Josh Berkus
Aglio Database Solutions
San Francisco

Browse sfpug by date

  From Date Subject
Next Message Quinn Weaver 2005-12-17 07:43:03 Re: [sf-perl] Practical theory: graphs
Previous Message elein 2005-12-16 01:21:36 Re: Practical theory: graphs