Productions are complex.

Ok, seriously, why can't I ever start with a simple problem when I decide to learn a new programming paradigm? (not just a language, but a whole paradigm. My last language was PERL, which is sooo not object-oriented. My first project was building a content model for Rosetta Stone, where I work, and mapping it against new texts to determine whether or not a user could read the new text, given X units of Rosetta Stone. Harder than it sounds, since I took into account new forms of known head words).

The problem at hand:
I want to build a stage management system. I want it to do LOTS of cool things.
Examples:

• Have you ever noticed how every theater box office website SUCKS? I mean, really every one. Even the Kennedy Center, and they've got more money than God has angels. Why do they all suck? Selling tickets is not a hard problem, people. Why not just adapt ticketing software from, like...sports or something? Those people know what they're doing.
• Maintain actor bios so that making the program is easy. Automatically add a credit whenever the actor is cast in any play managed by the system.
• Help with doubling. This is when one actor plays several roles. It's frequently done in Shakespeare productions, where you have 40 characters, but several of them are in only a few scenes each. I did Antony and Cleopatra with 12 actors, and there are 43 characters. Doubling is a great theatrical technique, but it sucks to figure out. It's crazy error-prone. I think that writing a program that would create doubling charts is far too complicated for me (or practically anyone--some smart person once explained to me that this is basically the traveling salesman problem, and requires AI). I'd be happy to create a system that allows a director to propose a solution and then says whether or not it will work.
• Create part-scripts. Say you have a 16th-century play, and you want to do it old-school. Your advertising gimmick is that the rehearsal process is just like it was in Shakespeare's day (as far as we can guess). The American Shakespeare Center's Renaissance Season every spring is like this. Well, you'd want to use part-scripts (also called "rolls"). A part script is where it has the couple lines before your character speaks, what your character says, and then a big jump to the next cue for your character. In the days before printing was cheap and easy, this is how actors received their lines. Now, it is true that many of Shakespeare's plays are available in part-script form. But what if you want to cut the script a bit? What if you are doing doubling and you want each actor to have a part-script that contains all the lines for all of that actor's characters? To the best of my knowledge, practically every theater does this using cut-and-paste. No automated solutions exist (except for the one I wrote in PERL, and which I plan to do in Ruby).
• The biggie: scheduling rehearsals. This is how most directors/stage managers schedule rehearsals. You have one spreadsheet that has all the actors' conflicts (when they can't rehearse). You have another that shows all the scenes everyone is in. By going back and forth between spreadsheets, you figure out which scenes you can rehearse at each time slot. There's a very high probability for human error here, and it takes HOURS every week.

Those are just a few of the ideas I have. I really think this could be a useful service for theaters. The last problem is the one I chose to start with (because I'm dumb and overly ambitious). My trouble here is that it's so very complex to model a theater production. Then if I want to make it scalable (so that I could have several client theaters, and the whole system wouldn't collapse if two of them did Hamlet, or if a theater decided to do You Can't Take It With You for a second time, or if an actor worked for two different client theaters), it's a whole other can of worms.

I had a lot of this working, using a spaghetti junction of has_and_belongs_to_many join table things. Then I realized that it wasn't extensible. If I were modeling only one production, it would be great. But modeling only one production is not useful. I think that what I need to do is rewrite it to use has_many :through, with a "Production" model as the nexus. I'll still need other models, like a "Casting" model to connect users with roles. It's still a mess. I think the nested_has_many_through plugin will help here, but I'm a bit nervous that it won't. If it doesn't, I'm not sure what to do. So, here's my test schema...any comments would be greatly appreciated. I haven't implemented this yet because I'm sort of nervous about it...I have subversioned my present development instance, so it shouldn't be a big deal...but oh, the obfuscatory error messages! I can hardly bring myself to confront them.

 I need to bite the bullet and just do it...but I'm reluctant.

theater
has_many :productions
has_many :users, through :productions
has_many :plays, through :productions

production
belongs_to :theater
has_many :castings
belongs_to :play

user
has_many :credits, through :castings
has_many :productions, through :castings
has_many :conflicts
has_many :theaters, through :productions
has_many :plays, through :productions
has_many :acts, through :plays
has_many :scenes, through :acts

conflict
belongs_to :user

play
has_many :productions
has_many :theaters, through :productions
has_many :acts
has_many:scenes through :acts

act
has_many :scenes
belongs_to :play

scene
belongs_to :act
casting
has_many :users
has_many :credits #I'm saying credits instead of roles because "role" is a reserved model for my authorization thing. Also, "credit" allows for technicians as well as actors.