Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

sfpug by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group