Joined: 27 Mar 2007
Location: Troy, MI USA
| 0 votes |
| 0 salutes ||
|Posted: Tue Oct 23, 2007 3:54 am Post subject:
|?Sparsely? vs. ?Densely? populated tables.
The ?Sparsely? and ?Densely? populated COBOL table description, used in some circles, are used to describe how the COBOL table looks after it has been populated. That is, which elements within the table have been populated with data.
The ?Densely? Populated table
What we would consider a ?Densely? populated table is a table that is populated in the normal way. That is, all of the table entries are populated, starting at subscript 1 and ending with the subscript equal to the number of entries, with the remainder of the table being empty.
You would read the first branch record and place it in the branch-table (subscript 1), read the next record and place it in branch-table (subscript 2), and so on. So when all of the branch records have been read, all 490 of them, the Branch table subscripts 1 through 490 all have branch data in them. And as you can see, the data is ?Densely? populated, with no gaps, all at the beginning of the table. The table entries would, however, not be required to be sequentially in order.
The ?Sparsely? Populated Table
Now the ?sparsely? populated table, unlike the ?densely? populated table does not require that the entries are populated starting at subscript 1 and every subscript increment being populated. Quite the contrary, the populated entries are scattered throughout the table with most of the table being empty. So if you were to read branch 1273 you would use the branch number as the subscript into the table and populate the branch-table( subscript 1273), then read branch 6729 and populate branch-table ( subscript 6729) and so on until all the branches are read and the appropriate entries populated. And as you can see, the table is ?sparsely? populated with the valid entries scattered throughout the table.
?Densely? vs. ?Sparsely? Pros and Cons
You can see that the structures of these two types of tables are greatly different. So the question arises, why would one use one type over the other type?
The answer depends on how the table will be accessed, and to what frequency it will be accessed.
You could be sending advertisement to 10s of thousands to 100rds of thousands to millions of households with the branch number in the letter bouncing around like popcorn. Or you may be sticking to a single branch and sending to all the households in that area.
A ?densely? populated table lends itself to sequential processing, read the first branch-table entry, process that one, go on to the next and so on. However, even if the table is in sequential order, it does not lend itself to random access very well. Even if you use a binary search, the overhead can be substantial if done enough.
On the other hand, the ?sparsely? populated table shines on random access, as the branch number becomes the subscript and access is pretty well direct. However, the ?sparsely? populated table does NOT lend itself to sequential processing as you now need to read through all of the empty entries to find a few valid entries.
I have had the problem of having to access entries in a table hundreds of million times, both sequentially and randomly, in the same program, depending on the type of input. In this case, I built both types of table, with a little modification to the ?sparsely? populated table.
As I read the data to be placed in the table, I would build my ?densely? populated table entry, then use the key of the entry as the subscript to the ?sparsely? populates table, but instead of putting the data into the ?sparsely? populated table I put the subscript of the ?densely? populated entry into it.
So now, if I had to randomly access the entry, I would use the entry Key as the subscript into the ?sparsely? populated table to get the subscript of my entry in the ?densely? populated table. It?s a little slower since I need to make two accesses, but a lot faster then searching for the entry.
Well, I hope this answered more questions than it created. If you have any questions, please come back