use-revolution Digest, Vol 66, Issue 47

[Jim Bufalini]

Hi Jim

> Thanks Jim. I get it.
> 
> I do a lot of election database work for local political  candidates
> at election time.
> In that case there are a fixed set of defined fields for each voter
> record.
> I use RR a lot for constructing mailing labels for select political
> mailers, i.e. mail to households, or to families using first names,
> or just to individuals.
> It doesn't appear that the hierarchical nature of  RR multi-
> dimensional arrays would be an advantage in these kinds of
> applications.
> 
> Thanks again,

I may as well jump into this thread and add my 2 cents worth. ;-)

What you say is both true and false, depending on point of view and what
aspect of this election database you are charged with designing and
maintaining and mostly how this database will be used. It could very well be
exactly what you need and can use. It is the fixed number of fields you
mention that a multidimensional array can let you work around.

For example, you have a voter table. Think of this for now as a spreadsheet.
The rows of this table is one for each voter. Again, for simplicity sake,
let's say there are only two columns: Name and Address (ignore for now that
addresses are usually broken into multiple columns of street, zip, etc)

Now, some voters only have one address. But some voters, maybe exactly the
ones you want to contact, ;-) have multiple addresses, and all over the
world (because they have lots of money), and can be at any one of these
addresses at election time. So, you want to make sure to mail to all of
their addresses, but only to the people who are registered to vote in a
particular district.

The "two-dimensional" way of handling this is to create another table called
Addresses where you can enter any number of addresses for one individual.
Each of these addresses then has to be "related" (indexed) to a single
individual (many-to-one relationship). Now you need a complex query to
retrieve and print out your mailing.

What multidimensional arrays allow you to do is to stay with your original
single table of two columns of Name and Address. Except, you make the
Address column an array of addresses. And, in this simplistic example, you
would probably want to add a third column of Primary Zip Code (where they
can vote).

Your data entry people can now enter one address for an individual or 20
addresses or any number of addresses. Again, all within one table.

Now when it comes time to do your mailing, you select from your single table
all voters within a range of zip codes (simple query of your third column of
Primary Zip Code). And then your code just loops through the Address array
and for each address, prints out a postcard.

Furthermore, since each address array can contain other arrays, such as what
country clubs or restaurants are nearby each address, you can further
personalize your mailing and suggest a place to meet (next to each address),
all without creating multiple two-dimensional related tables.

Where what is called "multi-valued" fields (I worked from the early '80s to
the early '90s with another "Rev" called Revelation, which is the Pick OS
ported to PC as an IDE and application development environment that is very
similar to Revolution in that it is a scripting language - and loved it)
shines is in areas like the example I gave above where you don't know, in
advance, how many of one column there can be.

The weakness of putting arrays into single columns is that, today, this has
to be put into a two-dimensional SQL database and this creates issues with
indexing and retrieval. What Pick/Revelation had was specialized b-tree
indexes where you could index on just one element of a multi-valued field.
It also had built-in all the handlers for sorting and "breaking-out" these
multi-valued fields.

Thus, to use multidimensional arrays for database in Revolution, you will
have to do things, like in my example, of identifying those elements that
you will need to index (the Primary Zip Code of my example). Otherwise, it
is matter of thinking in 3, 4 or more dimensions, rather than the more
common two-dimensional, related table database thinking.

Hope this helps you get your arms around the value and possible pitfalls of
using multidimensional arrays, at least in two-dimensional SQL databases.
There are, of course, other advantages of being able to have arrays within
arrays outside of database.

Aloha from Hawaii,

Jim Bufalini