Recent Progress

Data, data everywhere but not a row to read

It's great to look at pretty pictures of a well-designed user interface and talk about efficient algorithms for picking a schedule, but none of it would be possible without access to data about what courses are offered.

I've been working with data available publicly through the web catalog so far with the hope that I'd be able to get access to the real database at some point. The Registrar's Office is unwilling to give access even to the same data I already have (though will be sending a spreadsheet-type (comma delimited) version of the data at some point).

| Tables_in_CourseCorrect |
| SCBCRSE                 |
| SIRASGN                 |
| SPRIDEN                 |
| SSBSECT                 |
| SSRMEET                 |
| STVSCHD                 |
| STVSUBJ                 |

Thus, I've created my very own "Pretend-to-Make-Believe Course Registration Database." It's built to the same specifications as the actual database UVM uses, and is populated with data gleaned from the web catalog, making it identical in all the ways that matter.

The horribly ugly list of tables on the left is the only visible result of this so far. To anyone who's ever questioned naming conventions in a programming class: please, please, please learn a lesson from these names! This is what SCT (the company that produces the BANNER system UVM uses for course registration) decided to name its tables. The sad part is I'm now intimately familiar with these names after working with this schema for three years.

This may also serve as a lesson for anyone who doesn't believe in optimizing databases (it's a hypothetical scenario; go with me for a moment). When I first created these tables, without any indices created, even the most basic query took at least 30 seconds to process. After adding indices the same queries take (as they should) under a second. Hurrah for all that stuff we learned in Algorithms class!