Horse Crazy – An Infinite Number of Horses

I’m having a hard time getting back into the swing of things after the holiday weekend (here in the USA). Most holidays I work right on through, but this time I spent almost three entire days NOT working. Well, I documented some of the artwork needed for Dwayne, but it wasn’t until today that I did a little coding.

Very little. 🙂

I started with code from Ansca Mobile’s Code Exchange and then tweaked it a bit for my needs. If you need to swipe a bunch of “slides” from side to side, this is a great place to start:

Slider Module

What I wanted was a whole row of objects that you could scroll through horizontally and with a minor bit of tweaking I’m well on my way to having it work correctly.

Here’s a 1-minute video that shows the slide in action as well as gives you an idea of how the main part of the Horse Crazy app will work:

Like I said in the video, that’s just placeholder art so I’m not sitting around twiddling my thumbs — I’ll replace all that stuff as Dwayne starts feeding me things.

An Infinite Number of Horses?

Tonight I stopped as I was putting together the database (Database? For horses? Huh?) when I realized I was creating tables for an infinite number of horses and an infinite number of supplies (tack). While there are times when coding limitations is NOT a good idea, I’m not sure a “dress up your virtual horse” fits in that category.

Let’s say the horse can have a bridle, saddle, reins, and lariat. Since each horse has to know whether it’s wearing those items, you could have a data record that looks like this:

In the horsename field would be the name of the horse, so we know which one we’re talking about, and in the other fields would be the names of the graphics for that piece of tack — bridle.png, saddle.png, etc.

All well and good, but what happens when we decide that horses should also be able to have saddlebags, hackamores, and breastplates? Now we have to change the database to add extra fields.

So the “right” way to do it is to create a horses table, create an equipment table, and then create a table that ties the two together.

In the horses table all you’ll have is horse info — just what we know about each horse plus each horse will have a unique ID.

The records in the equipment table will be about each piece of tack and each record will have a unique ID.

In that third table we’ll have a single record for each piece of tack that’s associated to each horse. So if the Arabian horse had a saddle and a hackamore, there would be two records in that table:

– ArabianID + SaddleID
– ArabianID + HackamoreID

Adding three more pieces of tack onto that horse would add three more records. And if we wanted to add a Snufflebit to the list of available tack, we could do that by just adding data to the database and NOT changing the underlying structure.

So to find all the tack that goes with any specific horse, all we have to do is query that third table like so:

Now we’ll have a list of tack that should be on the horse and we can dress it up.

What’s Wrong With That Approach

Like I said, as I was putting together the database tables I started wondering whether it was overkill, and so stopped to put down my thoughts about it.

And in writing this blog post I’ve come to the conclusion that it’s absolutely the right way to handle the problem. While I could probably decide that there will never be more than 10 horses total or 30 pieces of tack per horse and get away with it, the code to do that wouldn’t really be any easier than what I described above.

If I do things the right way now I won’t have as many problems scaling things up in case (when?!) Horse Crazy takes off and people are clamoring for new tack and horses in updates.

I guess the moral of the story is that sometimes the right way to do things doesn’t really have to be any harder than the easy way to do things. 🙂