These tables show exactly what sort of work (for which hardware class for homogeneous redundancy) is available on the server in the shmem table, in the database and how many hosts are known in the database for each of these classes.
The thing is, the boinc server feeds your work requests through a table, a shmem table, of about 256 entries. If you request work, the only work you see is the work listed in that shmem table, despite the fact that there far is more in the database. The table should therefore be filled rather specific to the requests and to the type of work in de the DB and not just by a simple loop / query on the MySQL DB.
Sometimes you get the "no work from project" and yet on the site you see about 7000 WU's ready to crunch... Well, these 7000 available WU's are in the DB, but in the little shmem table (only 2x 256 WU's because we have two servers) are 'visible' to the requester... Get the mismatch if you do a stupid fill of the table? You can have the situation that the whole table is filled with the work for an Apple Mac because the DB contains work for it and the dumb feeder is just dumping linearly that work into the small tables...
Well, these kinds of problems are present on any project that needs to use homogeneous redundancy; folding@home, docking@home, Leiden Classical etc. This is because these project do molecular dynamics types of calculations and these calculations tend to be 'chaotic'. With chaotic I mean that a small deviation in a value of some starting condition or half way through a trajectory explodes and alters the final outcome of the trajectory. The trajectory is scientifically (statistically) still valid, but de numbers will be different... you see?
The tables you ask about show the different classes we use and how we schedule for them here at Leiden. Compare that to the docking@home scheduling to see the differences... Keeping in mind they have less classes and far les hosts in there project too and more over an increased shmem table of 4096 entries or so ;-)...