I think this was one of the most enjoyable meetings we've ever had, and certainly the most interactive. As the chapter president, this took very little preparation (printing, writing implements) and really required me to do nothing more than lead the discussion. My most excellent user group colleagues did all the heavy lifting, with lots of smiles.
I took my Relational Database Design exercise from the October 2012 Regional AITP Conference, printed out a bunch of copies, and handed them out to the attendees. I'd recommend this to anyone looking for a change-up in their user group. We couldn't find a speaker for January, so I thought this would be good content for our first meeting of the year.
For about 20 minutes, they worked with pens (not pencils, we're professionals!) on scratch paper for rough drafts of their design. I reminded them that knowledge of American college football was not required, and that if you were making design decisions based on sports knowledge, you're probably not on the right track.
I hooked up my laptop to the big screen TV and started up a blank database diagram in SQL Server Management Studio 2012, which many of them had not seen. The Database Diagrams tool built into SSMS is perfect for an exercise like this. I hit "New Table" and said, "What table is first?" Later, "Any more columns we need here?" "What's the next table?" "What would be the best data type for this?" While on the keyboard, I tried to make as few decisions as possible, and encourage discussion of everyone's ideas and suggestions. A couple times, we backed up the design after changing our minds. No worries!
The 15 of us got through most (not all) of the design in about 80 minutes, time which flew by. We had a great mix of very friendly folks. Some had experience back to SQL 4.2, some with lots of Business Intelligence experience, and some .net devs with only accidental SQL experience. We covered a ton of topics that were educational for everyone, and stumbled across too many design choice point-counterpoint discussions to remember.
Do we need audit fields? What attributes do we need to store per year, per player, or per game? Are attributes dependent on the primary key? How should we handle static student data vs student data that is measured annually? The storage of games, schedules and rosters was a big source of conversation - always polite and professional and with lots of jokes and side conversations. While most of our design conversation was vendor agnostic, we also touched on data types and indexes in SQL Server.
Along the way, added indexes, unique constraints, computed columns (to record if our football team won/lost/tied), foreign keys, identity columns and more, using only the Management Studio Database Diagrams.
The point of the user group meeting was not to complete the exercise - there wasn't enough time - but to raise all the kind of database design decisions that would come up in "real life." With more time, we could have completed the design, filled in sample data, or even created some basic reports and a data warehouse to serve them.
Here is a link to the problem statement for the contest, which I suppose now I can't ever use again for a conference competition:
Here's a second panoramic I took, with much less success. My apologies to the folks whose heads were vanished by the Pano app on my android phone.
Thanks to everyone who attended, see you in February!
