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 _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
